瞎逼逼：研发效能度量的得与失
内容提要
本文讨论了研发效能度量的得与失，不同的度量方法都有各自的问题。文章认为量化数据不能完全代表工作量，应综合考虑其他因素。同时提到忽视需求调研、体系设计和代码自测等环节的问题。最后总结了改变思维习惯的困难。
延伸解读
量化考核的常见陷阱
文章指出，工时、代码行数、Bug数等量化指标容易导致不良竞争和内耗。例如，程序员可能追求代码行数而忽视质量，或推卸Bug责任。这些指标无法全面反映脑力劳动的价值，反而可能引发造假行为。
更科学的度量指标
圈复杂度和代码当量等指标试图更科学地衡量代码质量。圈复杂度通过控制流图计算，评估代码可测性和维护成本；代码当量基于AST分析变化，加权打分，避免单纯代码行数的弊端。但这些指标仍可能被规避。
被忽视的关键环节
文章强调，需求调研、体系设计和代码自测等环节在软件开发中至关重要，却常因难以量化而被忽视。这些工作如同扁鹊大哥的医术，防患于未然，但价值不易被认可。团队应重视这些环节，而非只关注编码。
平衡量化与人为判断
作者并非完全反对量化，但认为不能仅凭冰冷数字考核。应结合Leader对工作分配和产出的判断，区分事故性质：人为低级错误需追责，经验不足则总结改进。改变思维习惯困难，尤其在现有考核环境下。
Q&A
研发效能度量存在哪些主要问题？
研发效能度量存在得与失，不同度量方法各有问题，量化数据不能完全代表工作量，需综合考虑其他因素。
为什么工时计件制不适合程序员？
工时计件制不适合程序员，因为它容易导致内耗，无法准确反映脑力劳动的复杂性。
如何更科学地衡量代码质量？
可以使用圈复杂度和代码当量等新指标，这些指标能更科学地衡量代码质量，而不仅仅依赖于代码行数和Bug数量。
在软件开发中，哪些环节常被忽视？
在软件开发中，需求调研、体系设计和代码自测等环节常被忽视，这些环节实际上比动手写代码更为重要。
量化目标可能导致哪些不良后果？
量化目标可能导致造假、责任推卸和不良竞争，影响团队的合作和责任感。
改变思维习惯在研发效能度量中有多困难？
改变思维习惯非常困难，尤其在现有考核环境下，团队成员往往难以适应新的评估标准。
