这是鼎叔的第一百篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》,星标收藏,大量原创思考文章陆续推出。

第一百篇文章要上个硬菜。开启一个新专题系列 - 如何度量研发效能,同时也开启了对于过去几年研发效能工作的快速复盘。

缘起

在一个两千人的研发组织里,做一次面向企业技术高管的月度效能汇报,鼎叔花费的总人力大概比十年前至少要低一个数量级。

记得十年前,我要拉一个过程改进团队,加上一堆技术接口人,反复检查数据,输出观点和作图,折腾很久才能对高管层汇报一次。

这两年,我只需要一个兼职的测试开发员工,每个月花半天输出初稿,再让各接口人花点时间确认指标变化的原因,开一次小会就可以了。

要做到这个效率,效能度量和汇报的成本要降到最低,第一步是能随时看到关键指标,第二步就是汇报框架非常简单和稳定。

效能的数字化呈现方案,每个公司都会做,但这里充斥着理解上的误区。

效能可视化建设,首先要明确核心用户是谁,他的需求是什么,其次再明确唯一的北极星指标是什么,围绕它来建设质效可视化大盘,切忌不让其他指标喧宾夺主。

CTO 视角

如果给大型研发组织呈现效能数据,姑且认为第一用户是 CTO 等技术高管。

CTO 面对的第一个困境是,团队规模庞大,我怎么能更好地看到一线团队的效能情况?中间隔着厚厚的部门墙。每个部门汇报的数据都看着很好,但是彼此之间不是完全统一。

质量管理团队或者效能团队虽然会拉通大组织的效能数据来呈现,但也经常犯一类毛病,就是指标庞杂,观点不聚焦,并且容易内部妥协(担心被内部质疑)。

形成这个局面的主要原因是:

一,没有专家敢对北极星指标负全责,结果把北极星指标变成了团队脑暴成果。质效指标看起来都对,但是都是盲人摸象,逻辑零散。十个人观点汇总的报告也不可能达到高水平。

想到一堆重要指标很容易,但是锁定唯一指标就难。

二,为了体现质量和效能成果的 “专业度”,故意引入复杂的行业指标框架,并定义了极为细致和深入的子指标。在一线开发和测试生成的数据上,进行不必要的二次封装或拆解。

从第一用户的视角来做质效大盘,挑选出的北极星指标,还是要来源于对组织效能的本质理解。

我认同多数公司会选择 “需求平均交付周期-Lean time” 作为 “唯一” 的北极星指标。如果用户主观觉得太慢,那效能评价就不会满意。

这里面又可以拆解出需求平均研发交付周期。

研发团队如果是独立管理,可以先聚焦研发侧的交付时长。

如果产研高度一体化,就可以看整个需求交付时长了,它通常包括需求调研和文档时长,研发时长(含测试和合入主干),市场部署时长(对于纯后端发布的业务,这块时间极短)三块。

CTO 的第二个困境随之而来,多久时间可以觉察出效能短板,并及时干预,中间等待下属分析的时间极短?

我们很容易想到做一个实时质效大盘,并通过它进行质量和效率的风险预警,并能自动生成初版的效能报告。各个部门很难对度量数据进行及时的 “掩饰”。

但实际上,质效大盘在各个公司的落地评价差异非常大,本质上的原因是什么?

质效大盘的设计

正如前面分析的,大盘的首页一定要突出北极星指标,然后是围绕它的第一层拆解,拆解出直接影响北极星数值大小的分类信息。

以需求研发交付时长作为北极星,第一层关联指标该怎么拆解?下面是个人的实践推荐:

一 需求达成率(吞吐率)或月度需求完成总数。知道了平均时长,再配合交付的数量,和交付承诺的达成情况,研发交付的宏观情况就更清楚了。

二 过程耗时拆解。一线团队看到了自己的平均交付时长,可能还是不知道中间哪里被拖延了,这时大盘可以提供拆解耗时视图,比如研发交付周期被拆为四大阶段:需求开发设计,编码和自测,集成/系统测试,合入主干/发布。

每个阶段可以利用研发管理平台的状态流转自动统计耗时(注意这里有个坑)。

四大阶段还可以继续拆解为 N 个小阶段,每个阶段单独统计耗时。

三 过程关键质量。研发过程中导致技术人员返工的质量问题,必然会拖累北极星指标。推荐指标有:

低级缺陷率(或数量),一看就属于开发自测应该发现的基础问题,但遗留到了系统测试阶段。

