敏捷开发框架︱详细解读《敏捷本土化实施框架》核心宣言（下篇）
2022-11-09
来源：凌宇哥聊敏捷创新 ，作者王凌宇
用户目标高于内部指标
一、内部指标
在前面“敏捷实施的一些问题”中，我们列举了常见的两个问题：只针对内部进行度量和单一追求效率的问题。在工作过程中，进行度量和追求效率的提升是常用的管理手段和期望目标。在敏捷实施过程中，这两者也是经常采用的。
但是，在多个团队中，我们发现了一些不良气味，主要原因都在于“内部指标”。这里的内部指标有如下含义：
1. 很多度量指标，度量的都是团队或者组织的内部的工作过程，而且指标数量繁多。
究其原因，管理者为了掌控团队成员的工作情况，根据团队成员的日常工作行为，设置了繁多的度量指标。这些指标，一些能反映团队成员的工作量，比如代码行/日；一些能够反映的是工作过程，比如工时/日。这些指标有用吗？不能说没有，我们假定这些数据是真实的话，那么也能体现一些工作情况。但是，当一些团队把这些指标设置成KPI，进行绩效考核后，“考核什么就会得到什么”。当考核代码行，本来10行能够实现功能的，程序员会写出20行！当考核工作时长，本来2小时能够完成的工作就会拖拉到4小时完成。这个时候，这些指标的度量就变得没有价值，而且会造成大量的浪费。
KPI绩效考核方法是可以采用的，但是当对这些过程指标进行度量的话，就会变形失真。那么，为什么会繁多呢？因为，内部指标更直接，更容易获取，那么度量的越多，有时候越能在某些组织中体现出“价值”。
2. 追求效率的提升没有问题，但是如果没有正确的方向，就会变得没有意义。
追求效率提升，是当下敏捷实施或者说绝大多数企业组织追求的经营效果。基于此，组织也设置了花样繁多的度量指标。但是，很多组织在度量效率的时候，只是在监测提升“正确地做事情”。比如，在产研业务流中，在需求环节，有的会度量“功能数”；在研发环节，有的会度量“BUG关闭率”；在测试环节，有的会度量“测试用例覆盖度”。这些指标有价值吗？有。但是还不足够。
如果，组织一直在做业务流单环节的指标度量和绩效考核，确实能够提升各环节的效能。但是，对客户最终产生价值的是整条业务流的提升，而不是单点。产品功能做得多就能让用户更满意吗？功能质量好会不会到了一定程度就变得没那么重要了？
回归到敏捷变革，这里面就会涉及到当下敏捷业界关注的一个重点问题：如何做到业务敏捷。为什么会产生这个问题？因为诸多敏捷实践
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
