作者 | 泥洹
来源 | 阿里技术公众号
一 背景
项目管理的理论有很多，但大多是从理念和方法论的角度出发。当在一个团队推行项目管理的某种实践的时候，不免被挑战的一个问题：“如何衡量技术团队的效能”。于是不得不试图去把逻辑题转成数学题，用数字指标去证明一些“不证自明”的方法论。
但如果我们只是摆出一些指标，不可避免地会陷入“上有政策、下有对策”的循环（只要不加其他约束，数字还不是想怎么优化怎么优化）。我们也应该能看到这些数字背后，需要坚持的一些原则，和需要遵守的一些硬性标准。
假设目标是提高技术团队的效能，会得到如下OKR（Objectives and Key Results，目标与关键成果法）：
O：
- 提高技术团队的效能
KR：
- 增加总的价值交付率和交付质量
- 增加单位研发成本的平均交付价值
- 降低单位价值的平均交付时长
本篇侧重点在如何量化，而不是如何提高。所以接下来继续分解，我们要做的事情就是：
- 定义、衡量交付价值
- 定义、衡量研发成本
- 定义、衡量交付时长
- 细化指标
二 如何定义交付价值？
1 这里可能会存在两个误区
误区1：交付的价值就是产出的方案、代码的数量和质量
这样衡量交付价值，就很少有人愿意建设公共设施了（因为质量好不好很难量化，建设公共设施初期的耗时往往明显大于直接完成业务需求），也很少有人愿意使用公共设施（因为用别人的，不如自己建，还能拿个结果）。而对于技术团队，长期创造价值的能力，离不开公共设施的完备和对公共设施的使用。
误区2：交付的价值就是业务KPI中指标的增量
有很多功能并不带来直接的增量，或者比较难以衡量，但可能带来公司的竞争壁垒，如产品的体验。这样衡量交付价值，带来的问题就是，大家都只关注短平快的增量功能（比如营销），最终产品的竞争力下降。
2 我目前的答案：交付价值是需求背后的客户价值
不完全是技术方案、代码的数量和质量，也不完全是KPI指标的增量。交付价值就是按照用户的需要，对用户提供的整个产品、服务的数量和质量。这个定义几乎是不证自明的，但是把交付价值定义为客户价值，会不会让这件事情更加复杂，变得更加不可能量化？这就需要我们转变一下思路，通过按照优先级加权的需求的工作量来衡量。
按照优先级加权的需求的工作量代表着客户价值，这里做一些基本假设（假设不成立的场景可以作为另外的问题解决）。
假设1：技术的上游（一般是业务、产品）对于客户价值的判断是基本准确的
我们知道业务是会试错的，给业务小成本试错的机会、在业务试错的过程中沉淀一些通用的产品技术能力，往往不是局部最优，但是全局最优。
假设2：技术的上游会按照客户价值推演出优先级然后给技术提需求
假设3：技术的上游提给技术的需求是充分的（不存在业务产品人员配置的缺失而导致需求质量数量不足的情况）
基于这几个假设，上游提出的需求可能就很大程度上代表着客户价值，研发在非功能性需求方面对上游的需求做补充。
三 衡量交付价值
交付价值有个非常主观但有效的衡量方式，是上游（一般是产品业务）的满意度。背后的逻辑是，交付价值（背后代表的客户价值）往往很难量化，而产品业务的满意度，体现了技术与业务是否很好的协同，也反映了技术是否很好的交付价值。
需求的工作量不应该通过人日来评估，因为不同团队，对于相同功能点的开发时长是不同的。需求的工作量的单位应该是分解到最后的功能点数量。再细化一些，对于服务端是领域模型、领域服务数量，流程分支节点数量，对于前端、交互我不是很了解，但偏展示层可能更多的是页面区块、交互流程、行动点的数量。这些已经有量化的可能性了。
四 定义、衡量研发成本
研发成本，在一般的工程效能里面有时候会被简单的理解为人日，单纯的交付人日的衡量，其实比较简单，整个团队的 人数*工作天数。但容易被流程设计者忽视的是，站在企业成本的视角，交付人日，可能还要按照开发人员的收入进行加权。从这个角度来看，技术团队效能里面的研发成本，准确的来说就是公司对于研发的金钱投入，包括购买服务器、云服务、培训、行政投入。
这部分对于提升效能的启发是：
- 哪些功能自研、哪些功能靠购买，有时候真的得算一笔帐。
- 软件开发是一个边际成本递减的行业，如何让功能更简单的得到复用，可能是对效能提升最有帮助的部分之一（复用50个人日的功能模块，就几乎等于省了50人日的研发成本。当然也可能存在复用及后期维护的成本大于新建成本的情况，需要有良好的设计去规避）。
五 定义交付时长
我自己之前曾经陷入一个误区，认为交付时长就是从开始开发，到完成上线，这个就是交付时长。但是回到客户价值这个维度来思考，技术团队交付时长（这个时候可能说产研团队更合适一些），应该是从业务的一个想法，到验证、立项、完成发布、灰度，到最终用户可以真正使用的时长。
于是单位价值的平均交付时长，就变成了以下公式：
六 如何衡量交付时长
衡量交付时长其实也比较简单，记录下业务提出该功能的时间以及功能开发的时间。难点可能是整个价值流交付过程中细化的指标，而细化的指标更能帮助我们发现问题。于是我们可以从一般项目的生命周期来看，哪些节点的时长会影响我们的交付：
- 需求立项到评审的时长
- 需求评审到技术方案评审的时长（如果项目很大可能会有多个层次的设计方案）
- 技术方案评审完成到开发完成自测的时长
- 自测的时长
- 多端联调的时长
- 测试的时长
- bug验证的时长，bug的数量（reopen可以数量+1）
- 环境部署等待的时长
- 代码合并的时长（主干发布的情况下）
- 回归的时长
- 发布的时长
- 灰度的时长
这部分对于提升效能容易忽视或有启发的点是：
- 需求的拆分成基本的功能闭环进行迭代（以不引入或少引入测试的重复回归为标准），或许能比较有效的降低需求价值量的平均交付时长。
- 自测充分、减少bug数量，最终减少联调、测试回归的次数和时长，在一定的单测覆盖率要求以前，是收益大于成本的。
- 代码合并有时候冲突解决很麻烦，会导致一次部署的时间很长，且代码合并引入了更多次的测试回归工作（这可能是某些BU往主干开发分支发布走的原因之一）。所以基于业务的理解，进行应用的拆分，减少单个应用的并发数量，也可以提升研发效能。
- 在缺乏有效的项目管理的情况下，资源的相互等待可能是项目延期的一大因素，有时候某端开发完了，另一端资源没到位，一直不能联调提测。项目管理的同学对于资源目前的分工和瓶颈应该给上游及时的反馈。
容易陷入误区的点是：
- 技术方案（架构、详细设计）的评审既然是很大的一块耗时，是不是可以直接写代码，少写方案。我理解在技术方案写不熟练的情况下，写技术方案确实比较耗时。但是技术方案体现的是分析设计的过程和结果，这部分如果不写出来，增加的是大量的沟通成本。而分析设计就算不写出来，这部分工作量在编写代码的时候也是没办法省略掉的，只是变成了在大脑中进行（也许在大脑中真的不如在纸上写出来来的快和清晰，真的省略了设计，最终就会成为技术负债）。我个人感觉对于多大的需求需要技术方案评审的比较好的实践，是以Code Review能否不基于技术方案直接阅读代码为准。
七 最后
但我仍然认为，好的量化的指标往往是好的结果的必要不充分条件。简单粗暴的优化某项指标往往会因为两个问题而使得最终的结果背道而驰：
- 某项指标变好，带来的是其他指标的降低，局部最优并非全局最优（如：取消技术方案的编写和评审，造成的是编码时间或者后期维护时间的增加）。
- 效能是多个变量共同作用的结果，缺乏理论基础和方法论的情况下，很可能在短期优化指标的时候，忽略了长期的团队成长、系统能力沉淀等因素；或是忽视了业务方满意度等难以量化的因素。
所以，效能的优化，不止应该有指标，还应该有路径，而路径往往是最难的部分。
