第135讲|钮博彦:软件研发度量体系建设(一)
文章目录
你好,我是美团高级技术经理钮博彦,主要负责美团点评研发工具栈的建设。我今天想跟大家分享的内容是,我们作为平台团队与业务线团队在软件研发度量中的实践及思考。我将从三个方面展开内容,第一,度量的意义;第二,研发度量体系;第三,度量平台建设。
度量的意义
为什么需要度量呢?因为我们在研发过程中总会遇到各种各样的问题,比如下面这三个典型问题:
1. 为什么我们做的产品与用户的期望总是存在差异呢?
2. 市场需求日新月异,这个功能可能还没开发,需求就已经变化了,对此,我们该如何提高团队的反应速度呢?
3. 现在的产品质量到底怎么样,为什么 bug 永远修不完?
这些问题都是我们在研发过程中经常遇到的,那我们应该如何解决这些问题,使团队更专注、更有效率、更有质量呢?这就是度量的意义所在,我们可以将它总结为三点。
第一,让目标更明确,比如让大家在项目开始时、研发过程中、项目结束后,对目标有共同的认识。
第二,让现状更清晰,度量可以告诉我们现状如何、效率如何、质量如何、流程如何以及问题所在。
第三,让改进更精准,关于如何完善质量流程、体系化研发过程的方法,我们并不缺乏专家学者与著作观点,那怎样找到适合自己团队的观点呢,就需要通过度量来实践。
研发度量体系
整体的研发度量体系可以从三个维度来考量:即价值、效率、质量。
一、价值
这里的价值,指的是我们要做正确的事,而不是有效率的做一些错误的事情。以此为出发点去架设研发度量体系,我们就可以思考三个问题,第一,怎样度量我们的团队正在做正确的事?第二,既然明确了正确的事情,我们怎样以最高效率交付它?第三,我们既做了正确的事,又很有效率,那交付是否符合我们的预期,符合用户的预期呢?
可能每个公司都有自己的价值指标体系,但整体可以分成两大类,就是商业价值和技术价值,每一类又可以细分为可度量价值与不可度量价值。
- 商业价值的可度量价值包括钱、订单量、DAU、转化率、停留时间等;不可度量价值则包括影响力、美誉度等。
- 技术价值的可度量价值包括 QPS、可用性、响应时间、故障恢复时间等;不可度量价值则包括技术竞争力等。
总而言之,不论是宏观的项目还是微观的产品,都会根据不同场景制定不同的度量指标,再根据这些指标,开始研发流程,并在过程中不断迭代,使交付结果越来越好。
举个例子,我们要做一个产品,开始立项时,定了一堆项目目标,比如 DAU 增长目标、订单量目标、技术目标等,跟上面提到的价值度量指标相关联。然后进入功能设计阶段,为这个产品设计了 N 个功能,以其中的某个功能 X 为例,接着就进入到功能 X 的研发流程阶段,包括评估与设计、开发与测试、发布上线、反馈与复盘等。
我们在流程实践上的创新之处在于,我们会把项目目标和需求目标相关联,将项目目标作为需求设计的目标之一,从实际结果看这个需求为整个项目目标分担了多少指标,比如做完这个需求,我们可以增长多少的订单量等。
其中,反馈与复盘特别重要,在需求上线之后,可能一周或一个月,我们就需要进行复盘,来判断它到底有没有达到预期。我接触的很多团队都会将复盘放到项目结束后,但我觉得在需求设计过程中进行复盘也很重要,相当于定期追踪。
因此,我们可以把整个项目流程分为三个阶段,即事前计划、定期追踪、事后复盘。这样做能带来什么价值呢?第一,我们所有的需求都是从价值出发,项目的所有参与人都明确目标,能够提升成就感;第二,拆解高价值需求,更早交付,提升 ROI;第三,把控需求质量,减少“三拍”需求,降低部门浪费。
二、效率
当我们确定价值以后,就需要考虑如何有效率的交付这些价值,我们来看下面这张交付周期图,这是一个非常典型的技术研发流程,包括需求评估、需求设计、待开发、开发、联调、待测试、测试、发布等环节。
那我们如何度量效率呢?有两个核心指标,一是吞吐率,二是交付周期。
首先来看吞吐率,吞吐率就是在单位时间内,团队能够交付多少产出。而对于产出的衡量,大家也是各有各的看法,有些团队以需求个数或故事点数来衡量,有些团队以价值来衡量,比如这个团队在一季度内为公司增收的盈利等。
我们可以从多个纬度出发综合衡量产出,因为单个纬度衡量可能会有不准确的情况。举个例子,假设张三一年写了 1000 行代码,李四一年写了 800 行代码,那张三一定比李四的效率高吗?不一定。再假设李四做了 20 个需求,张三做了 10 个需求,李四的效率一定比张三高吗?也不一定。所以,通过综合纬度衡量,可以更加确保对于吞吐率的度量结果的准确性。
再来看交付周期,顾名思义,就是一个需求从提出到上线所用的时长,可能有版本交付周期、需求交付周期、故障修复周期等等,这些都属于交付周期的范畴。
明确了效率的两个核心指标,下面我们来看如何操作能够帮助我们更好地度量效率。
我们在交付周期的衡量中用了两个典型的项目管理工具,一是累计流量图,帮助我们定位瓶颈。如下图:
这张累计流量图的横轴是时间,纵轴是需求个数,我们可以对照某一个切片来看这一天处于各个状态的需求个数,而红色区域和蓝色区域就是我们团队的瓶颈,我们大部分需求都是卡在这样的阶段。
二是价值流程图,它可以告诉我们,需求卡在每个阶段的平均时间。如下图,从这张图中可以看到,我们在待处理阶段与开发阶段停留的时间比较长。
综合累计流量图与价值流程图,我们能够得知几个常见问题:
1. 需求阶段,需求质量差,需求评估设计时间过长等。
2. 测试阶段,测试数据、环境准备成本较高,自动化测试率低等。
3. 开发阶段,手工重复的工作很多,联调时间长,代码质量差等。
除了上述 3 个问题,可能还有一些整体的人员瓶颈,比如开发人员少,待开发排序的时间就长,类似这样的问题我们可能会在人员结构上进行调整,或者是提高大家的技术能力等等。
总而言之,从效率这个维度来看研发度量体系,我们主要可以获益三点:第一,识别团队瓶颈,优化短板,减少资源浪费;第二,缩短交付周期,提高吞吐率,提升市场反应速度;第三,对团队产能预估更准确,提高团队工作幸福度。
最后,由于篇幅受限,今天就主要分享度量的意义和研发度量体系的前两个维度,即价值和效率,关于研发度量体系中的质量指标以及度量平台建设,我会在下一篇文章中继续分享。欢迎持续关注。
感谢收听,我们下期再见!如果你觉得这篇文章对你有帮助的话,也欢迎把它分享给更多的朋友。
作者简介
钮博彦,美团高级技术经理,负责美团点评整体的研发工具栈建设。曾就职于微软中国、雅虎北研、唱吧等公司,从事系统开发、DevOps 和质量保障等相关工作。一直专注于提升研发整体质量与效率,及其流程和平台建设。
文章作者 anonymous
上次更新 2024-03-26