敏捷开发框架︱详细解读《敏捷本土化实施框架》核心宣言（下篇）

 

用户目标高于内部指标

一、内部指标

在前面“敏捷实施的一些问题”中，我们列举了常见的两个问题：只针对内部进行度量和单一追求效率的问题。在工作过程中，进行度量和追求效率的提升是常用的管理手段和期望目标。在敏捷实施过程中，这两者也是经常采用的。

但是，在多个团队中，我们发现了一些不良气味，主要原因都在于“内部指标”。这里的内部指标有如下含义：

1.      很多度量指标，度量的都是团队或者组织的内部的工作过程，而且指标数量繁多。

究其原因，管理者为了掌控团队成员的工作情况，根据团队成员的日常工作行为，设置了繁多的度量指标。这些指标，一些能反映团队成员的工作量，比如代码行/日；一些能够反映的是工作过程，比如工时/日。这些指标有用吗？不能说没有，我们假定这些数据是真实的话，那么也能体现一些工作情况。但是，当一些团队把这些指标设置成KPI，进行绩效考核后，“考核什么就会得到什么”。当考核代码行，本来10行能够实现功能的，程序员会写出20行！当考核工作时长，本来2小时能够完成的工作就会拖拉到4小时完成。这个时候，这些指标的度量就变得没有价值，而且会造成大量的浪费。

KPI绩效考核方法是可以采用的，但是当对这些过程指标进行度量的话，就会变形失真。那么，为什么会繁多呢？因为，内部指标更直接，更容易获取，那么度量的越多，有时候越能在某些组织中体现出“价值”。

2.      追求效率的提升没有问题，但是如果没有正确的方向，就会变得没有意义。

 

追求效率提升，是当下敏捷实施或者说绝大多数企业组织追求的经营效果。基于此，组织也设置了花样繁多的度量指标。但是，很多组织在度量效率的时候，只是在监测提升“正确地做事情”。比如，在产研业务流中，在需求环节，有的会度量“功能数”；在研发环节，有的会度量“BUG关闭率”；在测试环节，有的会度量“测试用例覆盖度”。这些指标有价值吗？有。但是还不足够。

如果，组织一直在做业务流单环节的指标度量和绩效考核，确实能够提升各环节的效能。但是，对客户最终产生价值的是整条业务流的提升，而不是单点。产品功能做得多就能让用户更满意吗？功能质量好会不会到了一定程度就变得没那么重要了？

回归到敏捷变革，这里面就会涉及到当下敏捷业界关注的一个重点问题：如何做到业务敏捷。为什么会产生这个问题？因为诸多敏捷实践方法，已经能够把产研业务流里面的研发、测试、运维等环节的效率大大提升。但是，这些提升对于产品业务流里面的其他重要参与人：市场、产品、运营等人员，好像却没什么感觉。为什么？

因为，很多敏捷变革里面当前的效能提升措施只是针对业务流里面的单点环节进行的。单点环节效率提升了，能看到一些成效，但是，对整体业务流效能的提升并不大。所以说，我们要系统化思考整体业务流的效能提升。业务敏捷追求的正是整体业务流的提升。

因为，整体业务流效能的提升，不仅需要如何正确地做好，更要关注怎样做的是正确的事。

二、用户目标

 

用户目标的定义来源于创新大师克莱顿·克里斯坦森提出的“用户目标达成理论”（Jobs To Be Done）。用户目标是某个人在特定的情境下所追求的进步（process）。成功的创新可以让用户取得想要的进步，解决困难，而且实现未满足的愿望，取代之前有缺陷或不存在的解决方案。用户目标不只关乎功能，社会和情感层面的用户目标也很重要。有时，社会和情感层面的用户目标 可能比功能层面的用户目标更强大。用户目标通常都在日常生活中出现，所以界定用户目标时， 情境是核心，也是创新的关键，用户特质、产品属性、新技术或趋势等都不是创新的关键。

“用户目标”的提出，重新指出了企业的创新关键，也给企业的创新行为指明了方向。对于敏捷创新，也应该以实现用户目标为导向。敏捷实施中的效率提升和指标度量行为，也需要基于这个导向进行。

作者：《敏捷本土化实施框架》实践创建者、“组织敏捷转型周期”模型提出者 王凌宇

文章来源：凌宇哥聊敏捷创新