本文作者：曾学海
1. 效能：它真的重要吗？
研发效能一直是广受关注的话题，过去十多年里我们这个行业花了非常多的钱和精力去做敏捷、DevOps、微服务等举措，目标都是希望研发团队的效能再提高一些。研发效能反应的是一家科技公司对市场环境的响应力有多高，它是一种基础能力，就好像人体做出反应有多快一样，这种基础能力的提升，会帮助人体在每一项任务上都做得更好。这是研发效能一直很受重视的原因。一家很大的商业银行的CIO曾经对我感叹说：“我们最怕的对手不是其他任何一家银行，我最怕的是Google如果有一天要做银行怎么办，Google在几乎每项任务上都比我快。”。对效能的焦虑根植于我们这个高速发展的行业中，既催生了大量的咨询业务，也催生了大量的加班。
科技公司的能力分为两部分，一类是业务能力，向市场提供具有竞争力的产品和解决方案；另一类是元能力，在企业内部推行一些方法或者工具，提高所有研发团队的速度和准确度。元能力就是“产生竞争力的能力”，市场变化会让一些业务能力过时淘汰，元能力则是可以穿越周期的立身之本。这篇文章我们专门来谈谈“速度“的问题，“准确”的问题我们以后再聊。
先来看看这个行业有多“快”：
有些数据我们没有拿到，但不妨碍我们了解一个大概的情况。如果研发团队不够快的话，会出现什么情况呢，我们观察了很多的科技公司，结论就是“一慢几乎毁所有”，以下情况是每家公司都会存在的痛苦：
需求的实现速度不够快，堆积了很多需求没有做
业务复杂，代码历史悠久，太多信息需要掌握，新人上手很慢
工作量评估没有基准，产品经理和开发人员都很焦虑，产品经理觉得下周就该上线，开发人员觉得简直异想天开。需求排期经常出现冲突
虽然有清楚的效能改进目标，例如Cycle Time、部署频次等，研发团队也知道的确有很多指标需要改进，但是缺少具体的改进办法，具体应该做什么、做到什么程度并不清楚。研发团队心里也挺着急，我怎么才能快？
企业里不同研发团队之间的差异很大，有的很不错有的差一些，公司大了这种情况肯定难免。所以很难推出一套统一的、又能对大家都适合的管理制度。这些管理动作照顾了A可能就伤害了B，到底是提高了效能，还是说只是给研发团队制造了新的工作量？
行业里面有一些可参考的资料，目前比较流行的是两个，一是Google推出的DORA框架，值得一提的是DORA是我的前同事、堪称杰出的ThoughtWorker Jez Humble建立的，后来Google收购了他的公司；二是工信部信通院提出的DevOps规范。这两套东西都非常不错，各有擅长。DORA胜在指标简单清楚、有大量数据样本作为依据、度量起来比较简单，但是它缺少细粒度的问题定位，也不提供最佳实践的指导，就好像一代名医给人看病的时候只告诉病人哪些地方有问题，但没给药方。信通院的标准胜在全面翔实，覆盖端到端的研发运维全流程，提供很多维度的知识和实践，既有流程也有指标还给出实践，非常详细完备。但这套标准的弱点也在于全面，如果不加裁剪直接采用，那么研发团队就啥也别干了，专心搞这套规范落地就已经高负荷运转了，同时让研发团队直接采用这样一套完备的规范，也容易让团队养成事事遵循流程的习惯，可能失去自主思考、自我改进的意识。
看起来好像有个中间路线：基于DORA的方法来做简单度量寻找问题，然后按需裁剪信通院的实践，按需找出需要推动的举措。听着好像还行，但需要再琢磨琢磨。
2. 办法：带来的是价值还是工作量？
话题岔开一下，我们来看一个其他行业的例子：大型综合医院。
在我的家乡成都有一家世界知名的医院：华西。它在国内的地位仅次于北京协和。这家医院每天接诊16,000人次，任何一天去这家医院都会看到这样的景象：
这里的每个医生每天接诊200-400个病人，其中40%左右的病人并不需要治疗，只需要给出轻量级的建议即可让其回家观察，例如不要抽烟、多吃蔬菜之类；30%左右需要深入检查、坚持服药；剩下30%左右需要立即住院治疗。所以医生接诊时有个重要的工作是，如何把这三类人区分开，也就是说识别出按需问诊的『需』是什么。
其实研发团队的效能诊断也差不多，没有任何一个研发团队是100%健康的，总是会有各种各样的问题，但是有问题并不意味着需要立刻强制治疗。我们看待研发团队的效能问题，目标也是让团队基本健康、不耽误快速出活就行，并不是所有问题都要全部解决。我们应该有一种研发效能的『快速分诊』，找出哪些团队需要立即『住院观察』、哪些问题需要立即解决。其他还不错的团队，就不要耽误他们继续工作，只需有针对性的提出轻量级的建议，让他们平时留意一下，继续保持健康度就行了。只要能准确的诊断出这些问题，我们这个行业有非常多的解决方法可以采纳。讲得直白一点，一个大型的研发组织，一定有一些团队和人干得不错，有一些干得不怎么样，他们分别是谁？干得好和不好的原因分别是什么？如果我们的组织不大，几十个人的团队大家都非常熟悉，互相知根知底，大家凭感觉和经验就能分析得八九不离十，但是如果组织规模很大，有两三千人甚至几万人，那就很难讲清楚了，局部的经验通常都不靠谱。
所以我们需要一个这样的研发效能改进方法：
这个工作方法中有4个非常核心的问题，这四个问题回答好了，团队的效能就肯定能提高：
如何对整个组织做快速分诊？
如何针对每个团队提出有针对性的改进措施？
如何保证改进措施可以被正确的执行？
如何验证改进措施产生了什么效果？
第一步是快速分诊，我们需要一个足够简单并且能够依靠机器自动化做检查的指标，才能对几千上万人的研发效能每天做检测，我们是这样设计的：
健康度高的团队，就应该观察他们的特征，为什么他们能干得好，是因为采用了某种流程，还是有独特的工具和方法，还是人员的能力特别强？这些特征是怎么产生的，是入职之前就掌握了，还是入职后接受了某些培训和辅导？这些特征能复制给其他团队吗？
健康度中的团队，就应该找出对应的弱点，给他们提出建议，让他们自己采取一些自治的改进措施，既不耽误他们继续干活，也能帮助他们继续提高。
健康度低的团队就不太妙了，应该派出效能顾问，深入分析到底哪些地方出了问题，提出改进方案，然后推动一些强制性的改进工作，直到该团队的健康度达到中。
只要企业具备基本的DevOps能力，就很容易利用一套自动化的脚本来做上述度量，每天都能看到每个团队的效能改进情况，辅以恰当的管理制度，就能慢慢建立起『持续改进』的工作习惯，而持续改进是研发团队能走向卓越的根因。很多团队觉得『改进』是因为自己干得不好、很丢人，这个观念是不对的，持续改进的意思就是不管你现在干成什么样，都应该去追求做得更好一点点，日拱一卒的意思，很光荣、一点不丢人。
道理呢就是这么个道理，讲出来大家都懂，我们来说点实际的，看看我们具体怎么干的。
3. 实战：说得这么热闹，有实锤的效果吗？
我们花了一个多月的时间对一家2000多人的科技公司做了咨询，首先用一套自动化的工具把2020年3至10月的Git提交数据、JIRA需求与缺陷数据、持续集成流水线全部归拢做了建模，自动化的对20个团队产出了60份诊断分析报告（每个团队三份报告），这使得我们可以在完全不接触团队的情况下掌握它的大致情况，包括这个团队的工作速率、需求质量水平、人员水平、团队结构等，从这份报告里就能看出团队可能存在的问题和改进点，然后我们再派驻咨询顾问，有针对性的去实锤这些问题，验证真实原因，然后找出最能提升这个团队的两三个改进建议。我们用其中一个团队的情况来做讲解的例子，其中的数据和人员姓名全都做了脱敏。
我们先看这个团队的代码提交报告（信息已脱敏）：
首先这个团队的代码提交频次不高，平均每人天只有0.61次提交，远低于每人天1次的提交，实际上我们很鼓励频繁提交，每个Story的每个Task完成后都应该做一次提交，这有利于更频繁的集成与发布。其他19个团队的提交频次都更高，最高的达到1.7次每人天。这个团队为何这么低，这是我们应该去调查的第一个问题。
其次我们观察到这个团队的代码提交非常集中，提交次数前三的人员比第十位的人员多出了6-7倍，这个值很不正常，同一个团队的人，前三比第7位多出3-4倍是比较常见的，多出6-7倍就需要看看原因，是前三的人员能力非常突出，还是后面的人员需要辅导，甚至可能在白日摸鱼？需要调查一下。
第三我们注意到，有几个同事代码提交频次不高，但是他的中心度非常高，这意味着他的工作内容涉及的业务领域非常多，对很多人都有影响，很多人的工作都会与他产生依赖。再结合这些人实际的技能水平，判断这部分人所承担的工作内容是否合理。是否存在高水平的人做了低价值的事情，或者低水平的人长期被分到不重要的边角工作阻碍了自身的能力提升。
这是我们从代码提交模型上看到的三个问题，很有趣。我们再看JIRA上的建模数据（信息已脱敏）：
这个模型让我们看到，缺陷数占了总任务的一半，我们需要去看看这些缺陷是如何分布的，缺陷热点在哪里，我们就应该把测试资源对应的投过去。
这个模型还给出了人员速率的评级，让我们可以看到哪些人的速度明显高于平均、达到平均、低于平均，我们不能武断的认为这直接反应员工绩效，还需要到团队里去看看情况。我们挑出一个最有代表性的名单，可以很有针对性的去观察他们的工作任务和工作习惯，找出高绩效和低绩效的原因是什么。这些特征可以帮助我们去优化员工培养与招聘。
很有意思的是这个团队在6个月里的Delay Rate是0，也就是没有任何一个Story延迟交付，这个现象在其他19个团队也是一样。这20个团队在6个月里没有任何一个任务Delay，调查后发现这个公司非常在意延迟交付这件事，当出现这个可能性的时候就会要求加班，出现延迟之后还会有较重的惩罚，这个管理措施非常“见效”，研发团队都会把工作量估计得大一些，留出足够Buffer避免延期。所以就得到一个非常杰出的数据。这种制度造成的另外一个结果就是，工作量评估成了很头疼的事情，缺少方法也没有基准参考，开发团队只要不太过分自己说多少就是多少，业务方很难挑战，真急了就拉着研发的领导吵一架，研发的领导要么顶回去要么硬拍一个上线时间。这种现象也会让读者会心一笑吧。
我们还能看到团队的平均Lead Time；每个迭代完成Story的最大值、最小值、中值；每个迭代完成Story点数的最大值、最小值、中值。这个数据单独看意义不大，但是如果能把所有团队的数据都做建模追踪，就能得到工作量评估的Benchmark，以后再估工作量就有点依据，虽然也只能做到相对准确，但是可以避免很多冲突。
第三份报告是团队的人员耦合度与代码库的耦合度（信息已脱敏）：
左边这个点状图的每个圆代表一个员工，相同颜色的人他们日常工作中的协作非常频繁，他们的代码总是互相耦合，也经常一起提交，这个信息可以帮助Leader去考虑团队的实际工作内容与规划的组织结构是否一致，是否需要重新调整，怎么安排工作内容和上班时间。
右边你这个点状图的每个圆代表一个代码库，相同颜色的代码库有更高的内聚度，经常一起修改。这个信息可以帮助Leader去考虑如何调整系统架构，可以看出模块和微服务的划分是否合理。
带着这些信息，我们派驻了2个研发效能的咨询师与团队一起工作了两天，参加他们的站会、与团队一起结对编程、参加需求沟通会和迭代会议、定向找了几个人员做一对一访谈（每人40分钟）。我们找出的改进点非常多，但是我们希望能少一些，让团队做最少的事情来提升研发效能。所以我们减了又减，提出了这几条建议，我们认为其中每一条都可以显著的提升团队的研发效能（其中的人员名字我们做了替换）：
团队的代码提交频次过低的一个重要原因是设置了固定的迭代周期（两周），我们抽样看了一些代码提交记录，结合结对编程的情况，我们看到很多提交的修改几乎没有意义，例如多次的Code Format、修改少量注释、可有可无的简单代码重构。经询问发现团队多次出现开发完成但是不做提交，等着两周迭代临近结束再提交代码的情况。同时该团队已经具备了足够的DevOps基础设施（云、容器、流水线），因此我们强烈建议开始推动持续交付，打破两周的固定迭代周期。行业内曾经认为两周一迭代是个默认选项，但是随着行业的进步，需要不断走向更快的迭代，实现持续交付。
培养团队理解Story的完成标准，提高开发的一次通过率。这个团队里有几个Junior和毕业生的同事加入公司时间不长，从数据来看他们工作很勤奋，愿意付出，但是产出的质量不高，现象就是超过70%的Story都不能一次性通过QA，都会产生平均2-4次迭代内返工，这会给开发、QA、BA都来带很高的协作成本。这些同事此前得到的培养都是了解业务流程和UI交互，但是疏忽了告诉大家什么叫做“工作完成”，很多Story并没有达到可以提交测试的标准就已经进入验收，所以返工率很高。我们建议推动一个很成熟的培训，就是让Dev正确的去拆解工作任务、正确的理解Story的验收标准，把开发工作真正做完了再提交测试，使团队的Story一次通过率达到50%以上，只是这一点就能显著的提升整体研发效能。
团队里有三个高潜力人员A、B和C，从数据来看表现很不错，但是一直在做一些边缘模块的开发，导致团队Leader主观感觉他们表现一般。核心模块是另外两个很资深的人一直在做，这两个人的中心度很低，一直工作在核心模块上，与其他人的协作很少。同时我们观察到这两个人入职时间很长，因为负责核心模块所以经常参与各种评审会、横向拉通会，成为团队的瓶颈。因此我们建议这两个人要轮流与ABC三人结对编程，让他们逐步参与核心模块，既可促进人员成长，也可改善团队瓶颈。
像这样具体到个人、立刻能实操的建议我们还能给出很多，但都不及上面三条带来的收益大，因此不再列举。
上述过程我们在一个多月里针对三个团队都做了一遍。我们发现对不同的团队来说，即使问题的现象一样，但是背后的原因都不太相同，需要采取的措施也不一样。所以如果我们不做这样的诊断，只是推出一刀切的管理措施一定会伤害一些团队，从这些研发团队的角度来看，就会觉得管理者瞎指挥，并不解决问题只是带来了工作量。而管理者则会觉得，无论这个制度如何设计，总会有人不满。团队之间的差异性很大，通过一套唯一的管理制度提升整体效能是非常困难的。
我们的工作方法已经介绍完了，最后我们来看看这家公司的管理者如何评价我们的工作。这部分的信息也非常多，我们摘取一些最有意思的内容。还是上面那个团队，我们向团队的研发经理讲解了工作过程和改进措施，他认为：
我们通过数据对团队的刻画是准确的，他打算调整一下团队的结构和分工，之后希望我们再来跑一套数据看看对比。
他作为研发经理已经做了几年的研发管理，但是从来没有得到过完备的管理培训，管理工作都是靠自己的经验。我们提供的方法很有吸引力，他希望能自己掌握然后自我改进，这是他将来作为管理者继续晋升的重要能力
希望这套工作方法可以更自动化，帮助他提前感知团队问题，出了问题再救火的话他的压力就很大
希望我们继续分析需求频繁变动、频繁返工的具体原因，在需求效能和架构分析上给出自动化的工具
希望能基于数据模型给出工作量评估的基准，解决现在缺少依据容易吵架的问题
最后的最后，我们集中了所有信息向该公司CIO做了一次汇报，我想引用这位管理者的评价作为本文的收尾：
“这种数据分析方法很有意思，我以前还没有见过用这种方式来做这件事。这个事情对我们的公司运营非常重要，你们要继续做下去。但是要先埋头打磨这套模型，向我做汇报，然后再慢慢铺开“
追求更高的研发效能是一代代IT人的目标，步伐从未停歇，目标也远未达成，未来可能也永无止境。我辈尚需努力，是为记。
免责声明：本文内容仅表明作者本人观点，并不代表Thoughtworks的立场