因为一篇post – 我为什么翻译《程序员度量》，受邀参加Scrum Gathering Shanghai 2013的活动，话题是《程序员度量》。说真的，对这个话题我没有太大的自信，很容易触到一部分人的神经，而我本身又是一个不太善于争论的人。谢谢孙妮和老窦的鼓励。我决定从另外角度来说程序员度量的这件事——从我们之前的失败案例看起（起码从我的角度是这样）。我想从这样的角度会引起更大的共鸣，让大家明白其中的种种。作为一种反思的素材供大家参考，这是有帮助的。

现场的反映超出了我的预期，认识到有很多的朋友在关注这个问题，也有的朋友正在经历类似的煎熬和困惑：

• 短期的激励无法满足长久的发展
• KPI来限制团队或成员的工作行为，发现长久之后，丢失了一个研发团队本应有的激情和创新
• 绩效考核
• 度量的数据无法收集，或无法保证数据的有效性及一致性
• 是否需要花大量的精力来做这个事情

可能持反对意见者从这些问题会立刻得出这样的结论：度量方法害死了。

我本身亲历过这样的过程，而且很有幸多经历了几个角色，能更多地有同理心地去思考这些问题。如果真的需要度量，是否可以从几个方面做一些改进：

• 不做排名比较
• 不做限制工作行为的事
• 只获取团队动态的洞察力，用于管理者对团队的认识及发展调整
• 只做对你可以控制的面的度量，限定度量的范围
• 从你开始一个度量，也从你结束一个度量，不留下给别人利用你的度量耍流氓的机会。A制定度量的时候是为了获取团队动态，而B可能就会用来做团队排名。

说多无益，只是想请大家审慎地做出对人的度量这回事，目的和策略的不同，同样的事情，最后出来的结果是不同的。