瞎逼逼：研发效能度量的得与失
内容提要
文章探讨了研发效能度量的挑战，指出传统的考核方式如工时计件制和代码行数统计无法真实反映程序员能力，且可能导致消极工作。虽然更高级的指标如函数重复率和圈复杂度更科学，但仍可能被操控。作者强调量化数据不能完全代表工作成果，需求调研和系统设计同样重要，需综合考虑团队实际情况。
延伸解读
量化指标为何总被“钻空子”
文章指出，从工时、代码行数到函数重复率、圈复杂度，任何量化指标都可能被有意操控。例如，开发者可以开分支先大改再改回，制造双倍工作量。这并非否定量化，而是提醒：指标越“科学”，规避手段也越隐蔽，单纯依赖数字考核容易陷入“道高一尺魔高一丈”的循环。
被忽视的“前期工作”价值
需求调研、系统设计和代码自测在考核中常被忽略，甚至排期时不算工时，但文章认为这些工作比写代码更重要。作者以扁鹊三兄弟为喻：防患于未然的大哥名气最小，却医术最高。同理，前期设计到位能避免后期大量返工，其价值难以量化，却直接影响项目成败。
考核方式如何影响团队行为
文章分析，低端考核如工时计件制导致内耗，升级版如代码行数、Bug率则引发抢简单需求、互相甩锅。即使Leader强调不看考勤和Bug率，团队思维习惯仍难改变。这说明考核方式不仅衡量结果，更会塑造行为——不当指标会诱导消极、短视的协作模式。
Q&A
传统的研发效能考核方式有哪些缺陷？
传统考核方式如工时计件制和代码行数统计无法真实反映程序员能力，可能导致消极工作。
更高级的研发效能指标有哪些？
更高级的指标包括函数重复率和圈复杂度，这些指标虽然更科学，但仍可能被操控。
为什么需求调研和系统设计在研发中重要？
需求调研和系统设计在软件开发过程中比动手写代码更为重要，但往往被忽视。
如何评估代码的复杂度？
可以通过圈复杂度来评估代码的复杂度，计算公式为V(G) = E - N + 2，其中E为边的数量，N为节点的数量。
量化数据在研发考核中有哪些局限性？
量化数据不能完全代表工作成果，且可能被操控，无法全面反映程序员的真实能力。
如何避免研发效能考核中的造假行为？
尽管有科学的量化指标，但仍需警惕造假行为，例如通过不当操作来提高个人业绩。
