产品研发效率是困扰大多数互联网公司的问题。从人事政治的层面，产品研发降速通常有三个要素：
这三点都涉及到同一个要点，就是 “免责”。如果行动中出错，我要背锅。如果行动没错，但有用户骂起来了，我也要背锅。所以宁肯把流程拉长到三倍五倍，反正工资照发，但这样我就不背锅了。既要研发效率高，又要所有环节不出错，这是做不到的。效率低老板不知道骂谁，出错可是点名枪决。稍微大一点的产品研发团队，效率必然打着滚地下降。换成另一个包袱轻，少而精的团队，单位效率可以做到大厂的3-5 倍——我的创业团队就做到过。但我也亲眼目睹，曾经是高效率的十几个人的小团队，成长为几百人中型团队后，效率打着滚地下降。原因之一就是产品规模成长后，对出错的敏感与责备增加，人人自危，但求无过。在小团队，出错就出错呗，改过来，下次注意就好了。快速迭代最重要。在大中型团队，出错不叫出错，那个叫 “事故”，一次严重的生产事故。就算不扣工资，也要通报批评。就算不通报批评，大家都知道你出了事故，心理压力也是很大很大的。所以小团队敏捷，未必是小团队强悍，更多是轻装上阵，人少所以协作成本低，心理负担小所以下手飞几把快。总之，既要又要，最终必然是一项权重更高的 KPI ，压倒了其他冲突性的 KPI。KPI 之间的博弈也有胜负，但不妨碍既要又要的口号喊得响亮。除开人事政治的因素，就技术论技术，怎样提高研发效率？我和拍档的研发老大多次讨论过这个问题。他的回复是，对于几百人的团队而言，仅仅提高团队素质是不够的。更有效的方法是 “重构代码”，相当于优化代码结构，更有效率地接住需求。一个在屎山上开发了 3 天的功能，如果重构为灵活优雅的代码结构，可能只需要半天就完成了，并且可维护性更佳。但这需要产品团队的配合，给代码重构留出时间。否则产品侧不断压新需求过来，研发侧忙不迭地实现新需求，无暇重构老代码——屎山越堆越高，积重难返。屎山这种事情，很多时候并不是研发能力的问题。有时候是需求不断叠加后，代码结构也应该随之而变化。有时候急着功能上线，研发只能用一些应急的脏办法去实现。如果有机会重构代码，未来该系统的功能迭代就可以大大加速，磨刀不误砍柴工。问题是磨刀消耗的时间并没有直观的产出，对于产品侧，尤其对于老板来说，没有产出和摸鱼何异？所以很多公司并不鼓励代码重构，得研发老大扛住压力，一边开车一边换引擎。我经历过的情况是，老板一边吐槽 “我们的研发效率为何如此之低？”“为什么不能一边开火箭一边换引擎？” 一边连绵不断地压新需求过来，仅仅是完成新需求都很吃紧，不给任何代码重构的时间，屎山越堆越高。我只能扛住压力，把几个核心页面的迭代时间拉长，偷偷给研发匀一点喘息空间去重构。很显然，我这种产品老大极其稀有，更多的产品老大逼着技术 996 赶工完成老板需求——反正加班的是程序员又不是他，但这样老板就会欣赏产品的 “推动力强”。
这个道理，放着互联网研发之外的领域，其实也是一样的。傻子都知道磨刀不误砍柴工，但又受不了磨刀时没有产出，没有产出就烦躁不安，最终拿着钝刀冲进山林，并且抱怨 “这砍柴的速度真的不行。”
内容来自“用思考交换思考”的 PM 思辨社区「犬校」。©2017-2023
