QCon 全球软件开发大会 | 大型团队研发效率持续改进实践

根据统计，平均而言，关于大型研发团队 IT 项目失败的原因，延期、超出预算、功能不满足、软件质量太差等涵盖了其中的75%。

因此，如果这几方面的问题能得到有效解决，那么，软件研发的成功率有望大大增加。

结合实践，我们发现，大型研发团队面临以下这些挑战：

大型研发团队面临的挑战

工作效果差异大

由于不同团队使用不同工具，平台化方案难统一应用，团队数据分散，导致团队协作效率低，整体效能提升难。成绩优良的团队通常依赖若干位专家，但「专家」难以复制到其他团队。

同时，项目进度是衡量团队效率的核心指标，需要研发团队协作推进，然而中大型团队任务进度的可预测性低。

业务满意度低

在日常工作中，总会有业务部门会质疑研发团队：这个需求不很简单吗？为什么做这么久？

这反映了「需求前置时间过长」的问题，即需求从提出到交付的时间过长，无法满足业务方或客户的期待。

同时，因为技术风险、紧急事故等各种难以避免的客观问题，项目进度承诺容易被打破，同时可能导致返工率高，使得团队怨声载道。

改进措施难落地

改进措施的落地需要所有团队成员的配合。然而在改进初期，管理者经常遇到这样的问题：团队成员认为「我们本来就很忙，还要额外付出时间和精力来改进」？这样一来，导致团队认为此事「执行成本高」。

不仅如此，改进常常意味着团队内部的「改革」，可能会打击某些人原有的角色或位置，让团队成员对改进措施产生质疑，从而导致落地阻力大。而改进的培训和沟通成本高，尤其是对于中大型团队而言，需要进行持续的培训，成本高，见效慢；培训后的执行效果难以跟踪。这些因素综合影响了团队的改进措施的执行落地。

基于对大型研发团队所面临的挑战，我们认为，研发管理改进必须以「不依赖人的手段」来推进，而是通过制定标准，并将其落地到工具中，实现自动化的管理。

在落地改进之前，我们首先要找出影响研发效率的底层因素是哪些。

影响研发效率的因素

工作量与工作节奏

如前所述，项目执行过程中常常因为突发的紧急任务打破研发节奏，造成研发任务的累积。这意味着部分业务部门提出的需求，研发部门迟迟没有完成，长此以往将形成严重的工作量堆积，出现失控的局面。

 

标准的建立与执行

标准是保证团队规模化的最重要手段。一个有效的标准，应该是一个被清晰定义的工作流程，是被清晰定义的各个环节的完成标准。而且，管理者必须确认团队是围绕该标准进行工作的。

改进的阻力源

如何让团队成员理解并接受改进？

实际上，在改进具体的事情之前，首先应该改变人的认知。而当涉及多个因素的改进时，阻力会加倍，它可能涉及了人、事、工具等方方面面，例如组织架构调整、工作习惯改变、工具落地等。

针对上述的关键因素，我们来看看如何有效落地改进？

持续改进落地实践

改进过程可以采用 PDCA 循环理论框架。

 

PDCA 循环又称戴明循环。P-D-C-A 这四个字母，分别代表：Plan（计划），Do（行动），Check（检查），Act（处理）。戴明是一位美国的质量管理大师，他认为，高质量，不是来自基于结果的产品检验，而是来自于基于过程的不断改善。后来，他的理念不但被用于质量管理，更被广泛地用于企业管理领域。

PDCA循环

1计划阶段

如何改变人的认知？项目的可视化是第一步。

科学的数据可视化能够直接给团队反馈，为理性分析提供依据，为感性认知提供视觉印象。

下图是报表中显示的团队需求周期时间分布图，这是一个高度离散的分布图，说明了需求的交付时间可预测性很弱。

需求周期时间分布图

另一个「状态趋势图」则表明了团队的待研发需求一直在不断增加，然而发布的速度却跟不上待研发需求的速度，最终可能导致团队需求累积，降低研发效率。

状态趋势图

而持续可视化需要在线化、结构化工作内容。以用户故事的管理为例，通过研发管理工具，管理者能够根据团队实际场景，自定义配置用户故事字段，供执行人员填写，从而保证研发数据被结构化地记录，便于后期进行数据可视化的效能分析。

结构化工作内容

此外，计划阶段还需要限制并行的任务数量，找到流程中的瓶颈；并识别不同的工作流程，在组织架构和人力投入上进行隔离，保证资源高效利用。改进时如果遇到多个阻力因素，应优先选择影响因素少的细节开始改进，这样做的好处是能够快速给到团队正向反馈，提升团队对改进的信心——前提是，管理者对团队的全局待改进情况有系统的认知。

例如通过看板工具可以直观地了解到该团队的「待研发任务」很少，但「研发中」、「待测试」、「测试中」的任务堆积，此时管理者则需要调整资源，疏通阻塞。

看板视图

2执行阶段

首先，建立一个简单、容易被理解的标准——该标准更容易被认可和落地执行。

一个简单的标准并不需要覆盖尽可能多的场景，大而全的标准反而容易导致标准落地困难，简单的标准覆盖90%的场景即可。标准并不是告诉大家工作的「所有」工作是什么，而是「至少」要做到什么。

其次，利用工具数字化工作流程，内嵌完成标准。「内嵌」是指将团队中各个角色的工作及状态流转规则落地到工具中，以减少人为因素的干扰和噪音导致的偏差。

工作流引擎

再次，鼓励团队使用工具展开日常工作，以实现研发过程真正地按照标准执行。

最后，利用工具尽可能地实现自动化。如图，显示了一个经典的需求和任务状态联动的自动化流转。当关联同一需求的多个子任务都完成时，则该需求自动完成。

自动化引擎

从这里我们可以看出，这些做法的好处是：通过工具引导团队以标准高效地完成工作。

3分析阶段

改进措施落地后，管理者需要持续进行效能数据的监测。

例如，对比改进前后的「需求周期时间分布图」可分析出，改进后团队的需求周期时间集中在20以内，证明团队的需求交付可预测性变强了。

（左）改进前 （右）改进后

又例如下图的「状态趋势图」，可以看到改进后，团队发布的需求逐渐增多，而新增的需求不断消耗，证明研发效率明显提升。

（左）改进前 （右）改进后

 

4调整阶段

标准并非一成不变的，而是需要定期复盘，以保证标准在团队发展变化的过程中有更好的适应性，而复盘结果则汇入到下一循环中进行规划。

最后，对以上内容做两点总结：

一、改进效率，要关注工作量的安排、是否有简单清晰的工作标准、从单个因素入手。

二、工具落地标准化，有助于持续大范围落地标准和可视化，进而达到持续改进的状态。