共计 2678 个字符，预计需要花费 7 分钟才能阅读完成。
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 调整阶段
规范并非变化无穷的，而是须要定期复盘，以保障规范在团队倒退变动的过程中有更好的适应性，而复盘后果则汇入到下一循环中进行布局。
最初，对以上内容做两点总结：
一、改良效率，要关注工作量的安顿、是否有简略清晰的工作规范、从单个因素动手。
二、工具落地标准化，有助于继续大范畴落地规范和可视化，进而达到继续改良的状态。
