大家好，我是李倩，来自上海，是 KodeRover 的创始人 & TGO 鲲鹏会会员。很高兴能跟大家聊聊关于研发效能的话题，尤其是效能的量化和度量。通过度量认清短板固然重要，但靠度量提升效能却很难，特别是在工程能力不足的情况下做度量，甚至依赖度量制订绩效，都很容易出现问题。
既然提升效能如此困难，我们就来探讨一下，如何分步骤、阶段性地真正提升效能。
一、提升软件交付效能的关键之处
所谓技术研发，就是通过开发软件为企业带来业务价值。那么软件交付效能是什么？它指代生产软件持续为用户产生有效价值的效率，可以理解为三个关键词：有效性、效率、可持续性。
一、有效性：关注产品是否能为客户、公司带来价值；
二、效率：关注团队能否快速生产和发布产品、快速应对市场需求变化和企业业务目标；
三、可持续性：小团队做小业务，可能没问题；随着业务规模和团队规模的成倍增长，还能有效控制研发效能吗？这就是可持续性探究的问题，也是很容易忽略的一点。
为什么要提升软件交付效能？这主要为了企业长远发展和让企业有持久竞争力。
如何提高软件交付效能？首要任务，就是改善研发人力投入结构，动态平衡时间、成本、质量三者之间的关系。
常有人问，研发团队到底应该怎么搭建，或者说，成熟团队的结构是什么样的？其实没有标准答案，一切取决于业务形态，组织结构要围绕业务或企业成本来规划建设。举个例子，如果企业要推出一款产品，就应该围绕产品建立交付架构，如常见的 PO(Product Owner) 模式，产品负责人为产品的 ROI 负责。如果预算是 1000 万，就要用 1000 万 去搭建一个可以完成产品商业目标的团队。团队角色可能只有开发人员，也可能包含产品经理、QA、开发人员，甚至可以招募运营人员。
一个商业单元，一切要以价值为导向改善人力投入，没有固定的岗位比例建议。以完成确定的商业目标为依据，制造所有可能的、必要的资源和岗位。
软件交付效能不是技术团队可以单独决定的，尤其在涉及到 ToB 环节时，链路很长。分析一下链路中的利益相关方就会发现，CPO 对企业生存发展负责，通过识别商业价值，使产品经理能够完成实际的需求定义；接下来，技术团队才能推进实现和研发交付；最后，市场和销售观测、验证市场反馈，服务团队进行客户支持和响应，接着开始新的一轮软件交付周期。
所以，软件交付管理的过程，要从商业识别到客户服务的端到端开始管理，是端到端的价值流动和需求响应，既不是从产品经理拿到需求的那一刻开始，也不是到代码上线就结束了。
在研发交付环节，最大的痛点是如何在保证研发速度的情况下，兼顾质量。一个相对完整的产品上线之前需要大量的验证与运维工作，开发完成后有很多工作要做，比如部署测试验证时间经常会超过代码编写时间，环境和构建问题也是团队消耗大量精力的地方。
代码质量差，导致测试人员投入大量精力用来验证和返工；交付流程管理不规范、不合理，导致从上游传递下来的信息缺失，让运维非常痛苦，承担了很大的上线风险。
综合看来，效能低的外在表现就是需求响应慢、交付周期长、事故多、服务能力下降，进而导致企业无法快速进行创新创造。
如何解决交付困境，大家也想了很多办法，比如说有些企业通过规范一整套流程来约束每个阶段的产出规范，也有团队为了验证业务隔离环境，实现了七、八套测试环境，但这样真的能提高效率吗？
二、交付的挑战和变革
做软件研发的核心是处理人、技术、流程之间的关系，目标是在三者间建立良好的关系与合理的机制。
其中包含四个关键点：
1、人的服务化：建立面向开发者的服务体系，将支撑部门 BP 化；
2、组织效能的数字化：面向流程、工程、业务指标、技术建立多层次的效能度量体系；
3、技术的云原生化：充分运用云技术提升 IT / Infra 使用效率与开发人员生产力；
4、流程的工程化：简化流程体系，用工程代替流程，流程越精简越好。
最终四个关键点回归一个最简单的逻辑：帮助开发者生产高质量的代码，上线到生产环境，并为客户提供服务。大家对 HRBP(HR BUSINESS PARTNER) 的概念耳熟能详，其实研发内部也一样。开发者是主体，其他都是 BP，只要能帮助优质代码上线，无论怎样为开发者提供服务都不为过。
按照这样的思路，所有面向业务交付的部门都应该是一个单元。也就是说，QA、SRE 都应该下沉到业务，而不是业务方层层审批获得资源。当某个部门、组织不是面向业务交付时，它就只是一种职能化的存在，无法很好地体现价值。
支撑部门 BP 化以后服务目标如何定，核心价值又如何体现呢？这里效能度量体系提供了一种思路。通过建立度量，整个过程清晰可见，知道到底发生了什么，比如说效率和质量怎么样，中间协作过程是否顺利，哪些因素有利于开发者上线，哪些因素是瓶颈？支撑部门也逐步从成本中心转向服务中心，与业务建立关联，体现核心价值。
我们回到本质，提升研发效能要解决的是开发者的问题，而不是管理者的问题。大部分技术管理者，很容易从自己的角度出发，思考应该怎么去管理研发。实际上恰恰相反，开发者才是主体，管理者应该思考如何将他们的价值发挥到最大。所谓的“996”，只是一种形式而已。
面向开发者建立服务体系的思路，在国外已经非常成熟，Facebook 的持续开发过程聚焦的正是让开发者毫不费力地完成代码的提交和验证过程。
Facebook 的持续开发过程大体如下：
1、开发人员负责 UT 和 IT，在本地开发机器上进行开发、包括本地的编码、调测、单元测试等；提交 PR(Pull Request)，云端执行完整的测试过程，并行运行包含静态检查、单元测试、集成测试、安全测试，以及性能测试等；
2、测试通过后，是 Phabricator 的机器 CR(Code Review) 和人工 CR 环节，人工 CR 选择性的触发端到端的系统测试、调测，并具有一票通过和否决权，通过后入库；
3、入库后进行持续交付的自动化测试验证、灰度上线验证，目前已经能支持到 CR 级别的持续部署能力。
我们可以看到代码入库前经过的本地、云端、机器自动化测试案例和实时质量检测及基础设施都是以服务化的形式提供，可以灵活的调用。入库后的运维过程也是高度自动化的。
可见，硅谷顶尖互联网企业的流程非常轻量、灵活，而国内很多公司则设定了大量的流程框架，看上去好像是在帮助管理者明确工程师的工作内容和开发进度，实际则不然。提升效能的根源在于开发者能否顺畅的写完代码并上线。
又有些人质疑说国内外工程师有差异。那么国内外工程师水平真的相差很大吗？我不这么认为，我们中国工程师非常聪明，这种差别其实源于工程交付思维的不同。在国内，一些发展迅猛的互联网公司流程也逐渐开始采用硅谷研发方式，完成从“写完代码就完事” 到 “代码上线服务客户了才算成功” 的意识转变。工程师为自己的代码负责，没有人为其担保和托底。就像 Facebook 拥有 一万多名开发人员，却只有为数不多的产品工程师，寥寥几名运维，没有 QA，更没有繁重的流程。
三、软件交付效能演进
让我们看看，目前有哪些影响交付的因素呢？上图展示的是从想法到用户之间的距离，也展示了我们技术团队日常工作各个环节的内容。持续集成是指代码的集成，验证代码逻辑没问题。持续交付是做业务的集成，验证代码交付了正确的业务，重点关注业务的集成成功率和验证效率，目标是持续验证业务价值。
很多团队在持续集成工程实践上做的很好了，但有相当一部分团队测试或部署过程是人工的、非连续的。实现全流程的自动化是软件持续交付、效率提升的关键。
业务团队可以通过业务拆分、采用微服务架构进行并行开发，但不能连续测试、持续部署到环境中。建立持续交付能力帮助 QA 不间断地进行业务校验，提供环境或者业务验证机制，或帮助开发自主验证。优秀的工程实践是把共性的部分，即每个人都要花大量时间的部分自动化掉。
我在长期做一个“工程师自己认为时间花在何处”的调查。统计结果显示，仍然有 55% 的工程师认为自己在做杂事，很少有时间安心写业务相关的代码。这很奇怪，作为工程师大部分时间却不在写代码。如果我们能将没有时间写代码的问题解决掉，效率就能提升。
上图展示的是持续交付的演进阶段。这里非常有必要提一下分支管理，分支管理与工程成熟度密切相关，比如 Facebook 是主干分支模式，合并负担和流程都非常轻量，可以把持续集成和持续交付做到极致，频繁入主仓集成检验，而大部分公司采用主干分支加功能分支或者 Git Flow。
根据图示大家可以对比下，当前很多公司还处在第二、第三阶段，有一定的自动部署能力，但没有持续交付能力。到智能部署阶段，基本具备了全面的管理能力。至于混沌工程，如果没有全量的监控能力和对整体变更的管控能力，混沌工程也很难采用。只有基础设施相对完善的情况下，混沌工程才可以常态化的实施，每个季度或者每个月提升一次系统健壮性，比如模拟炸机房故障演练等。
四、效能度量建议
我从事质量或效率工程很多年，一直在寻找一个答案：有没有一种基于指标的度量模型可以准确衡量一家公司的软件交付效能 。通过这么多年的探索，发现代码量、PR 量、覆盖率、需求数量、缺陷数量等指标都不合适，无法提升效能甚至带来副作用。那么什么样的指标更有价值？我发现基于不同的改进目标，面向人、流程、技术建立多视角的度量，根据成熟度选择适合自己企业特性和现阶段发展的指标，不仅可以提升效能还可以增进工程文化。
首先要面向过程改进，也就是流程改进，尤其需要注意打回率和各种测试的平均耗时。QA 的高打回率指标可以推动研发自测，减少返工情况。各种测试的平均耗时则显示了你花费了多少时间在验证，比如花了很长时间在 UT 上，一个同学提了一个 PR，运行了 20 分钟，如果每个人都耗 20 分钟，那其他人等这个代码集成，时间损耗就很大了，这是特别容易忽略的效率。
我很推崇从工程技术角度度量，首先这些指标最能代表核心效能，比如 CI/CD 是交付核心的效率，覆盖率是交付核心的质量指标。另外，对于工程师而言，客观逻辑至上。相比”写了多少代码，解决了多少个缺陷，完成了多少个需求“这些指标，客观技术指标非但不会损伤开发者的尊严，反而给大家更强的目标感，完全可以用于关键绩效的依据。
同时，每个企业都应该有核心的 North Star（北极星）指标，这是可以建立绩效的点，是老板关注的点，也是员工可以努力的方向。比如云服务核心服务 SLA 承诺指标，可以用做绩效考量。
当然，还要考虑事故处理能力。事故就是针对企业内在流程机制的考验，故障恢复时间可以作为核心内部作为绩效指标。
其他的指标在这里就不详细阐述了。如何选择度量指标，要取决于企业阶段性的研发运营目标是什么。比如最近对外缺陷很高，可以拿缺陷性指标去度量。另外，想要建立这样的度量体系，还需要注重自动化体系的搭建，需要有自动化能力，并且可以持续收集数据。
但请注意，不要陷入一个误区：在自动化能力不强的情况下，就去统计指标，指望通过 1-2 个月去收集到全团队指标来度量团队效能和评比，真正的度量和优化需要长久的运营。
随着时间的推移，问题驱动转向数据驱动，团队通过数据可以清楚短板在哪里，就可以定向解决这个短板，最终让研发团队从软件生产过程的数据中成长获益。
