为什么研效衡量吸睛，但续约者廖廖
持
乔梁约 6 分钟
乔梁约 6 分钟1
度量本身很昂贵：它需要人度量工作流程，分析结果，并将结果发布给公司的其他部门。 度量本身也很繁琐，可能减缓了工程组织的其他工作。 即使度量并不缓慢，但是跟踪过程中可能会改变工程师的行为，可能会掩盖潜在问题。
你期待什么结果，为什么？ 如果数据支持的预期结果，将采取什么行动？ 如果我们得到一个负面的结果，会采取适当的行动吗？ 谁将决定对结果采取行动，他们将何时采取行动?
现在你无力变更流程或者工具。 任何结果不久都会因为其他因素而无效。 结果将仅用作虚荣心指标，以支持你无论如何都要的事情。 仅有的度量指标不够精准，不足以度量问题，而且可能会与其他因素混淆。
2
目标（Goal）：期望达到的结果。它是用来表达你想了解的较高层次上的东西，而且它不应该指定某种具体的度量指标。 信号（Signal）：用来判断我们是否已经得到了最终结果的东西。信号是我们想要度量的东西，但是它本身很可能无法直接度量。 指标（Metric）：信号的处理。这是我们事实上可以度量的东西。它可能不算是非常理想的衡量标准，但是我们认为它已经足够接近了。 要防止“路灯效应”：如果你去亮的地方找你想要的东西，那你可能找错了地方。 如果只是用那些我们易于理解且易于度量的指标，而不管这些指标是否适合我们的需求时，就会出现这种情况。
3
当一个指标本身成为唯一追求的目标时，它就不再是一个好的衡量项。
这就是古德哈特定律。这一定律还有一个推论，即：
一切科学评估的度量，都注定会被滥用（玩弄）。
当前， 很多 IT 管理者都在寻找一套完美的衡量指标，希望一劳永逸地解决软件工程管理问题。然而，他们在这条路上一直碰壁。因为软件工程问题不只是技术问题，它是一个社会学问题。
软件开发目前还仍旧是依赖 手工+ 脑力的劳动。Facebook 八年的数字证明，虽然 Facebook 从2008年开始，工程师人数不断增长，但是人均日代码量并没有增加，基本保持稳定。
工具的使用并不能让工程师的人均日代码生产量增加。当前，DevOps 工具的使用还仅仅是辅助工具，做得好一些，可以让使用者在工作时感到心情好，但它并非生产力的绝对提升因素。
它的一个很大的作用是透明，将工作透明出来。然而，由于其生产工序并不绝对地标准化，工作量的评估一直都是一大难题，所以它更多的依赖于工程师的个人技能与经验。所以，只有通过近距离观察，才能做到工作透明。
这在当前现状下，基本是一个不可能完成的任务。所以，所有的度量工具在刚刚引入时，好像还有点儿作用。但是，一旦人们对它了解和熟悉了，由于上面说的原因，基本就不是很奏效了，除非你的衡量最终不用于工作流程中的执行人。然而，这种原始手艺活儿的大规模地应用，就是很困难的。
如何才能解决这种问题呢？一个必要条件就是要有足够的人才密度。过去软件行业的大发展，使得我们没有时间训练更高技能的从业者。也许，接下来会有几年的时间了。又或者 AI 的发展让整个行业都不再依赖于手工编码。