研发效率破局之道01 | 如何系统地理解研发效能?

你好,我是葛俊。今天,我来和你聊聊什么是研发效能,以及研发效能的模型,这些内容是理解整个专栏的基础。 
今年的 3 ⽉ 26 ⽇,⼀位昵称为 996icu 的⽤户,在 GitHub 上创建了 996.ICU 项⽬,⾃此 996 这个话题被推上了⻛⼝浪尖。⽬前,这个项⽬已经拿到了 24 万多颗星。朋友们也常常问我:硅⾕的公司有没有 996? 其实,在硅⾕,很少有公司要求 996。
不过,在初创公司,因为业务紧张、同事间的竞争,加班也很常⻅。但是,硅⾕和国内的公司有⼀个很⼤的区别,就 是硅⾕的公司⼀般是任务驱动,只要完成任务就⾏,不管你花了多少时间。⽽国内很多实⾏ 996 的公司不仅仅是要求完成任务,更强调⼯作时⻓。但其实, 专注时⻓的这种操作在软件开发⾏业是不合理的,因为⻓期加班不能保证持续的⾼效产出。 
从我以及身边许多开发者的经验来看,每天能够⾼效地产出代码五六个⼩时,已经相当不错了。短期突击加班会有效果,但如果⻓期加班,通常效率、质量会 下降,产⽣了 Bug 就要花费更多的精⼒去修复。如果这些 Bug 发布到了⽤户⼿上,损失就会更⼤,得不偿失。 
⻓期加班还会出现⽆效加班的结果。⽐如,有个朋友在⼀家国内⼀流的互联⽹公司⼯作,据他反馈,公司实⾏ 996,很多⼈加班其实是磨洋⼯,低效加班⾮ 常明显。可想⽽知,其他推⾏ 996 ⼯作制的公司,⼤概率也会存在这种问题。 
那么,⻓期加班效果不好,⾯对激烈竞争,我们到底应该怎么办呢?在我看来,这个问题还是要从软件开发本身的特点来解决。 
为什么要关注研发效能? 
软件开发是⼀个创造性很⾼的过程,开发者之间的效率相差很⼤。就⽐如,10x 程序员的⽣产效率可以达到普通开发者的 10 倍。其实,不仅是个⼈,团队间 的效率相差也很⼤。所以,相⽐⼯作时⻓⽽⾔,公司更应该关注的是研发效能。 
接下来,我们再回顾⼀下我在开篇词中给研发效能的定义: 
研发效能,是团队能够持续为用户产生有效价值的效率,包括有效性(Effectiveness)、效率(Efficiency)和可持续性(Sustainability)三方面。简单来说,就是开发者是否能够长期既快又准地产生用户价值。
硅⾕的很多知名公司,⽐如 Google、Facebook、Netflix 等,在研发效能上做得很好,是研发效能的标杆。这,也是它们业务成功的重要因素。 
以我在开篇词中提到的 Facebook 的部署上线流程为例。Facebook 在 2012 年达到 10 亿⽉活的时候,部署⼈员只有 3 个,达到平均每个⼈⽀撑 3.3 亿⽤户 的惊⼈效率。举个形象的例⼦,如果全中国每⼀个⼈都使⽤ Facebook,那最多只要 5 个部署⼈员就够了。 
Facebook 做到这⼀点的基础,就是不断提⾼研发效能。还是以上⾯的部署流程为例,原来的部署已经⾮常⾼效,但是在 2017 年,Facebook ⼜引⼊了持续 部署,做了进⼀步的优化,实现了更⾼效率的部署上线。试想⼀下,如果 Facebook 选择堆⼈、堆时间的话,那需要增加多少⼈、多少加班才能做到呢? 
所以在我看来,如果研发效能提不上去,单靠加⼈、加班根本不可能解决问题。 
注重研发效能的另⼀个巨⼤好处,是开发者能够聚焦产出价值,更容易精进⾃⼰的技术。于是,团队容易建⽴起好的氛围,进⽽⼜能促进⽣产效率的提⾼,形 成良性循环,⽀撑持续的⾼效开发。 
所以,国内公司近⼀两年越来越注重提⾼研发效能,许多公司甚⾄专⻔成⽴了⼯程效率部⻔。但是,在真正开展研发效能提升⼯作时,它们却常常因为头绪太 多⽆从下⼿,或者对⽅法了解不够,导致画⻁不成反类⽝的效果。这,⼜和软件研发的⾼度创造性和灵活性紧密相关。 
⾃软件⾏业诞⽣起,开发者们就发挥聪明才智,不断创造新的⽅法、流程和⼯具来适应和提⾼⽣产效率。互联⽹产业爆发以来,这⼀趋势更是明显:从最初的 瀑布研发流程到敏捷到精益,从持续集成到持续发布到持续部署,从实体机到虚拟机到 Docker,从本地机器到数据中⼼再到云上部署,从单体应⽤到微服务 再到⽆服务应⽤。新的⼯具、⽅法,可谓层出不穷。 
⾯对如此多的选择,如果能处理好,则开发体验好,产品发布速度快,研发过程处于⼀个持续的良性发展情况。但处理不好,就会事倍功半,出现扯⽪、重复 劳动、产品质量不好、不可维护的情况。 
微服务的不合理引⼊就是⼀个典型的例⼦。⾃从亚⻢逊成功⼤规模地应⽤后,微服务逐渐形成⻛潮,很多公司在不清楚适⽤场景的情况下盲⽬采⽤,结果是踩 了很多坑。 
⽐如,我⻅过⼀个初创公司,在业务还没开展起来的时候,⼀上来就采⽤微服务,因为没有要求⼀致的技术栈,也没有限制服务的⼤⼩,于是开发⼈员怎么⽅ 便怎么做,只考虑局部优化⽽忽视了全局优化。半年下来,20 ⼈的开发团队搞出了 30 多个服务和 5 种开发语⾔。服务之间的调⽤依赖和部署上线越来越复 杂,难以维护,每次上线问题不断,经常搞通宵才能让服务稳定下来。同时,知识的共享⾮常有限,有好⼏个服务只有⼀个⼈了解情况,⼀旦这个⼈不在的时 候这个服务出现问题,解决起来就基本上成了“不可能的任务”。这样的错误使⽤微服务的公司⾮常普遍。 
那,到底怎样才能有效地提⾼研发效能呢?硅⾕的业界标杆公司⼜是怎么做到⾼效能的呢? 
只有深⼊研发活动的本质,才能提⾼效能 
我的建议是,提⾼研发效能,需要深⼊了解研发活动的本质,从纷乱的表象和层出不穷的⽅法中,看到隐藏的模型,找到根本原则,然后从这些原则出发,具 体问题具体分析,找到合适的⽅法。这样做的原因是,软件研发很灵活,在实践的时候总会遇⻅各种不同的情况。越是灵活的东⻄,就越需要理解其本质,这 样才能做到随机应变。 
在 Facebook 的时候,我们做事时都遵循⼀些基本原则。⽐如,有⼀个原则是“不要阻塞开发⼈员”,贯穿在公司的很多研发和管理实践中。接下来,我给你 举两个具体的应⽤场景,来帮助你理解这个原则。 
第⼀个应⽤场景是,本地构建脚本的运⾏速度要⾜够快。开发⼈员在⾃⼰的开发机器上写完代码之后,都要运⾏这个脚本进⾏构建,把新做的改动在⾃⼰的开 发机器沙盒环境上运⾏起来,以⽅便做⼀些基本检查。 
这个操作⾮常频繁,所以如果它的运⾏时间太⻓,就会阻塞开发。因此,确保这个脚本的快速运⾏就是内部⼯具团队的⼀个超⾼优先级的任务。我们对每次脚 本的运⾏进⾏埋点跟踪,当运⾏时⻓超过 1.5 分钟后,就会停下⼿中的⼯作,想尽⼀切办法给这个本地构建加速。 
第⼆个应⽤场景是,商⽤软件的采购。对⼀定数额下的软件购买,开发⼈员可以⾃⾏决定,先斩后奏。⽽且那个数额还蛮⾼的,覆盖⼀般的软件完全没问题。 
我个⼈就经历过两次在晚上加班时,要购买⼀个商业软件的情况。如果等主管审批,就需要到第⼆天。但,公司信任⼯程师能够在这样的情况下做出利于公司 的决定,所以我可以直接购买并使⽤。这样⼀来,除了能提⾼这⼏个⼩时的开发效率外,更重要的是,我觉得⾃⼰拥有信任和权⼒,⼯作积极性更加⾼涨。 
这两个应⽤场景差别很⼤,却都是基于“不要阻塞开发⼈员”这个原则。Facebook 之所以会有这个原则,正是因为它认识到了,开发流程的顺畅是⽣产优质软 件的关键因素,只有这样才能最⼤程度地释放开发者的创造性和积极性。相⽐之下,很多公司更注重强管理下的流程和制度,⽽忽略了开发的顺畅,结果是开 发⼈员⼯作起来磕磕绊绊,⼜谈何⾼效率呢。 
看到这⾥你会说,我已经很清楚地知道,要想提⾼研发效能,就必须理解软件开发的本质。那么,软件开发的本质到底什么呢? 
接下来,我就和你探讨⼀下软件开发的本质特点,然后基于这些特点,搭建出⼀个研发效能的模型,希望你可以灵活运⽤,找到提⾼研发效能的主要着⼒点。 这个思路,将是贯穿整个专栏的主线索
研发效能的模型是什么? 
在我看来,软件开发本质上就是⼀条超级灵活的流⽔线。这个流⽔线从产品需求出发,经过开发、测试、发布、运维等环节,每⼀个环节的产出流动到下⼀个 环节进⾏处理,最后交付给⽤户。 
图 1 软件开发的流水线
另外,这条流⽔线的每个环节都还可以细分。⽐如,本地开发环节可以细分为下⾯⼏个部分:
 
