阿里妹导读:衡量技术团队的效能,是不是只要摆出一堆数字指标就行?对交付价值的定义,通常有哪些误区?好的量化指标,一定会带来好的结果吗?本文从定义、衡量交付价值、研发成本、交付时长以及细化指标四个方面,分享如何量化效能。
提高技术团队的效能
增加总的价值交付率和交付质量
增加单位研发成本的平均交付价值
降低单位价值的平均交付时长
定义、衡量交付价值
定义、衡量研发成本
定义、衡量交付时长
细化指标
二 如何定义交付价值?
哪些功能自研、哪些功能靠购买,有时候真的得算一笔帐。
软件开发是一个边际成本递减的行业,如何让功能更简单的得到复用,可能是对效能提升最有帮助的部分之一(复用50个人日的功能模块,就几乎等于省了50人日的研发成本。当然也可能存在复用及后期维护的成本大于新建成本的情况,需要有良好的设计去规避)。
衡量交付时长其实也比较简单,记录下业务提出该功能的时间以及功能开发的时间。难点可能是整个价值流交付过程中细化的指标,而细化的指标更能帮助我们发现问题。于是我们可以从一般项目的生命周期来看,哪些节点的时长会影响我们的交付:
需求立项到评审的时长
需求评审到技术方案评审的时长(如果项目很大可能会有多个层次的设计方案)
技术方案评审完成到开发完成自测的时长
自测的时长
多端联调的时长
测试的时长
bug验证的时长,bug的数量(reopen可以数量+1)
环境部署等待的时长
代码合并的时长(主干发布的情况下)
回归的时长
发布的时长
灰度的时长
这部分对于提升效能容易忽视或有启发的点是:
需求的拆分成基本的功能闭环进行迭代(以不引入或少引入测试的重复回归为标准),或许能比较有效的降低需求价值量的平均交付时长。
自测充分、减少bug数量,最终减少联调、测试回归的次数和时长,在一定的单测覆盖率要求以前,是收益大于成本的。
代码合并有时候冲突解决很麻烦,会导致一次部署的时间很长,且代码合并引入了更多次的测试回归工作(这可能是某些BU往主干开发分支发布走的原因之一)。所以基于业务的理解,进行应用的拆分,减少单个应用的并发数量,也可以提升研发效能。
在缺乏有效的项目管理的情况下,资源的相互等待可能是项目延期的一大因素,有时候某端开发完了,另一端资源没到位,一直不能联调提测。项目管理的同学对于资源目前的分工和瓶颈应该给上游及时的反馈。
容易陷入误区的点是:
技术方案(架构、详细设计)的评审既然是很大的一块耗时,是不是可以直接写代码,少写方案。我理解在技术方案写不熟练的情况下,写技术方案确实比较耗时。但是技术方案体现的是分析设计的过程和结果,这部分如果不写出来,增加的是大量的沟通成本。而分析设计就算不写出来,这部分工作量在编写代码的时候也是没办法省略掉的,只是变成了在大脑中进行(也许在大脑中真的不如在纸上写出来来的快和清晰,真的省略了设计,最终就会成为技术负债)。我个人感觉对于多大的需求需要技术方案评审的比较好的实践,是以Code Review能否不基于技术方案直接阅读代码为准。
某项指标变好,带来的是其他指标的降低,局部最优并非全局最优(如:取消技术方案的编写和评审,造成的是编码时间或者后期维护时间的增加)。
效能是多个变量共同作用的结果,缺乏理论基础和方法论的情况下,很可能在短期优化指标的时候,忽略了长期的团队成长、系统能力沉淀等因素;或是忽视了业务方满意度等难以量化的因素。
研发效能肩负着提升企业产品交付和创新能力的责任。本课程将从研发效能的定义和度量着手,逐渐深入解析来自不同业务部门提升持续交付能力的实践、方法和工具,同时还将分享如何基于持续交付能力,切实提升产品和业务创新的效率和效果。
点击“阅读原文”,开始学习吧~