10 月 21 日上午，在 2021 Qcon 全球软件开发大会（上海站）上，ONES CTO 冯斌作了题为《大型团队研发效率持续改进实践》的主题演讲，与众多行业大咖和从业者分享研发效能提升的实践经验。
以下是该演讲的主要内容。
根据统计，平均而言，关于大型研发团队 IT 项目失败的原因，延期、超出预算、功能不满足、软件质量太差等涵盖了其中的 75%。
因此，如果这几方面的问题能得到有效解决，那么，软件研发的成功率有望大大增加。
结合 ONES 的实践，我们发现，大型研发团队面临以下这些挑战：
大型研发团队面临的挑战
01 工作效果差异大
由于不同团队使用不同工具，平台化方案难统一应用，团队数据分散，导致团队协作效率低，整体效能提升难。成绩优良的团队通常依赖若干位专家，但「专家」难以复制到其他团队。
同时，项目进度是衡量团队效率的核心指标，需要研发团队协作推进，然而中大型团队任务进度的可预测性低。
02 业务满意度低
在日常工作中，总会有业务部门会质疑研发团队：这个需求不很简单吗？为什么做这么久？
这反映了「需求前置时间过长」的问题，即需求从提出到交付的时间过长，无法满足业务方或客户的期待。
同时，因为技术风险、紧急事故等各种难以避免的客观问题，项目进度承诺容易被打破，同时可能导致返工率高，使得团队怨声载道。
03 改进措施难落地
改进措施的落地需要所有团队成员的配合。然而在改进初期，管理者经常遇到这样的问题：团队成员认为「我们本来就很忙，还要额外付出时间和精力来改进」？这样一来，导致团队认为此事「执行成本高」。
不仅如此，改进常常意味着团队内部的「改革」，可能会打击某些人原有的角色或位置，让团队成员对改进措施产生质疑，从而导致落地阻力大。而改进的培训和沟通成本高，尤其是对于中大型团队而言，需要进行持续的培训，成本高，见效慢；培训后的执行效果难以跟踪。这些因素综合影响了团队的改进措施的执行落地。
基于对大型研发团队所面临的挑战，我们认为，研发管理改进必须以「不依赖人的手段」来推进，而是通过制定标准，并将其落地到工具中，实现自动化的管理。
在落地改进之前，我们首先要找出影响研发效率的底层因素是哪些。
影响研发效率的因素
01 工作量与工作节奏
如前所述，项目执行过程中常常因为突发的紧急任务打破研发节奏，造成研发任务的累积。这意味着部分业务部门提出的需求，研发部门迟迟没有完成，长此以往将形成严重的工作量堆积，出现失控的局面。
02 标准的建立与执行
标准是保证团队规模化的最重要手段。一个有效的标准，应该是一个被清晰定义的工作流程，是被清晰定义的各个环节的完成标准。而且，管理者必须确认团队是围绕该标准进行工作的。
03 改进的阻力源
如何让团队成员理解并接受改进？
实际上，在改进具体的事情之前，首先应该改变人的认知。而当涉及多个因素的改进时，阻力会加倍，它可能涉及了人、事、工具等方方面面，例如组织架构调整、工作习惯改变、工具落地等。
针对上述的关键因素，我们来看看如何有效落地改进？
持续改进落地实践
改进过程可以采用 PDCA 循环理论框架。
PDCA 循环又称戴明循环。P-D-C-A 这四个字母，分别代表：Plan（计划），Do（行动），Check（检查），Act（处理）。戴明是一位美国的质量管理大师，他认为，高质量，不是来自基于结果的产品检验，而是来自于基于过程的不断改善。后来，他的理念不但被用于质量管理，更被广泛地用于企业管理领域。
PDCA 循环
1 计划阶段
如何改变人的认知？项目的可视化是第一步。
科学的数据可视化能够直接给团队反馈，为理性分析提供依据，为感性认知提供视觉印象。
下图是 ONES 报表中显示的团队需求周期时间分布图，这是一个高度离散的分布图，说明了需求的交付时间可预测性很弱。
需求周期时间分布图
另一个「状态趋势图」则表明了团队的待研发需求一直在不断增加，然而发布的速度却跟不上待研发需求的速度，最终可能导致团队需求累积，降低研发效率。
状态趋势图
而持续可视化需要在线化、结构化工作内容。以用户故事的管理为例，通过 ONES 研发管理工具，管理者能够根据团队实际场景，自定义配置用户故事字段，供执行人员填写，从而保证研发数据被结构化地记录，便于后期进行数据可视化的效能分析。
结构化工作内容
此外，计划阶段还需要限制并行的任务数量，找到流程中的瓶颈；并识别不同的工作流程，在组织架构和人力投入上进行隔离，保证资源高效利用。改进时如果遇到多个阻力因素，应优先选择影响因素少的细节开始改进，这样做的好处是能够快速给到团队正向反馈，提升团队对改进的信心——前提是，管理者对团队的全局待改进情况有系统的认知。
例如通过看板工具可以直观地了解到该团队的「待研发任务」很少，但「研发中」、「待测试」、「测试中」的任务堆积，此时管理者则需要调整资源，疏通阻塞。
ONES Project 看板视图
2 执行阶段
首先，建立一个简单、容易被理解的标准——该标准更容易被认可和落地执行。
一个简单的标准并不需要覆盖尽可能多的场景，大而全的标准反而容易导致标准落地困难，简单的标准覆盖 90%的场景即可。标准并不是告诉大家工作的「所有」工作是什么，而是「至少」要做到什么。
其次，利用工具数字化工作流程，内嵌完成标准。「内嵌」是指将团队中各个角色的工作及状态流转规则落地到工具中，以减少人为因素的干扰和噪音导致的偏差。
ONES Project 工作流引擎
再次，鼓励团队使用工具展开日常工作，以实现研发过程真正地按照标准执行。
最后，利用工具尽可能地实现自动化。如图，显示了一个经典的需求和任务状态联动的自动化流转。当关联同一需求的多个子任务都完成时，则该需求自动完成。
ONES Project 自动化引擎
从这里我们可以看出，这些做法的好处是：通过工具引导团队以标准高效地完成工作。
3 分析阶段
改进措施落地后，管理者需要持续进行效能数据的监测。
例如，对比改进前后的「需求周期时间分布图」可分析出，改进后团队的需求周期时间集中在 20 以内，证明团队的需求交付可预测性变强了。
（左）改进前 （右）改进后
又例如下图的「状态趋势图」，可以看到改进后，团队发布的需求逐渐增多，而新增的需求不断消耗，证明研发效率明显提升。
（左）改进前 （右）改进后
4 调整阶段
标准并非一成不变的，而是需要定期复盘，以保证标准在团队发展变化的过程中有更好的适应性，而复盘结果则汇入到下一循环中进行规划。
最后，对以上内容做两点总结：
一、改进效率，要关注工作量的安排、是否有简单清晰的工作标准、从单个因素入手。
二、工具落地标准化，有助于持续大范围落地标准和可视化，进而达到持续改进的状态。