本文共计1407字,建议阅读时间:3分钟。
阅读本文你将收获:
1、从生产管理推导出简化的研发效能度量模型
2、几款有赞研发效能团队正在采用的创新度量指标
3、如何借助效能度量来改进研发实践
前言:我们邀请到有赞研发效能团队负责人费解老师参与 DevData Talks 直播活动,分享了《有赞研发效能度量实践》。以下是干货内容整理。
嘉宾介绍:费解,有赞研发效能团队负责人,程序员出身,2016年加入有赞,用友PMP、PRINCE2、CSM、LeSS、六西格玛黄带、ITIL等多项认证和职业资格,正在国企、外企、外包和互联网企业等不同环境下从事项目管理和效能改进工作。
『科学管理』之父泰勒提出,科学管理的根本目的是谋求最高劳动生产率,重要手段是用科学化、标准化的管理方法代替经验管理。
在软件研发行业,生产资料包括了人和机器两大类,这两类生产资料各有长处:
• 人的特点:具备业务的理解和创新能力
• 机器的特点:能快速无误地执行既定命令
从生产资料的视角,我们可以思考如何使人与机器各自发挥优势,实现生产率提升。可以简单分为三个思路:
1. 挖掘人的创造力,帮助开发者做得更好
2. 提高机器的执行效率,保障基础设施合理、方便、易用
3. 让机器分担部分原先需要人力投入的重复性工作,进一步释放开发者的创造性
基于这三个思路,我们可以梳理出一个全局框架,涵盖每个思路下的度量对象与相应度量方法。再从全局框架中挑选出适合业务与工程现状的对象,搭建起研发效能度量体系。
项目浓度指标的计算公式是:项目浓度 = 项目工作量人日 /(研发周期*参与人数)。这个指标的侧重是某个项目中的资源利用率。
相比需求吞吐量,研发浓度是一个过程性指标,可以在项目进程中持续被度量,先验性地反映研发效率;相比研发交付周期(流动效率,价值接收方视角)和资源利用率(员工的工作饱和度,资源效率,价值输出方视角),研发浓度处于二者之间,既能反映研发资源是否有效利用,也能在某一项目的视角下预判交付情况。
开发者掌握的功能模块和技能全面、外界打扰少、工作流简洁无依赖,都会带来更高的研发浓度。但在实践中,追求 100% 的研发浓度是不现实的。
这个指标的意义在于帮助研发团队寻找典型案例,发掘可复用的优秀实践,以及协作行为、能力、项目管理、工具集等方面的提效机会。
需求波动指在一定时间范围内的,研发团队的需求总量与交付需求数量趋势与离散程度(用样本标准差来反映)。这个指标可以用于部门或项目级的横向对比,寻找生产平稳程度较差的关键下钻点。
如果研发团队进行工程改进试点,需求波动可以作为反映改进效果的指标之一。例如某团队正在试点敏捷转型,那么需求波动可以反映交付模式调整是否给需求管理、项目管理带来了正向的变化。
基于有赞的研发效能实践,以下总结三条原则,能够帮助研发效能团队与业务研发团队达成共识,共同推进度量落地。
效能度量源头是数据观测,呈现>评价。客观现象的呈现本身就有价值,避免呈现之上附加太多判断评价,引起业务研发团队抵触
度量抓手是指标被共同看见后的价值,我以为>你觉得。效能团队与业务研发团队应达成共识,以专业知识提供支持,引导业务团队主动发现问题,避免单向输出。
度量是反映自管理效果的镜子,意愿>命令。在感知问题的基础上,效能团队应引导业务团队主动思考改进策略,让最了解上下文的角色去主导改进。
如果您想了解更多关于本次演讲的内容,可以联系思码逸团队获取演讲视频和演讲PPT;
——————————————————————————————————————
思码逸 Merico 研发效能分析平台,致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点,提升研发效率与软件工程质量;
欢迎在评论区与我们交流~更多咨询可以在公众号:思码逸研发效能 获取。