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

10 月 21 日上午,在 2021 Qcon 全球软件开发大会(上海站)上,ONES CTO 冯斌作了题为《大型团队研发效率持续改进实践》的主题演讲,与众多行业大咖和从业者分享研发效能提升的实践经验。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

以下是该演讲的主要内容。
根据统计,平均而言,关于大型研发团队 IT 项目失败的原因,延期、超出预算、功能不满足、软件质量太差等涵盖了其中的 75%。
因此,如果这几方面的问题能得到有效解决,那么,软件研发的成功率有望大大增加。
【QCon 全球软件开发大会 | 大型团队研发效率持续改进实践】结合 ONES 的实践,我们发现,大型研发团队面临以下这些挑战:
大型研发团队面临的挑战
01 工作效果差异大
由于不同团队使用不同工具,平台化方案难统一应用,团队数据分散,导致团队协作效率低,整体效能提升难。成绩优良的团队通常依赖若干位专家,但「专家」难以复制到其他团队。
同时,项目进度是衡量团队效率的核心指标,需要研发团队协作推进,然而中大型团队任务进度的可预测性低。
02 业务满意度低
在日常工作中,总会有业务部门会质疑研发团队:这个需求不很简单吗?为什么做这么久?
这反映了「需求前置时间过长」的问题,即需求从提出到交付的时间过长,无法满足业务方或客户的期待。
同时,因为技术风险、紧急事故等各种难以避免的客观问题,项目进度承诺容易被打破,同时可能导致返工率高,使得团队怨声载道。
03 改进措施难落地
改进措施的落地需要所有团队成员的配合。然而在改进初期,管理者经常遇到这样的问题:团队成员认为「我们本来就很忙,还要额外付出时间和精力来改进」?这样一来,导致团队认为此事「执行成本高」。
不仅如此,改进常常意味着团队内部的「改革」,可能会打击某些人原有的角色或位置,让团队成员对改进措施产生质疑,从而导致落地阻力大。而改进的培训和沟通成本高,尤其是对于中大型团队而言,需要进行持续的培训,成本高,见效慢;培训后的执行效果难以跟踪。这些因素综合影响了团队的改进措施的执行落地。
基于对大型研发团队所面临的挑战,我们认为,研发管理改进必须以「不依赖人的手段」来推进,而是通过制定标准,并将其落地到工具中,实现自动化的管理。
在落地改进之前,我们首先要找出影响研发效率的底层因素是哪些。
影响研发效率的因素
01 工作量与工作节奏
如前所述,项目执行过程中常常因为突发的紧急任务打破研发节奏,造成研发任务的累积。这意味着部分业务部门提出的需求,研发部门迟迟没有完成,长此以往将形成严重的工作量堆积,出现失控的局面。
02 标准的建立与执行
标准是保证团队规模化的最重要手段。一个有效的标准,应该是一个被清晰定义的工作流程,是被清晰定义的各个环节的完成标准。而且,管理者必须确认团队是围绕该标准进行工作的。
03 改进的阻力源
如何让团队成员理解并接受改进?
实际上,在改进具体的事情之前,首先应该改变人的认知。而当涉及多个因素的改进时,阻力会加倍,它可能涉及了人、事、工具等方方面面,例如组织架构调整、工作习惯改变、工具落地等。
针对上述的关键因素,我们来看看如何有效落地改进?
持续改进落地实践
改进过程可以采用 PDCA 循环理论框架。
PDCA 循环又称戴明循环。P-D-C-A 这四个字母,分别代表:Plan(计划),Do(行动),Check(检查),Act(处理)。戴明是一位美国的质量管理大师,他认为,高质量,不是来自基于结果的产品检验,而是来自于基于过程的不断改善。后来,他的理念不但被用于质量管理,更被广泛地用于企业管理领域。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

PDCA 循环
1 计划阶段
如何改变人的认知?项目的可视化是第一步。
科学的数据可视化能够直接给团队反馈,为理性分析提供依据,为感性认知提供视觉印象。
下图是 ONES 报表中显示的团队需求周期时间分布图,这是一个高度离散的分布图,说明了需求的交付时间可预测性很弱。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

需求周期时间分布图
另一个「状态趋势图」则表明了团队的待研发需求一直在不断增加,然而发布的速度却跟不上待研发需求的速度,最终可能导致团队需求累积,降低研发效率。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

状态趋势图
而持续可视化需要在线化、结构化工作内容。以用户故事的管理为例,通过 ONES 研发管理工具,管理者能够根据团队实际场景,自定义配置用户故事字段,供执行人员填写,从而保证研发数据被结构化地记录,便于后期进行数据可视化的效能分析。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

结构化工作内容
此外,计划阶段还需要限制并行的任务数量,找到流程中的瓶颈;并识别不同的工作流程,在组织架构和人力投入上进行隔离,保证资源高效利用。改进时如果遇到多个阻力因素,应优先选择影响因素少的细节开始改进,这样做的好处是能够快速给到团队正向反馈,提升团队对改进的信心——前提是,管理者对团队的全局待改进情况有系统的认知。
例如通过看板工具可以直观地了解到该团队的「待研发任务」很少,但「研发中」、「待测试」、「测试中」的任务堆积,此时管理者则需要调整资源,疏通阻塞。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

ONES Project 看板视图
2 执行阶段
首先,建立一个简单、容易被理解的标准——该标准更容易被认可和落地执行。
一个简单的标准并不需要覆盖尽可能多的场景,大而全的标准反而容易导致标准落地困难,简单的标准覆盖 90%的场景即可。标准并不是告诉大家工作的「所有」工作是什么,而是「至少」要做到什么。
其次,利用工具数字化工作流程,内嵌完成标准。「内嵌」是指将团队中各个角色的工作及状态流转规则落地到工具中,以减少人为因素的干扰和噪音导致的偏差。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

ONES Project 工作流引擎
再次,鼓励团队使用工具展开日常工作,以实现研发过程真正地按照标准执行。
最后,利用工具尽可能地实现自动化。如图,显示了一个经典的需求和任务状态联动的自动化流转。当关联同一需求的多个子任务都完成时,则该需求自动完成。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

ONES Project 自动化引擎
从这里我们可以看出,这些做法的好处是:通过工具引导团队以标准高效地完成工作。
3 分析阶段
改进措施落地后,管理者需要持续进行效能数据的监测。
例如,对比改进前后的「需求周期时间分布图」可分析出,改进后团队的需求周期时间集中在 20 以内,证明团队的需求交付可预测性变强了。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

(左)改进前 (右)改进后
又例如下图的「状态趋势图」,可以看到改进后,团队发布的需求逐渐增多,而新增的需求不断消耗,证明研发效率明显提升。
QCon 全球软件开发大会 | 大型团队研发效率持续改进实践
文章图片

(左)改进前 (右)改进后
4 调整阶段
标准并非一成不变的,而是需要定期复盘,以保证标准在团队发展变化的过程中有更好的适应性,而复盘结果则汇入到下一循环中进行规划。
最后,对以上内容做两点总结:
一、改进效率,要关注工作量的安排、是否有简单清晰的工作标准、从单个因素入手。
二、工具落地标准化,有助于持续大范围落地标准和可视化,进而达到持续改进的状态。

    推荐阅读