我认为敏捷社区要改变评测敏捷团队是否成功的方法。我们收集指标以及从这些指标中获取信息的方法实际上妨碍了我们做出能用的软件，而这才是最重要的东西。
强推个体指标有时会导致过于关注其他人，影响团队的协作。这会歪曲我们要评测的内容，摧毁我们的真实意图。
在我看来主要有两个问题：
观察者效应： 观察者效应是指对一个流程进行观测可能会影响它的输出。比如告诉一个团队你会密切关注他们的速度，该团队可能会为了加快速度而过度估算他们的工作内容。这在处理 故事点 时尤其危险，因为根本就没有依据可以判断估算是否有效。
尽管上面这幅漫画中的情况很有可能发生过，但并不是我理想中观察者效应的例子。我给你们讲一个我很久之前认识的技术支持工程师，我们叫他“杰森”好了，因为他的名字就是杰森。杰森是一位优秀的技术支持，在别人遇到特别困难的问题时他会施以援手，一般在客户打来第一个电话时他就能正确地把问题解决掉，而且客户对他的评价很高。问题是杰森接电话的时间太长，而这一指标对管理层来说非常重要。后来经过几次会议和一次考核之后，杰森明白他必须把时间缩短，否则就只能另谋高就了。很快几周就过去了，杰森的呼叫时长在整个支持团队中排到了前5名。他是怎么做到的呢？如果不是我有一天接他班时提前到了一个小时，他可能永远都不会跟人讲起其中的秘密，那天我发现他原来是接了电话之后马上就挂掉了。
这挺有点儿意思，如果杰森的呼叫时长没有他的真实绩效重要，他就不会干那种事。以呼叫时长为指标评测他对产出产生了负面影响。除了这个糟糕的指标之外，即便没碰到过杰森这么极端的情况，我们也都遇到过只想尽快让你挂上电话的技术支持。问题是你的团队为了让自己的数值更好看挂了哪些电话？
路灯效应：路灯效应是指我们人类倾向于寻找更容易的答案，而不是真实的信息。比如计算代码行数就很简单，但代码行数并不能告诉我们程序的质量如何，也不能表明程序提供的功能性甚至效率怎么样。
我想起以前曾经工作过的一个团队，我们做了几个产品，每个产品的质量标准都不一样。当时的情形是“产品A”的质量标准要难得多，而产品B、产品C或产品D的质量标准不会是什么太大的问题，除非管理层在下次审查临近时改变了对这些产品质量的要求。
问题是“质量”这个概念有点模糊，真的不太好评测。而错误率就容易测量得多，因此那些做产品A这个质量标准比较高的产品的人，在面对审查时就更加不利。那这份工作最终是由谁来完成的呢？大部分是实习生、临时工或做外包的那些人，或者其他任何人，总之没人愿意参与。
事实证明，即便是容易测量的错误率，也不能给出什么有价值的信息，因为出现错误的次数更多是由产品而不是员工决定的。我们反而赶走了几个不错的新员工，丢掉了客户，整个团队的士气也受挫了，因为他们工作时考虑更多的是在如何避免错误，而不是如何构建产品。
因为这两个都不是软件开发的例子，所以接下来我们把这些概念放到一些常见的、你所熟悉的“敏捷”指标上。容易测量的指标有哪些？