缺陷平均处理周期,体现了缺陷处理时效。

缺陷 reopen 率(数量),体现了开发是否一次性解决问题。

四 上线质量。这类指标聚焦上线过程和上线后是否产生失败,导致交付损失和更昂贵的返工。推荐的可选指标有:

发布成功率/折返率。发布过程的失败次数值得具体分析,以暴露技术协作的风险。

线上事故级别和数量,线上逃逸缺陷级别和数量。根据公司质量规范定义,前者后果更为严重,可能触及研发红线,需要严肃复盘和追责;后者可能大部分是遗漏场景,需要具体分析能否提前拦截。

注意一个定义:事故和逃逸缺陷不一定都能通过有限成本的测试拦截的。但是漏测缺陷就一定可以。

为了让大盘内容更简单清晰,上述四类拆解指标的详细数据可以放在大盘的次级页面里,方便一线团队下钻。

大盘还会提供核心指标的趋势视图,便于干系人关注变化。

大盘的用户还有谁

再往下想一层:CTO 并不会频繁查看报表和提出数据分析需求,那大盘的第二类重要用户是谁?

那就是承担交付压力的一线团队 leader,他们必须要从大盘指示器中下钻到自己团队的可视化风险。

我遇到一个公司的持续交付负面例子:质量管理部列出几十个指标,让持续交付平台开发者把它们做到看板上。这些指标不是从一线团队日常视角来罗列的,更像是完成质量管理部门策划出来的目标。这样非但不能让一线团队得到自驱改进的益处,还增加了大盘的理解复杂度,并增加了开发维护成本。

我心目中的质效大盘是逐步演进出来的,一开始只有上述最简单的一级拆解指标,随着大家使用的活跃度提升,在不同层级上总结出了很有价值的分析指标,再慢慢加到合适的层级上去。

比如非常重视资金损失的团队,会把资金损失的异常告警数和事故数据,在大盘里添加,并实时提示出来。

效能的定期汇报

有了实时看板可能还不能满足质效工作者的安全感,定期的汇报可能会成为例行安排。

有了逻辑清晰稳定的实时大盘,汇报从本质上就轻松太多了,初稿一键生成 + 专家提炼观点 + 干系团队补充分析,三板斧搞定。

鼎叔发现一个有趣的现象,测试开发工程师做大盘生成是一把好手,结合强大的数据报表工具,效率极高;但分析效能指标观点起来就很弱了,要么没想法,要么瞎猜。确实后者是完全不同的技能,需要长期实践和交流。

对于大型组织的重要例行汇报,把握一个核心出发点就是实时数据说话,针对偏差大/劣化指标进行分析。保持和各部门接口人的沟通关系,迅速确认指标异常的原因。关键是及时暴露问题,而不是跨团队 PK 绩效和指责。

因为大盘背后的根基稳定且简单,鼎叔很少收到各大部门对大盘指标体系的质疑,最多是对某个指标自动度量的偏差有质疑。那我们往下看:

如何度量得更准

未来一个优化方向,就是如何自动度量地更准。鼎叔建议和项目管理团队合作,认真梳理研发管理平台的字段填写要求,并对规范进行培训和自动筛查。

最影响北极星指标度量的填写问题主要有:

1 需求和任务,傻傻分不清楚。

需求交付的是完整价值,用户能得到价值。

任务只是完成价值的一部分工作,如测试任务,联调任务,前端后端开发任务等。

北极星度量的是需求交付时长,切忌把 “任务” 改成 “子需求” 进行处理。

我们鼓励把大需求拆解为子需求进行度量,需求小了,交付效率就会高,团队就会敏捷。拆解文章请看:聊聊用户故事的估算和拆解

2 决定需求进入研发的 “起点时刻”。

回顾 Scrum 的知识,产品经理完成需求的修改和录入系统,成为 backlog 中的一部分,这些需求有很多并不会纳入本迭代开发,它们可能被推迟甚至无限推迟,从而拖长了 “需求平均交付时长”。

为了校准这点,研发管理系统要明确 “进入迭代开发” 的起点时间,作为统计 “研发交付周期” 的起点。

同理,针对对需求中途变更(经过团队确认,出于提升用户价值的目的),鼎叔鼓励暂停 “被推迟” 需求的统计周期,直到 “再次开启”,这样度量更准确,可以鼓励团队集体变更,拥抱变化。


↙↙↙阅读原文可查看相关链接,并与作者交流