4.5 指标体系的局限性

每个组织都可以通过自己的判断（注意，是判断而不是分析，同时用左脑和右脑）得出自己在软件开发上要解决的启发性问题，得出自己的改进模型。特别值得注意的是，指标的分解过程跟从谜题到启发性问题，再到算法性问题的降解过程一样，损失了大量的上下文信息，因此：

●即使在指标上取得了亮丽的数字，也未必一定能够达成业务目标。这个分解的过程是帮助我们梳理主要矛盾，发现工作的关键点的一种有效方式，但是我们应该经常回到这个过程的上一级问题，重新审视当前这一级的目标是否仍然有效。

●脱离使用场景，单独使用某个指标，通常也没有什么实际意义。我们从前面的Big Bank项目中看到，绝大多数的决策事件都需要多个指标数据的支撑。

而且指标之间并不是独立的，比如努力缩短交付周期可能增加回归测试的次数，会潜在地降低开发组织的交付速率，而能力这个维度则对所有其他维度都会有影响。

那么，我们是否应该试图设计一套体系，直到让每个人都满意高兴了才能去部署呢？从前面的过程中可以看到，度量体系的设计本身蕴含了很多人为的主观判断和取舍，面临着不少的局限性，所以肯定不能满足所有人的诉求。如果那是我们的目标，我们最好现在就放弃，完美绝对不是设计一个度量体系所追求的目标。对业务目标有帮助，能起到引导作用才是我们实施度量体系的价值所在。