图 2 本地开发流水线
这种流⽔线⼯作⽅式,在传统的制造业中很普遍,也已经有了很多经验和成功实践。最典型的就是汽⻋⽣产中使⽤的丰⽥⽣产体系(Toyota Production System,TPS)。所以,我们可以参考传统制造⾏业的经验来提⾼效能。 
事实上,瀑布模式就类似于传统流⽔线的处理⽅法:它强调每个环节之间界限分明,尽量清晰地定义每⼀个环节的输⼊和输出,保证每⼀个环节产出的质量。 但,和传统制造业相⽐,软件开发⼜具有超强的灵活性,体现在以下 4 个⽅⾯。 
1. 最终产品⽬标的灵活性。传统流⽔线的⽬标确定,⽽互联⽹产品的最终形态通常是在不断地迭代中逐步明确,相当于是⼀个移动的标靶。尤其是最近⼏ 年,这⼀灵活性愈发明显。⽐如,在精益开发实践中,常常使⽤ MVP(最⼩可⾏性产品,Minimal Viable Product)来不断验证产品假设,经过不断调整 最终形成产品。 
2. 节点之间关系的灵活性,⽐如流⽔线上的多个节点可以互相融合。DevOps 就是在模糊节点之间的边界,甚⾄有⼀些实践会直接去掉某些环节,或者融⼊ 到其他环节当中。 
3. 每个节点的灵活性。每⼀个⽣产环节都会不断涌现出新的⽣产⽅式 / ⽅法。⽐如测试,最近⼗多年就产⽣了测试驱动开发、Dogfood(狗粮测试)、测试 前移等⽅法;最近⼜出现的测试右移,开始强调在⽣产环境中进⾏测试。 
4. 每个节点上的开发⼈员的灵活性。跟传统制造业不同,流⽔线上的每⼀个⼯作⼈员,也就是每个开发者,都有很强的灵活性,主要表现在对⼀个相同的功 能,可以选择很多不同的⽅式、不同的⼯具来实现。 ⽐如,之前我在 Facebook 做后端开发的时候,同样⼀个代码仓,有的同事使⽤命令⾏的编辑环境 VIM/Emacs,有的使⽤图形界⾯ IDE,有的使⽤ WebIDE;在实现⼀个⼯具的时候,⼤家可以⾃⼰选择使⽤ Python、Ruby 或者 PHP。这其中的每⼀个选择,都很可能影响效能。 基于这些特点,我们可以从以下 4 个⽅⾯去提⾼研发效能。
基于这些特点,我们可以从以下 4 个⽅⾯去提⾼研发效能。 
图 3 研发效能模型 
1. 优化流程,主要针对特点 1 和 2,也就是最终产品⽬标的灵活性和节点间关系的灵活性,进⾏优化。具体来说,针对最终产品⽬标的灵活性,主要是提⾼ 流程的灵活性,让它能聚焦最终产⽣的⽤户价值,以终为始地指导⼯作,击中移动的标靶。⽽针对节点之间关系的灵活性,则主要聚焦流⽔线的顺畅,以 保证⽤户价值的流动受到的阻⼒最⼩。 
2. 团队⼯程实践,主是针对特点 3,也就是每个节点的灵活性进⾏优化,聚焦每⼀个⽣产环节的⼯程实践进⾏提⾼。 
3. 个⼈⼯程实践,主是针对特点 4,也就是每个节点上开发⼈员的灵活性,来提⾼个⼈研发效能。争取让每个开发⼈员都能适当地关注业务、以终为始,同 时从⽅法和⼯具上提⾼开发效率,实现 1+1>2 的效果。 
4. ⽂化与管理。任何流程、实践的引⼊和推⼴,都必须有合理的管理⽅法来⽀撑。同时,⽂化是⼀个团队⼯作的基本价值观和潜规则。只有建⽴好⽂化,才 能让团队持续学习,从⽽应对新的挑战。所以,要提⾼效能,我们还需要⽂化和管理这个引擎。 
优化流程、团队⼯程实践、个⼈⼯程实践,以及⽂化和管理,就是我们提⾼研发效能需要关注的 4 个⽅⾯,也就是我们所说的研发效能模型。 
在接下来的⽂章中,我会以这个模型为基础,从以上这 4 个⽅向与你介绍硅⾕公司,尤其是我最熟悉的 Facebook 的成功实践,并着重向你讲述这些实践背 后的原理。因为只有理解了这些原理和原则,我们才有可能在这个超级灵活和⾼速发展的软件开发⾏业⾥⻅招拆招,⽴于不败之地。 
总结 
在今天这篇⽂章中,我和你再次强调了研发效能是团队能够持续为⽤户产⽣有效价值的效率,包括有效性、效率和可持续性 3 个⽅⾯。 
⽽关于如何提⾼效能,我的建议是深⼊了解研发活动的本质,从纷乱的表象和层出不穷的⽅法中,看到隐藏的模型,找到根本原则,然后从这些原则出发,具 体问题具体分析,找到合适的⽅法。 
最后,我借鉴传统制造业流⽔线的形式,并结合软件开发的特定灵活性,总结出了研发效能的模型,主要包括优化流程、团队⼯程实践、个⼈⼯程实践、管理 与⽂化。专栏的后续内容,我将分为这 4 ⼤模块,帮助你提⾼团队和个⼈的研发效能。 其实,研发效能对于硅⾕的公司和个⼈来说,已经是常识,⽽我在美国⼯作的 10 多年,也已经习惯了这种⼯作⽅式。回国之后,我深⼊了解了国内的开发情 况,对效能关注不到位的现状颇为吃惊。因为这不符合软件开发这个⾏业的基本特性,也限制了国内软件⾏业的发展。 
同时,我也对国内开发⼈员的⽣存环境,感到些许遗憾。本来软件开发是⼀个可以充分发挥创造性的、有趣的⾏业,技术的发展有⽆尽的空间。但是,开发⼈ 员却常常被业务拖着跑,技术发展和创造性都被限制住了。另外,因为拼时⻓的做法,也伤害了开发者的身体健康和家庭关系。 / 正是因为这些惊讶和遗憾,我将这⼗⼏年对研发效能的理解与实践,做了⼀次系统梳理,于是就有了今天提到的研发效能模型。我希望这种系统化的模型⽅ 法,能够为国内软件团队的效能提升提供⼀些参考和引导,也希望能够提升开发者个⼈的技能,以节省出时间来体会研发的快乐,提⾼⽣活的幸福感。 
思考题 
你有⻅过 996 对团队和产品造成伤害的具体事例吗? 
感谢你的收听,欢迎你在评论区给我留⾔分享你的观点,也欢迎你把这篇⽂章分享给更多的朋友⼀起阅读。我们下期再⻅!

发表评论

您的电子邮箱地址不会被公开。