最近翻了下之前写的公众号文章，发现研发效能相关的就有三篇：

• 怎样提高开发效率

• 关于增效，需要做好这两点

• 再谈研发效率提升

从工具使用、业务的理解、团队的沟通协作到流程、组织、分享等内容，我能想到的大部分有关研发效能的点都有涉及到。

但知识和认知是在不断进化的，就像好书一样，常读常新。最近关于研发效能又看了些书和视频，有了些新的想法。

1、研发效能的本质是人，最终还是需要依靠人的内驱力来达到效能的提升，所有工具建设、流程优化、组织管理都是为人服务的；

2、 向落后的项目中增加人手，只会使进度更加落后，这就是著名的 Brooks 法则，因为增加人会带来沟通成本的增加，增加更多的人，这个成本会指数级地增加。但也并非绝对，如果事情都拆分的很细，并且有标准化的文档，增加的人员可以根据文档快速落地，也能增快速度的。软件研发中想做到零沟通，这种情况很少，也很难。

3、《人月神话》中有这么一句话：人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。就是说 1 个人做 10 个月能完成的任务，让 10 个人做 1 个月就能完成。这种在流水线上的计件工是可能的，但在软件研发项目中就成为神话了。

4、德鲁克说过：管理是最大限度地激发他人的善意。这个善意是指激发员工的成长性思维，提升每个人的内驱力，让每个人看问题能更长远，而不是只顾眼前利益。如果管理者在潜意识中认为每个人都是人性本恶的、那么在管理方式方法上就会引发他人的恶意，这种恶意对外的表露更是让管理者觉得自己的感觉是对的，从而形成了一种恶性循环。

5、德鲁克还说过：如果你不能度量他，你就不能改进他。好的度量要符合两个标准：

• 从解决根本痛点问题作为出发点；

• 能够引导团队成员做出正确的行为。

6、度量不应该跟 KPI 进行绑定，程序员是聪明的，上有政策就会下有对策，往往会适得其反，这样的例子很多：

• 考核钉子的个数，结果就是会生成一堆小钉子；

• 考核钉子的重量，结果会得到几个大钉子；

• 考核延期率，最终都不会延期，但质量就不能保证；

• 延期率和 Bug 数都进行考核，代码中就会有各种补丁，难以维护和扩展。

考核什么指标，经过一定的时间，从数据上看，这些指标肯定会越来越好，但结果未必就好。古德哈特定律也提到：当一个政策变成目标，它将不再是一个好的政策。

7、霍桑效应是指意识到正在被观察的个体，具有改变自己行为的倾向，这是心理学上的一种特征。在管理团队时，也需要照顾到每个人，做的好的时候要表扬、做的不好的地方要指出不足、心态、心情有波动的时候需要鼓励和安抚。每个人都觉得自己被关注了，就会做出改变。

8、樊登读书讲的《可复制的领导力2 》中，提到了一个「10 倍好」的方法，意思是如果要求提升 20 % 的效率，首先想到的是多招点人，加加班，或者增加投入，肯定能够提高 20% 。如果要求提升 10 倍的效率，就不是靠加人、加班可以解决的，需要我们放弃过去的做法，进行一些颠覆性的创新。10 倍这是一个说法，主要是思维能跳脱出来，站在更高维度来看问题。

9、代码注释是提升代码信息熵的低成本手段，只要稍加注意，每个人都能做到，可以减少人和人之间的依赖。以前觉得如果一个研发团队职责分的比较细，各个环节标准化，上下游协作像流水线一样，这样效率就会很高。实际发现很难做到，现在更倾向于一个人或一个小团队做一个垂直的模块。

10、交付更多的功能就实现了目标吗？当我们被繁重的工作弄得焦头烂额的时候，需要停下来思考下这个问题。最近领导在群里说：三个盖子五口锅，怎样才能把饭做熟？，有人说加火加时间，我觉得火太大不一定是做熟，有可能做糊了。要解决这个问题要思考下面几个问题：

• 一定要五口锅才能吃饱饭吗？

• 每口锅是否是满的呢？如果不是，是否能减少到三口锅，让每口锅装满？

• 如果五口锅都是满的，才能勉强吃饱饭，那就要好好想想了，是不是饭的质量不行，不抗饿？

找到问题，才能解决问题，加火加时间只能掩盖问题。

祝大家儿童节快乐！