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

这是一篇转自 ONES 企业公众号的一篇分享。文中有许多关于看板方法的很好的思考与实践!

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 个,且预估时间半天到一天不等
  • 无论是何种缺陷都需要立即响应,经常打断研发
  • 研发完成的需求在开始测试后仍然需要研发投入去修复测试缺陷
渐进式的研发管理改进之路

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

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

改进前:待研发需求高于发布需求
综合分析后,我们最终确定交付团队效能提升的约束就是研发环节,并为此制定了解决方案:

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

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

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

改进后:需求周期可预测

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

改进后:待研发需求数量

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

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

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

首先,最大化利用非瓶颈资源只会造成堆积和等待,效能改进需要聚焦疏通瓶颈,让改进变得落地简单可执行。其次,渐进式的研发效能改进能在短期内给团队正向反馈从而提升团队的自驱力。同时也能通过提升需求的可预测性有效地提升业务的满意度建立透明、信任的团队氛围

发布者:Cary Bao,转转请注明出处:https://tobeagile.cn/2021/10/21/%e6%b8%90%e8%bf%9b%e5%bc%8f%e7%9a%84%e7%a0%94%e5%8f%91%e7%ae%a1%e7%90%86%e6%94%b9%e8%bf%9b%e4%b9%8b%e8%b7%af/

发表评论

邮箱地址不会被公开。 必填项已用*标注