四年回顾——关于研发效能的思考
在H厂工作的四年里，我主要从事嵌入式开发工作。但工作之余也一直在思考团队的研发效能问题——如何提高团队的开发效率及开发质量。整个团队的主要状况是：
- 开发人员没有掌握基本的开发工具（如git、shell等）
- 投入多，产出少，流出BUG多
- 事成了但人不爽
- 储备的骨干人员流失严重
在实际工作中我们可以开发很多工具或自动化脚本用于提升效率，但最后我发现工具并不是阻碍研发效能提升的关键因素，团队管理与企业管理制度才是研发效能提升的重点。
一、团队管理——责任分配与知识负荷问题
在入职H厂初期，我便与主管领导进行过一次谈话沟通，当时我提出了一个疑问——团队所有人都对当前的业务负责，但并没有分配具体的业务模块到某个人头上，是否可以按业务模块划分责任？即团队的责任划分作如下变动：
在我工作过的几家公司，基本都是按图2的形式分配工作的。与H厂的主管交流后发现团队责任分配采用图1的形式的主要原因有：
- 避免人员流动造成业务无人可接的问题。
- 团队多项目并行，且有人力管道分配的限制，图1的组织结构更具灵活性，更能应付项目诉求。
但是图1的组织结构具有的天然缺陷却在日益增长的业务面前逐渐显露问题。问题主要体现在责任与知识负荷方面。
每个人都有责任其实就是每个人都没有责任
图1的组织结构在责任方面的问题正如本节标题所提的那样——每个人都有责任其实就是每个人都没有责任。当团队所有成员共同对具体某个业务模块负责时，大家都不会对其负责，也不知道该不该对其负责。比如在实际工作时，团队经常讨论的问题是——某块代码之前是A改的，那么出BUG了是A去改还是定位的同事去改？
在软件工程领域，有个很流行的概念叫“重构”。但在图1的团队中，重构是个不存在的概念，没有人愿意去修改大家共同负责的代码。此处我并不是支持重构，因为能正常工作无问题的代码远比程序员心目中的优质代码更为重。但是随时业务发展及需求变化，代码若不适时进行重构，会带来更高的维护成本，也更容易流出问题。
若团队所负责的项目只是个临时项目或是生命周期较短的项目，那么采用图1的结构并不会带来多大的问题，因此项目结束了，责任也就结束了。但若是面对的是长生命周期（10年甚至20年）的项目，图1就会带来越来越多的责任问题。
责任越多，知识负荷越大
工作越久，越不得不承认一点——人的能力是有局限的。当团队中每个人都对业务负责时，会带来一个非常严重的问题——团队成员难以应付复杂的业务场景和业务知识。相比于只需要了解业务的一小块逻辑，了解整个业务的详细细节是非常难的事。就以面试时常碰到的八股文为例，面试官会要求你了解操作系统的底层细节、C++/JAVA的高级技巧、计算机网络的详细实现、内核的详细工作原理等等。我们需要了解的知识很多，但人脑是有局限的，负荷越大效率越低。
在团队中时，我曾经非常疑惑一个问题——这个团队的人都比较聪明，为何连git、shell等基础工具都不会？但如果了解团队成员的知识负荷，就可以发现——并不是他们不想去学，而是他们没有时间去学。当团队成员对业务的所有模块都负责时，成员都无时无刻不处在学习之中，因为他们所要分析与解决的问题每次都是不一样的。在这种情况下，他们学习业务知识都分身乏术，但别说去学习可有可无的工具使用技巧了。
按模块划分责任的优势
总结上面所讨论的问题，团队每个人都对业务负责会带来责任与知识负荷问题。那么采用按模块划分是否可以解决这两个问题并解决人员流动与多项目并行的问题呢？
首先很明确的是，按模块划分责任可以降低团队成员的认知负荷问题，因为需要学习的东西变少了。当然这也会带来另一个问题，需要有方案培养统筹全局的架构设计的人。不过这个问题相对来说比较好解决——当成员对某个模块已经较为了解时，可以让他的手伸长点，承担起其它模块的责任。逐步在团队中培养起能够对全局业务都有所了解的架构设计师。
其次，按模块划分责任不一定能够让每个人都对自己负责的模块承担起责任，但按模块分责能够解决“谁该负责”的问题。成员责任心是主观能动性的问题，而成员责任是边界问题。边界理清楚了，再配合绩效管理可能有助是保持业务健康有序发展。
至于人员流动性问题其实并不是大问题。按模块分责后，每个人的知识负荷小了，也会有更多的时间去进行学习与总结。当某些成员真的离职之后，他们离职前形成的总结就是最好的交接材料。相对的，不按模块分责，一方面团队成员并没有多余的时间进行总结思考，因为一直在学习新知识；另一方面，大家都对业务负责，那么离职时也就没有需要交接的业务知识了，不懂问老员工就行了。而且私以为当团队成员不再一直处于不断奔波学习中时，也能够降低人员流动率。
最后是多项目并行的问题。不可否认的是，当团队按模块分责时，参与项目的人会相应地变多，带来更多的沟通成本。相对的好处是每个人都对自己负责的模块比较了解，能够更快地解决问题。不过当项目涉及多团队开发时，更高的沟通成本可以通过统一对外接口来解决。统一的对外接口人可以减少沟通路径，进而减少沟通成本。
综上，我认为采用图2的团队管理方式能够划清团队成员的责任、减少团队成员的知识负荷，进而提高团队的开发效率。
二、管理制度——绩效管理与统筹规划
作为一个底层小兵，我在这方面的认识并不一定是正确的，因为位置低了看到的事物就很有限。因此这节只大概提我在工作中碰到的问题及对研发效能的影响。
绩效制度应关注公共领域
我在工作后期，主张将各个业务领域相应的测试团队的自动化系统进行统一。因为在实际工作中，我发现不同的团队都在搭建自己的自动化工程，每个团队的测试框架、资源管理方式、测试方案都有所差异。这其实带来很大的资源浪费问题，各个团队都在进行重复的工作，而且都需要有专门的人员去维护自动化系统。因此我主张构建统一的自动化团队专项负责该问题。但是在多次与领导沟通之后，我发现他们并不是不想组建这样一只团队，他们所面临的问题是——如何给这个团队进行绩效评价。
公共领域的绩效评价确实是个难题，因为公共领域并不与直接的业务相挂钩。某项业务赚钱了，到底应该分给公共团队多少钱不太好评估。但是因此就不组建公共领域团队其实也不合理，因为各个团队效率低下、重复造轮子，损害的是企业的整体效益。
此处我无法给出具体的解决方案，或许可以按BUG流出指标、公共领域带来的效率改进成果、服务团队的评价等维度进行评估。
由技术专家与业务专家统筹规划
我在H厂的四年恰逢H厂“软件变革”的四年，这四年里我感觉异常痛苦——各类人员借机粉饰绩效从而带来整体软件工程的动荡。举两个例子吧：
- 源码交付改革。我们知道，在git CVS下大项目的源码管理一般都会采用google repo或git submodule的方案。当然，采用一个统一库的情况也有。我在H厂的第二年，团队就开始进行源码交付改革，将所有业务领域的代码都统一到一个代码库中。这带来的问题有：
- 仓库过大，代码下载慢，仓库频繁爆仓
- 未做权限管理，导致各业务模块逐渐出现耦合情况，后期问题加重
- 软件上厂里公共的CI/CD平台持续变化，一年一平台，一年一方案。平台端优化即“绩效”，上层应用端却因此频繁被虐。每当一个平台已经趋于稳定，团队成员已经了解平台的运作机制时，平台就进行切换或方案变更，从而带来极大的维护成本。平台不仅没有提高软件工程效率，反而带来负面影响。
我之所以举上面的两个例子，是想说明一点——软件工程是个系统工程，牵一发而动全身。小到源码管理、大到CI/CD平台都需要良好规划，这些系统性工程都需要有技术专家与业务专家的参与。笔者所看到的是，不懂技术的人员规划了方案，完成指定目标之后就升级走了，留下一堆烂摊子造成整体工程动荡，各个团队苦不堪言，效率更为低下。
三、总结
综上所述，私以为团队管理及企业管理制度是提高软件研发效能的关键要素。在研发效能提升过程中，我们既应该关注高效率工具开发、流程精简、DevOps模式，也应该关注企业管理和团队管理的方式。