项目交付效率
研发人效

通过度量研发效能,多角度洞察百人敏捷团队的价值交付

某知名互联网电商,借助代码当量等效能指标,对团队的交付成本、交付效率、交付质量等指标进行度量与分析
立即预约效能专家
痛点归纳
V
S
解决方案
研发价值的反馈不透明,高层管理者希望了解研发效能宏观结果与价值达成情况
通过季度报告帮助高层管理者管理研发的交付价值和成本
中层管理者需要能有效发现效能短板的工具,横向对比不同业务线的交付效率、质量与成本
通过月度报告帮助中层管理者发现效能短板、聚焦管理精力
团队 Leader缺少针对性的数据抓手,管理研发过程
- 通过双周报告辅助团队Leader 管理研发过程、打造改进闭环

案例背景

本案例来自某知名互联网电商,该客户有 200+人的研发团队,主要采用的是敏捷开发模式。

随着软件行业的快速发展,高效的研发效能已成为企业竞争力的关键因素。尤其对于具有一定人数规模的敏捷研发团队,如何在复杂的项目环境中客观衡量研发效能,更是团队和管理者面临的重要课题。这不仅关系到项目的质量、交付速度,更直接影响到企业的市场地位和经济效益。

因此,该企业的 CTO 牵头发起研发效能的建设项目,由该团队的质量管理负责人和 PMO 推动研发效能体系的落地,希望探索合理、有效的研发效能度量方法,对于研发团队来说,具有重要的现实意义。

本案例中,客户团队主要面对的研发效能难题可以总结为两方面:

  1. 研发价值的反馈不透明,高层管理者希望了解研发成本是否花在了有价值的事情上?
  2. 管理层中的不同的角色对研发效能的关注点不同,希望通过研发效能度量为不同角色提供针对性的数据抓手。那么希望研发效能带来的数据和洞察可以实现:

           1)由于项目每双周一次迭代,所以希望通过研发数据驱动研发Leader/项目经理发现风险或问题。计划通过效能双周会展示数据,落实改进点、负责人、及改进措施。

            2)每个月能够给中层管理者提供研发价值和成本投入情况,能够看到整体研发效能和短板,聚焦管理成本。

            3)每季度需要跟高层管理者汇报,希望能够给高层汇报价值达成、研发效能的宏观结果。

思码逸解决方案

针对以上这些痛点,思码逸 DevInsight 提供了从研发数据归集、治理,到研发效能指标体系、数据看板与专家级分析建议等全套的解决方案。同时,我们还为客户提供了创新的“代码当量”指标(点击阅读指标解释)。该指标相对于工时、需求数量、代码行数等指标,可以帮助团队更科学、更客观地度量研发工作量。

本案例中,由于不同的角色对于研发效能数据分析的需求不同,所以我们针对高层管理者、中层管理者、研发团队 Leader,三个不同角色提供对应的数据看板来分析交付价值、交付成本、交付效率、交付质量四个维度的指标,帮助不同管理角色分析、解释团队的“研发价值”和“研发成本与产出”。另外,由于不同角色的视角不同,例如高层管理者更需要看宏观的数据和分析报告,而团队 leader 则需要关注更多细节,所以思码逸DevInsight提供的数据会针对性地解答不同角色的效能问题。

一、通过季度报告帮助高层管理者管理研发的交付价值和成本

高层管理者关注的是宏观的研发效能表现,所以度量目标的重点是从交付价值和成本出发,根据数据分析结果,识别出不同维度的短板。针对交付价值、交付成本、交付效率、交付质量四个维度,思码逸 DevInsight 利用数据为高层管理者解答了真正产生价值的需求有多少?研发成本是否花在了有价值的事情上?团队的交付水平如何?与历史比变化如何?项目交付的质量如何?与之前相比有什么变化?几个问题。

思码逸DevInsight研发效能度量分析平台 ,通过需求价值了转化漏斗,直观体现到达考核周期的需求的价值转化情况,帮助管理者了解产生价值的需求有多少。这里的需求价值可以包含用户价值、企业价值、服务价值、销售价值等,具体可以根据企业自身情况来决定。基于不同价值对企业的重要程度,定义评分权重。

