研发效能提升是该先度量还是直接开干

举报
敏捷江湖桃花岛张教主 发表于 2022/02/22 18:00:57 2022/02/22
【摘要】 研发效能提升,先度量你还是先引入实践直接开干

最近在这方面思考了下,有一点想法,马克下来。

度量和直接开做的选择:

效能提升实践两条路径:

  • 梳理价值流->度量->发现瓶颈->识别改进方向->引入改进实践
  • 梳理价值流->快速发现很可能的瓶颈->引入改进实践

第一种方式更系统,特别是对于一个有一定的基础的团队,常见的先进一些的互联网公司的团队,或者对于一个整个公司级的改进,这种情况下,我们无法很快的发现真正的瓶颈,那就用度量数据来说话。(见注2,避免陷入陷阱)

比如某集团从CTO角度要做效能提升,此时我们需要数据支撑说明现状和改进方向,而每个团队的瓶颈点可能不一样,即使是教练走访团队,虽然能发现一些瓶颈,但是缺少数据的情况下,光依靠交流,得出的结论不够严谨,另外就是太慢了。如果先搭建度量体系的话,那么面对上百个团队,可以很快得出结论。

 

第二种方式更快,适合基础弱一些的团队,他们的最大瓶颈很明显,或者没有合适的度量体系的团队(合适的度量体系见注解1)

比如我们给一个小团队做辅导,或者去一些小型公司辅导,我会粗暴的通过交流+看一些他们仅有的基础信息(比如jira上的报告,git上的记录等),给一些意见,此时客户不可能给你时间搭建度量体系。

 比如他的测试周期比较长,没有自动化测试导致回归测试一塌糊涂,那这瓶颈就很明显。

注1:度量体系没有拿来主义,创建度量模型,度量数据,度量体系需要较长的时间和技术基础,比如数据需要自动化获取就需要技术作基础,度量模型又需要基于公司业务模式创立,并且面对的团队,往往他们的开发方式差不太多,比如硬件开发和软件开发,价值流差很多,用同一个度量模型就不合适,即使是在同一家公司,对于这种情况,也要有不同的度量模型,确保度量模型适合你的团队。

注2:比较赞同何免老师在云效对外的讲解里的说法,不能为了度量而度量,否则就陷入了Good-heart陷阱。度量的目的,是为了解决核心问题。比如说,我们对产品质量比较看重,想知道产品当前质量如何,哪里需要改进,那这就是我们的核心问题,为了这个目的,我们思考了下质量体现在哪里,比如说线上缺陷密度,变更成功率,此时可以以这个指标作为结果指标,通过它来看我们的核心问题的结果如何。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200