乐趣区

关于研发管理:QCon-全球软件开发大会-大型团队研发效率持续改进实践

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 调整阶段

规范并非变化无穷的,而是须要定期复盘,以保障规范在团队倒退变动的过程中有更好的适应性,而复盘后果则汇入到下一循环中进行布局。

最初,对以上内容做两点总结:

一、改良效率,要关注工作量的安顿、是否有简略清晰的工作规范、从单个因素动手。

二、工具落地标准化,有助于继续大范畴落地规范和可视化,进而达到继续改良的状态。

退出移动版