仅仅了解价值的转化还不够,高层管理者还希望可以了解需求价值的转化率。思码逸 DevInsight 结合开发工作量(即:代码当量)与价值产出的四象限分布图,帮助高层管理者分析产品需求投入成本与价值产出,了解团队整体的交付成本与产出。

在交付效率方面,我们通过月均需求吞吐量和研发交付周期综合判断出需求交付效率,衡量需求交付是否又“快”又“多”。而在关注效率的同时,我们集合代码当量与缺陷数量,根据时间范围得出缺陷逃逸率,以及该指标的环比变化趋势。通过这两个看板的数据分析结果,让高层管理者从宏观视角看清团队的交付效率与交付质量。

二、通过月度报告帮助中层管理者发现效能短板、聚焦管理精力

中层管理者往往要管理多个团队,需要了解团队间横向差异,所以对于中层管理者来讲,研发效能度量和分析的重点是定位各维度“关键的少数”,及时发现问题,保证多个团队的稳定交付。

针对这样的度量目标,思码逸DevInsight通过月报的形式,围绕交付价值、交付成本、交付效率、交付质量四个方面度量多个团队的指标,以便进行横向对比,发现差异,在出现问题苗头时快速做出改进动作。

交付价值的度量属于研发效能整体度量框架中重要的一部分,通过对研发资源、不同需求的投入产出比的度量,洞察研发团队交付价值产出情况。例如我们通过下图可以看到不同业务线在同一个时间周期内需求达标率。

在交付成本的度量方面,中层管理者,更关注的不同团队或业务线投入的研发成本。在此方面,我们通过成本方各月已完成任务对应工时的比例变化,衡量成本投入是否符合预期计划,及业务规划或诉求等。

同时,中层管理者可在思码逸 DevInsight 中通过项目投入人力、产出当量两者的变化,判断投入产出是否符合预期。通过环比,分析各项目投产比近期变化是否符合阶段特征。另外,思码逸 DevInsight 还为中层管理者提供了贡献均衡度的效能看板,洞察各个团队的负载情况,避免出现任务低负载或个别成员的任务过载。

3)针对交付效率

通过数据回答问题:

 需求交付效率变化如何,是否有提升空间?哪些团队的研发效率需要重点关注?

解决方法是通过绝大多需求研发交付周期的85%分位值判断研发交付价值的速度;通过交付周期的环比变化,判断研发交付速度是否平稳或有缩短。

近一年「月需求吞吐量」变化

首先,已完成需求 要满足以下条件:需求下所有任务的最晚「预计结束」均在时间筛选范围内 & 需求状态 = 完成or已复盘。在下图中,我们用不同颜色来表示需求工时(人天),即需求下所有技术任务「预估工时」的累计。用于区分需求大小,分为4个区间, 0-19; >=20 - 49;>=50 - 99;>=100。光有工时还不够精准,后续还可以将需求与当量关联,用当量区分需求大小,并校准工时,进行更科学地度量。

近一年需求交付「流效率」趋势变化

需求从创建到完成,交付过程的流效率 = 单位时间内已交付需求的总活跃时间 / (总活跃时间+总等待时间)。我们需要评估一年的需求交付流效率的趋势变化,来辅助解答交付效率有哪些变化。如下图所示,可以看到有两类需求,一种是处于活跃阶段(开发中、测试中),还有一种是等待阶段(规划中、BRD评审通过、暂停等),我们可以通过曲线来观察流效率,并可以看到流效率在什么时间段低于了均值(图中虚线)。如果持续低于均值,则需要管理者进一步下钻找出问题根源。

技术中心「各团队」月生产率环比

观察各团队生产率的环比变化,判断生产率是否相对平稳、产出效率是否与任务交付规划相符。

4)针对交付质量

通过数据回答问题:

 需求的交付质量趋势变化如何?外部质量是否逐渐平稳或需要加强内建质量?

近一年「线上缺陷」逃逸率

观察线上缺陷逃逸率的变化,如果呈上升状态,提示关注内部质量风险,针对性投入内部质量成本。具体的计算方式是:

