渐进式的研发管理改进之路

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

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

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

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

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

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

约束理论

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

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

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

首先，交付团队必须完全了解所有产品及其细节，否则会导致团队在做优化需求时，最终产出的产品质量不高。

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

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

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

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

• 需求每月新增 15-20 个，大量的需求在等待研发

• 规模预估每月需要完成 15-20 个，且预估时间半天到一天不等

• 无论是何种缺陷都需要立即响应，经常打断研发

• 研发完成的需求在开始测试后仍然需要研发投入去修复测试缺陷

1. 设立优化需求的 SLA（服务级别协议）响应等级，以粗略预估替代精准预估，从而大大降低团队用于需求预估的时间，将更多的资源用于直接产生客户价值的活动中去。

2. 将研发中和研发完成一并设置 WIP（在制品） 限制，减少「接近完成」的需求，从而加速价值流动。

3. 设立缺陷的 SLA，严重缺陷可临时突破 WIP 限制。通过看板，我们对缺陷进行优先级管理，并可视化地展现缺陷的处理流程和处理情况，让上下游团队更清楚地了解研发团队的研发能力，配合研发团队调整自己的需求的优先级。

4. 每月基于看板召开需求规划会，和上下游协商 Backlog 中的需求优先级。

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

改进后：需求周期可预测

改进后：待研发需求数量

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

• 排查并分析缺陷中的客户服务问题，成立独立部门应对，让研发团队更专注

• 分离路线图需求，与上游部门和产品部门协商响应策略

• 扩大团队规模，提升 WIP 的限制

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

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