写点什么

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

用户头像
万事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 团队的渐进式效能改进经验中,我们总结出两个核心理念:

 

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

 

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

发布于: 刚刚阅读数: 2
用户头像

万事ONES

关注

助力企业更好更快发布产品! 2018.08.06 加入

一站式企业级研发管理解决方案,满足敏捷、瀑布、通用多种研发管理模式,打造高效协作环境,助力企业更好更快发布产品。

评论

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