快速提升研发效能的秘诀是……

DevLake技术小组 2022-03-25 15:24:22

在上一期DevData Talks当中,我们邀请到了从业互联网行业十余年,现任思码逸高级咨询顾问的张超老师和我们分享场景化度量实践案例。首先我们对张超老师分享进行回顾~

DevData Talks 2 回顾 | 张超:场景化度量实践案例

『没什么用』的效能度量,可能离场景太远


研发效能领域的常见问题:组织投入资源建设了效能度量,也抱以极高期望,但从一线研发团队得到的反馈却是『感觉没什么用』。

价值感受不明显的具体原因,可能是用户拿到的数据与其需求并不匹配,比如将来自各个环节的海量数据明细直接展示给高层技术管理者,信息冗余造成极高的理解成本,效能度量自然被打入冷宫;可能是组织还没有对度量目的达成共识,漫无目的地看数据,数据就仅仅是数字的组合,沦为鸡肋也不奇怪。

有价值的效能度量,应该是怎样的形态?考虑到一线研发团队的绝大部分精力都投入在业务上,一个还需要用户补习领域知识、自行筛选解读的半成品数据集,确实不如人意。明明想要提升效能,反而需要投入额外精力,无异于南辕北辙。

要使效能度量的价值最大化,我们提供给研发团队的应当是『效能产品』。如张乐老师先前的分享所说,数据→信息→知识,用户可以根据需求,低门槛地自助消费数据,主动进行分析和洞察。

 

场景化分析,设计效能度量的第一个环节


当我们用产品思维重新思考效能度量这件事,『场景化』就成为必要条件。可以从目标

出发,借助场景化分析,明确以下四个要素,进而设计效能度量方案:

角色:度量数据使用者的在研发团队中的角色,决定了度量结构(组织、团队、项目、个人级)
背景:明确为什么做度量,这个需求可能来自业务方,或来自研发团队本身。上下文决定了度量对象(进度、质量、过程等)
目的:同一度量对象可能对应多个指标,因此需要拆成多个问题,进一步细化,这里不妨采用技巧:先抛出具体论点,然后思考要证实或证伪这个论点,需要哪些指标做支撑,哪些指标作为制衡保障度量有效性
度量:构建最小度量集合,并思考采用哪些分析方法来解读数据中的信息

 案例:常见的『研发团队要加人』场景

 

接下来我们展开介绍直播分享中的第一个场景,作为场景化度量实践的案例。直播中另外两个场景可以在直播回看。

这个场景可以说是相当常见:研发团队向上反映人手不够,要加人。那么高管在这个场景下的需求是:

  • 角色:高管
  • 背景:需要客观评估研发资源紧张程度,指导后续招聘工作
  • 目的:验证『要加人的 A 部门和 B 部门都存在人力缺口』是否成立

对于高管而言,度量对象是组织整体与某几个团队的产能与交付情况。

高管可以把代码当量、需求交付周期、需求吞吐量等指标作为数据抓手,从资源效率(价值输出方视角)与流动效率(价值输入方视角)两个视角,评估组织整体的产能情况,并通过与行业基线对比,评估是否存在组织级的产能紧张。

 

与行业基线的对比显示,大部分时间内组织的整体产能水平处于正常区间。

接下来,可以按照部门进行下钻分析,重点关注 A、B 两个部门的人均产能与组织均值的对比。

尽管不同部门可能在业务性质、阶段等方面存在差异,横向对比不一定适用。但这里部门级分析没有任何考核目的,仅是通过相对简单的数据抓手,识别需要高管额外关注的关键点。

下图显示,B 部门的人均产能偏低,继续下钻查看部门详情,显示 B 部门产能有显著降低的趋势。

 

 

基于这些洞见,『B 部门存在人力缺口』这一论点存疑,高管可能会要求 B 部门补充信息,来支持其人力需求的合理性。

现在问题回到了 B 部门内部。角色切换到 B 部门技术负责人,继续用场景化分析的思路梳理:

  • 角色:技术负责人
  • 背景:需要深入了解工作过饱和现象背后的根因,佐证人力需求确实存在,或采取针对性的效能改进措施
  • 目的:验证『工作过饱和的原因是团队协作行为有待改善』(这是多个待验证设论中的一个)

对于技术负责人而言,度量的对象是本部门的效率,以及可能影响效率的诸多因素。

技术负责人通过观察人均产能趋势发现,尽管最近加班加点,人均产能连续上升,但也仅回升至去年同期平均水平。同时,由于相关业务处于平稳期,需求吞吐量也没有明显波动。从资源效率与流动效率两个视角看,都不存在需求激增超过团队负载的情况。

 

为了验证团队协作行为是否对效率产生了影响,技术负责人可以从资源效率出发,进一步下钻至个人级,使用帕累托图去分析开发者的产能分布;也可以从流动效率出发,观察需求交付周期趋势,以及各环节的时长分布。

分析发现,尽管需求吞吐量变化不大,但交付周期明显延长,流负载(在制品数量)也显著增加。任务积压导致团队成员需要同时处理多项工作,频繁切换上下文,进一步拖累团队效率。

在团队中,某一部分工作延期较频繁,经常成为项目关键路径上的活动。技术负责人对该部分的相关开发人员近期产能进行帕累托分析,发现 80 %的代码工作量由 22% 成员贡献,反映出该部分工作存在任务分配不合理、不均衡,少数成员承担过多任务的情况,这也呼应了上一段提到的任务积压现象。

 

基于以上洞见,技术负责人能够了解到,协作不合理确实是效率的影响因素之一。进一步,可以选择针对性的改进措施,如

  • 与上游产品方沟通,控制需求流入,避免在制品数量继续上升,给关键环节以喘息调整的时机;
  • 调整任务分配机制,避免多个任务同时依赖于少数成员;
  • 定向组织培训,释放开发者潜能,使『单挑大梁』转变为『齐心协力』

 

DevData Talks 3 预告 | 茹炳晟:研发效能提升案例

看完上一期的分享回顾,大家是不是觉得意犹未尽呢?敬请期待下一期内容!

我们邀请到了 业界知名实战派 软件质量和研发工程效能专家 茹炳晟 老师来参与DevData Talks第三期的直播活动。届时,茹老师将与大家分享有关研发效能提升的思考,对可测试性进行一次深入浅出的探讨,主要内容包含以下 5 个方面:

·可测试性的定义

·可测试性差引发的问题

·可测试性的三个核心观点

·可测试性的四个维度

·不同级别的可测试性与工程实践

欢迎大家参与3月30日(周三)晚上7点的DevData Talks直播活动~

预约报名链接:http://hdxu.cn/2zNWe

...全文
990 回复 打赏 收藏 举报
写回复
回复
切换为时间正序
请发表友善的回复…
发表回复
相关推荐
发帖
研发效能

62

社区成员

专注软件研发效能和软件工程领域,干货资讯与实践经验分享
软件工程经验分享 企业社区
社区管理员
  • 思码逸研发效能
加入社区
帖子事件
创建了帖子
2022-03-25 15:24
社区公告
暂无公告