衡量一个技术团队的效率，难道只是一堆数字指标吗？对交付价值的定义有哪些常见的误解？好的量化指标就一定会带来好的结果吗？本文从定义出发，从交付价值、研发成本、交付时间、具体指标四个方面分享如何量化绩效。1研究背景项目管理的理论很多，但大多是从哲学和方法论的角度出发的。当项目管理的某种实践在团队中实施时，难免会受到挑战：“如何衡量技术团队的有效性”。于是只好尝试把逻辑问题变成数学问题，用数值指标来证明一些“不言而喻”的方法论。但如果只是出一些指标，难免陷入“政策在上，对策在下”的怪圈（只要不加其他约束条件，数量不是怎么优化就怎么优化）。我们也应该能够看到这些数字的背后，有一些需要坚持的原则，有一些需要遵循的硬性标准。假设目标是提升技术团队的绩效，将得到如下OKR（ObjectivesandKeyResultsmethod）：O：提升技术团队的绩效KR：提高总价值交付率和交付质量平均单位研发成本交付价值减少单位价值的平均交付时间本文重点关注如何量化，而不是如何提高。所以继续分解，我们要做的就是：定义，衡量交付价值的定义，衡量研发成本的定义，衡量交付时间。价值就是产出计划，代码的数量和质量，交付价值这样衡量的时候，很少有人愿意去建设公共设施（因为质量好不好很难量化，而且公共设施建设初期的耗时往往明显大于直接完成业务需求），很少有人愿意使用公共设施（因为用的是别人，还不如自己建，自己可以仍然得到结果）。对于技术团队而言，长期创造价值的能力离不开公共设施的完善和使用。误解二：交付的价值是业务KPI指标的增量。很多功能并不能带来直接的增量，或者难以衡量，但可能会给企业带来竞争壁垒，比如产品体验。这样衡量交付价值的问题在于，大家只关注短平快的增量功能（比如营销），最终产品的竞争力下降。2我目前的回答：交付价值是需求背后的客户价值。不完全是技术方案，代码的数量和质量，也不完全是KPI指标的增量。交付价值是指根据用户的需要，向用户提供的整个产品和服务的数量和质量。这个定义几乎是不言自明的，但是把交付价值定义为客户价值，会让这件事变得更加复杂，无法量化？这就需要我们转变思路，用优先级加权的需求工作量来衡量。根据优先级加权的需求工作量代表客户价值，这里做了一些基本假设（不成立的场景可以作为另一个问题来解决）。假设一：上游技术（一般是业务、产品）对客户价值的判断基本准确。我们知道商业会经历试错，所以给商业以低成本试错的机会，在商业试错的过程中积累一些通用的信息。产品技术能力往往不是局部最优的，而是全局最优的。假设2：技术上游会根据客户价值推导出优先级，然后提供有需求的技术假设3：技术上游提供的技术需求充足（不缺少业务产品人员配置）导致需求质量和数量不足）基于这些假设，上游提出的需求可能很大程度上代表了客户价值，研发在非功能需求方面对上游需求进行补充。3.衡量交付价值有一个非常主观但有效的衡量交付价值的方法，就是上游（通常是产品业务）的满意度。其背后的逻辑是交付价值（背后代表的客户价值）往往难以量化，而产品业务的满意度反映了技术和业务是否协调好，也反映了技术是否善于交付价值。需求的工作量不应该以人天来衡量，因为不同的团队对于同一个功能点的开发时间是不同的。所需工作量的单位应该是分解到最后的功能点数。更详细地说，服务器是领域模型，领域服务的数量，流程分支节点的数量。前端和交互了解不多，部分展示层可能更多的是页面块数、交互流程、动作点数。.这些已经是可以量化的可能性。4、研发成本的定义和计量研发成本有时被简单理解为一般工程效率中的人日。简单交货人日的衡量其实比较简单。整个团队人数*工作天数。然而，流程设计者容易忽视的是，从企业成本的角度来看，交付人日也可能会根据开发者的收入进行加权。从这个角度来看，技术团队效率中的研发成本恰恰是公司投入研发的钱，包括购买服务器、云服务、培训、行政投入等。这部分对性能提升的启发是：哪些功能是自研的，哪些功能是购买的，有时候真的要计算一下。软件开发是一个边际成本递减的行业。如何让功能更容易复用，可能是对性能提升最有帮助的部分之一（复用50人天的功能模块，几乎相当于节省了50人天的研发成本。当然，也有可能成本高的情况再利用和后期维护的成本大于新建的成本，这需要良好的设计来避免）。5、定义交付时间我自己之前也陷入了一个误区，认为交付时间是从开发开始到完成上线，这就是交付时间。但是回到客户价值的维度，技术团队的交付时间（这个时候可能说产研团队更合适）应该是从一个商业idea，到验证，立项，发布完成，灰度化，最终用户可以实际使用时长。因此单位价值的平均交付时间就变成了下面的公式：6如何衡量交付时间衡量交付时间其实比较简单，记录业务提出功能的时间和开发功能的时间。难点可能是整个价值流交付过程中的精细化指标，精细化的指标可以帮助我们更好的发现问题。所以我们从一般项目的生命周期可以看出，哪些节点长度会影响我们的交付：从需求立项到评审的时间长度从需求评审到技术方案评审的时间（如果项目很大，可能会有多个设计方案层次)从技术方案审核到开发完成的时间自测时间自测时间多端联调测试时间Bug验证时间，Bug数量（重开数+1）环境部署等待时间代码合并时间(trunk在release的情况下)regression长度therelease长度thegrayscale长度这部分很容易被忽略或者对提升性能有指导意义：将需求拆分为基本的功能闭环迭代（为了不引入或引入少repetitionoftestsRegressionasthestandard），或许能有效降低需求值的平均交付时间。充分的自测，减少bug的数量，最终减少联调和测试回归的次数和持续时间，在一定的单测覆盖率要求之前，收益大于成本。代码合并有时解决冲突很麻烦，会导致部署时间很长，而且代码合并引入了更多的测试回归工作（这可能是部分BU发布到主开发分支的原因之一）。因此，基于业务理解，拆分应用，降低单个应用的并发数，也能提高研发效率。在缺乏有效的项目管理的情况下，资源的相互等待可能是导致项目延误的主要因素。有时一端开发完成了，另一端的资源却没有到位，一直无法联调联测。项目管理同学要及时向上游反馈目前的分工和资源瓶颈。容易陷入误区的一点是：既然技术方案（架构、详细设计）的review是一大块耗时的，能不能直接写代码，少写方案。我明白，如果不熟练写技术方案，写技术方案真的很费时间。但技术方案反映的是分析设计的过程和结果。如果这部分不写，会增加很多沟通成本。而且即使分析设计不写出来，这部分工作量在写代码的时候也不能省略，而是变成了在脑子里完成（可能真的没有写在纸上那么快速清晰），真的省略了设计，最终将成为技术债务）。个人感觉技术方案review比较好的做法是看CodeReview能不能不基于技术方案直接看代码。七最后，但我仍然认为，好的量化指标往往是取得好结果的必要但不充分条件。对某个指标进行简单粗暴的优化，往往会因为两个问题导致相反的结果：某个指标的提升带来其他指标的降低，局部最优不是全局最优（比如取消技术准备）解决方案和审查，导致编码时间或后期维护时间增加）。效率是多个变量共同作用的结果。在缺乏理论依据和方法论的情况下，在缺乏短期优化指标的情况下，很可能忽视了长期的团队成长和系统能力沉淀等因素；或业务满意度被忽略。难以量化的因素。所以，性能优化不仅要有指标，更要有路径，而路径往往是最难的部分。
