当谈研发效能时,该谈些什么?
最近翻了下之前写的公众号文章,发现研发效能相关的就有三篇:
- 怎样提高开发效率
- 关于增效,需要做好这两点
- 再谈研发效率提升
从工具使用、业务的理解、团队的沟通协作到流程、组织、分享等内容,我能想到的大部分有关研发效能的点都有涉及到。
但知识和认知是在不断进化的,就像好书一样,常读常新。最近关于研发效能又看了些书和视频,有了些新的想法。
1、研发效能的本质是人,最终还是需要依靠人的内驱力来达到效能的提升,所有工具建设、流程优化、组织管理都是为人服务的;
2、 向落后的项目中增加人手,只会使进度更加落后,这就是著名的 Brooks 法则,因为增加人会带来沟通成本的增加,增加更多的人,这个成本会指数级地增加。但也并非绝对,如果事情都拆分的很细,并且有标准化的文档,增加的人员可以根据文档快速落地,也能增快速度的。软件研发中想做到零沟通,这种情况很少,也很难。
3、《人月神话》中有这么一句话:人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。就是说 1 个人做 10 个月能完成的任务,让 10 个人做 1 个月就能完成。这种在流水线上的计件工是可能的,但在软件研发项目中就成为神话了。
4、德鲁克说过:管理是最大限度地激发他人的善意。这个善意是指激发员工的成长性思维,提升每个人的内驱力,让每个人看问题能更长远,而不是只顾眼前利益。如果管理者在潜意识中认为每个人都是人性本恶的、那么在管理方式方法上就会引发他人的恶意,这种恶意对外的表露更是让管理者觉得自己的感觉是对的,从而形成了一种恶性循环。
5、德鲁克还说过:如果你不能度量他,你就不能改进他。好的度量要符合两个标准:
- 从解决根本痛点问题作为出发点;
- 能够引导团队成员做出正确的行为。
6、度量不应该跟 KPI 进行绑定,程序员是聪明的,上有政策就会下有对策,往往会适得其反,这样的例子很多:
- 考核钉子的个数,结果就是会生成一堆小钉子;
- 考核钉子的重量,结果会得到几个大钉子;
- 考核延期率,最终都不会延期,但质量就不能保证;
- 延期率和 Bug 数都进行考核,代码中就会有各种补丁,难以维护和扩展。
考核什么指标,经过一定的时间,从数据上看,这些指标肯定会越来越好,但结果未必就好。古德哈特定律也提到:当一个政策变成目标,它将不再是一个好的政策。
7、霍桑效应是指意识到正在被观察的个体,具有改变自己行为的倾向,这是心理学上的一种特征。在管理团队时,也需要照顾到每个人,做的好的时候要表扬、做的不好的地方要指出不足、心态、心情有波动的时候需要鼓励和安抚。每个人都觉得自己被关注了,就会做出改变。
8、樊登读书讲的《可复制的领导力2 》中,提到了一个「10 倍好」的方法,意思是如果要求提升 20 % 的效率,首先想到的是多招点人,加加班,或者增加投入,肯定能够提高 20% 。如果要求提升 10 倍的效率,就不是靠加人、加班可以解决的,需要我们放弃过去的做法,进行一些颠覆性的创新。10 倍这是一个说法,主要是思维能跳脱出来,站在更高维度来看问题。
9、代码注释是提升代码信息熵的低成本手段,只要稍加注意,每个人都能做到,可以减少人和人之间的依赖。以前觉得如果一个研发团队职责分的比较细,各个环节标准化,上下游协作像流水线一样,这样效率就会很高。实际发现很难做到,现在更倾向于一个人或一个小团队做一个垂直的模块。
10、交付更多的功能就实现了目标吗?当我们被繁重的工作弄得焦头烂额的时候,需要停下来思考下这个问题。最近领导在群里说:三个盖子五口锅,怎样才能把饭做熟?,有人说加火加时间,我觉得火太大不一定是做熟,有可能做糊了。要解决这个问题要思考下面几个问题:
- 一定要五口锅才能吃饱饭吗?
- 每口锅是否是满的呢?如果不是,是否能减少到三口锅,让每口锅装满?
- 如果五口锅都是满的,才能勉强吃饱饭,那就要好好想想了,是不是饭的质量不行,不抗饿?
找到问题,才能解决问题,加火加时间只能掩盖问题。
文章转载自公众号:不止dotNET