线上缺陷逃逸率 = 生产缺陷数量 / (测试缺陷数量 + 生产缺陷数量 + 缺陷类型为”空“的缺陷数量)

近一年千当量「测试缺陷」密度

观察内测千当量缺陷密度的变化,如果呈上升状态,提示关注开发质量、需求质量等质量左移测试是否到位。如下图所示:

  • 千当量测试缺陷密度 = 月创建的内测缺陷数量 / 月新增千代码当量。

三、通过双周报告辅助团队领导管理研发过程、打造改进闭环

相对于高层、中层管理者来讲,团队 Leader 不仅需要从项目的维度频繁地度量、分析交付效率、交付成本、交付质量,还需要从团队的维度洞察团队成员的贡献均衡度、交付效率等指标。思码逸 DevInsight 会通过贡献均衡度、交付的需求数量、研发交付周期、千当量缺陷密度等指标,以双周为时间周期,辅助团队 Leader 管理研发过程,及时洞察团队的效能瓶颈和不足。

该企业的的度量目标是通过千当量(代码当量)缺陷密度的趋势变化,判断内测质量是否平稳,若趋势上升提示关注提测风险、内建质量风险。思码逸 DevInsight采用千当量缺陷密度(测试提交BUG)作为度量指标,即周期时间内内测新增缺陷与新增代码当量的比值,辅助管理者度量交付质量。

研发工程质量可以反映项目整体及所选时段增量代码的内建质量,同时与与行业中等水平的对比作为参考。

2)项目对比

2.1)交付成本

需要通过数据回答问题:

 各项目投入的研发成本变化如何,是否符合整体计划或预期?

项目研发成本可以分为很多种,其中我们可以客观量化的就是项目中编程的工作量投入占比。在这里我们可以通过新增代码当量指标来进行度量。通过建立研发产出代码当量占比看板,可以洞察各项目投入研发成本(coding工作量)的占比,判断投入占比是否符合预期。团队 Leader 可以通过调配资源,将团队重心放在关键项目上。

项目任务饱和度:日人均当量

通过数据回答问题:

 哪些项目资源负载过高或偏低,是否需要进行项目间的资源调配?

要解决这个问题,我们就需要度量需求受理后的交付速度,即研发交付周期。这个指标反映了各个项目贡献者每日生产率的变化,如下图看板所示,颜色越深代表生产率越高、任务越繁忙。

如果连续多个工作日无代码提交,则意味着资源出现空置和或积压提交,那么管理者需要考虑进行合理的任务拆分或项目间资源调配。反之,如果连续多个非工作日高生产率,那么意味着出现了任务溢出,建议此时管理者关注质量和进度风险。

2.2)交付效率

通过数据回答问题:

 不同项目的研发效率如何?资源贡献均衡度是否对项目效率有负向影响?

另外,该企业的团队 Leader 还希望关注不同项目的研发效率如何?资源贡献均衡度是否对项目效率有负向影响?

为了解决这个问题,团队 Leader 在思码逸DevInsight 中建立看板,对比资源贡献均衡度和项目交付效率,如下图所示。通过图中右侧的专家系统可以看到,该企业设定了贡献均衡度的预警阈值为 40%,如果均衡度低于这个值,就说明资源贡献不均衡。同时,配合折线观察项目的研发生产效率趋势。

项目研发生产率 VS 贡献均衡度

小结

思码逸 DevInsight 研发效能度量分析平台从项目、团队、个人的角度,度量研发项目的产出、需求交付效率、内建质量等指标,帮助企业的高层、中层管理者,以及团队 leader 洞察交付成本、交付效率、交付质量情况,解决了研发价值反馈不透明,以及管理层种不同角色对研发效能不同指标的度量、分析需求。

想要进一步了解
解决方案详情?
立即咨询效能专家

想要进一步了解解决方案详情?

了解更多解决方案

No items found.
用数据驱动
研发质效提升!
预约思码逸效能专家,一起探讨如何提升研发效能!
立即试用
立即预约
在线客服
在线客服
扫码添加咨询微信
立即试用