GTLC 全球技术领导力峰会 | 渐进式的研发管理改进之路

10 月 17 日，ONES 出席 2021 全球技术领导力峰会-杭州站（简称“GTLC 大会”）。大会上，ONES 研发总监、ONES Core 业务中台负责人陈亮宇作了题为《渐进式的研发管理改进之路》的演讲，与各行各业的技术大咖一起，分享 ONES 的研发效能提升实践经验。

以下是陈亮宇演讲的主要内容。

研发管理中的噪声

研发管理是一个庞大的体系，需要从「大处考虑，小处着眼」。在实践过程中，企业管理者往往会制定大的目标，但在「小处」实施的时候会遇到各种各样的困难。这些困难的根本原因是整个研发效能改进过程中存在很多「噪声」。

2002 年诺贝尔经济学奖获得者丹尼尔·卡尼曼在其新书《噪声》中表示，「噪声」是指决策过程中不必要的随机变异性。哪里有判断，哪里就有「噪声」。

研发效能改进的过程中本身会存在很多判断，自然会产生很多噪声。而这些噪声大多是隐形的，你看不到它却会被它所影响。

以下是研发过程中的三种常见「噪声」。

第一种是执行预测性决策而产生的「噪声」。在推动敏捷、DevOps 等管理方法落地的过程中，团队往往需要进行组织架构的转型。这是一件风险较大的决策，需要公司管理层的信任与支持，而做这种预测性决策会产生随机变数。

第二种是目标理解偏差导致的「噪声」，其中目标理解偏差是比较常见的。例如，企业管理者的 OKR 是「提升研发效能 20% 」，这个目标拆分到不同部门后，测试部门认为要将测试效能提升 20%，而研发团队认为要将研发效能提升 20%。但其实管理者想要的是实现整个研发流程中端到端的研发效能提升，这就是目标理解偏差上的噪声。

第三种是主观情绪变化导致的「噪声」。研发过程改进通常会改变团队的工作流程和一线员工的工作习惯。要求一线员工离开自己熟悉的工作方法是一件”反人性“的事情，员工可能会产生一些抗拒感，从而影响改进措施最后完整落地。

由此可见，研发效能改进是由多因素多环节相互影响的复杂活动。《易经》中提到「易则易知，简则易从；易知则有亲，易从则有功」，这一思想可以应用到效能改进落地过程中，化繁为简，采用简单的渐进式的改进措施，使其容易被团队理解、执行，从而减少整个研发效能过程中的噪声影响。

化繁为简

渐进式的研发效能改进

研发流程其实是价值流动的过程。我们将研发流程想象成一条公路，研发效能提升就是清除这条路上可能产生的障碍（如道路变窄、交通事故等），避免因为一个道路障碍而产生越来越多的障碍，最终导致堵车。

我们可以利用「约束理论」来进行研发过程中的「道路疏通」。约束理论是指，实际业务中瓶颈节点的节拍决定了整个业务流程，它分为五个步骤，分别是：识别约束、用尽约束、配合约束、突破约束，然后再回到第一步来，进行循环改进。根据这个理论，我们可以不断地识别瓶颈、突破瓶颈，最终实现效能的渐进式改进。

约束理论

以 ONES 团队的效能改进实践为例。

ONES 成立了交付团队以响应客户的需求，提升客户满意度。随着时间推移，团队的效能提升出现瓶颈。我们首先想到了增加团队规模、提高团队人员素质或者通过引入自动化的流程改善团队效能。然而上述每一种方法都要求投入大量的资源，甚至可能需要团队暂停业务进行改进，这并不现实。因此，ONES 采用了渐进式的改进方法。

我们从分析交付团队的核心困境入手。

首先，ONES 产品矩阵丰富，已经发布了 8 款产品，交付团队必须完全了解所有产品及其细节，否则会导致团队在做优化需求时，最终产出的产品质量不高。

其次，客户对需求有预期的交付时间，团队花费大量时间进行工时预估并给出一个较精准的时间。但由于开发过程中的种种复杂因素导致交付延期，而需求也不断累积，最后，即使小的优化也需要很长的时间响应，最终导致业务满意度降低。

再者，客户的需求数量和需求提出时间具有极大的不确定性，新需求的预估会打断团队当前的迭代研发，导致效能降低。

与此同时，在面对大大小小的线上缺陷时，ONES 交付团队全盘响应，处理缺陷也会打断研发工作。

为了解决上述问题，ONES 对交付团队进行了效能分析：

• 需求每月新增 15-20 个，大量的需求在等待研发
• 规模预估每月需要完成 15-20 个，且预估时间半天到一天不等
• 无论是何种缺陷都需要立即响应，经常打断研发
• 研发完成的需求在开始测试后仍然需要研发投入去修复测试缺陷

改进前：需求周期时间离散

改进前：待研发需求高于发布需求

综合分析后，我们最终确定交付团队效能提升的约束就是研发环节，并为此制定了解决方案：

• 设立优化需求的 SLA（服务级别协议）响应等级，以粗略预估替代精准预估，从而大大降低团队用于需求预估的时间，将更多的资源用于直接产生客户价值的活动中去。
• 将研发中和研发完成一并设置 WIP（在制品） 限制，减少「接近完成」的需求，从而加速价值流动。
• 设立缺陷的 SLA，严重缺陷可临时突破 WIP 限制。通过看板，我们对缺陷进行优先级管理，并可视化地展现缺陷的处理流程和处理情况，让上下游团队更清楚地了解研发团队的研发能力，配合研发团队调整自己的需求的优先级。
• 每月基于看板召开需求规划会，和上下游协商 Backlog 中的需求优先级。

我们对改进措施进行了持续观测，实施两三个月后，团队的需求周期时间新增集中在了 5 天、10 天、20 天，交付时间可预测性增强。同时，待研发需求数量持续下降并稳定在了健康水平，并行的任务也维持在了 2-3 个，研发流程的瓶颈环节得到一定的疏通。

改进后：需求周期可预测

改进后：待研发需求数量

为更大程度地完成疏通，接下来便是突破约束。为此，我们还做了三件事：

• 排查并分析缺陷中的客户服务问题，成立独立部门应对，让研发团队更专注
• 分离路线图需求，与上游部门和产品部门协商响应策略
• 扩大团队规模，提升 WIP 的限制

在渐进式的研发改进实践中，团队效能和业务满意度都得到了明显的提升。从 ONES 团队的渐进式效能改进经验中，我们总结出两个核心理念：

首先，最大化利用非瓶颈资源只会造成堆积和等待，效能改进需要聚焦疏通瓶颈，让改进变得落地简单可执行。

其次，渐进式的研发效能改进能在短期内给团队正向反馈，从而提升团队的自驱力。同时也能通过提升需求的可预测性，有效地提升业务的满意度，建立透明、信任的团队氛围。