软件研发行业到底要不要考核？——从 KPI、OKR 到工程文化的一些思考
在软件研发行业中，绩效考核几乎是一个绕不开的话题。
大多数公司都会有各种各样的考核体系：
- KPI
- OKR
- 绩效评级
- 末位淘汰
- PIP（Performance Improvement Plan）
但如果仔细观察技术行业，会发现一个很有意思的现象：
越优秀的技术团队，往往越不依赖复杂的绩效考核体系。
例如：
- Google 早期工程团队
- Netflix 工程文化
- GitHub 早期团队
- Basecamp（原 37signals）
这些团队在快速成长阶段，并没有复杂的 KPI 体系。
这就引出了一个值得思考的问题：
在软件研发行业中，绩效考核究竟解决了什么问题？
一、管理学视角：绩效考核从哪里来
绩效管理并不是现代互联网公司发明的概念。
早在 1954 年，管理学家 Peter Drucker 就在其著作《The Practice of Management》中提出了一个重要思想：
Management by Objectives（MBO，目标管理）
参考资料：https://en.wikipedia.org/wiki/Management_by_objectives
MBO 的核心思想是：
通过明确目标，使员工的工作与组织目标保持一致。
后来，大量绩效管理方法都从 MBO 演化而来。
KPI
KPI（Key Performance Indicator）强调：
通过指标量化组织目标。
参考资料：https://en.wikipedia.org/wiki/Performance_indicator
KPI 在以下行业中非常有效：
- 制造业
- 销售团队
- 呼叫中心
- 金融服务
这些行业有一个共同特点：
产出容易量化。
例如：
- 销售额
- 订单数量
- 客户数量
- 生产件数
但软件研发工作却并不完全符合这种模式。
二、软件工程研究：研发绩效很难量化
软件工程领域其实很早就意识到了这个问题。
著名计算机科学家 Fred Brooks 在经典著作《The Mythical Man-Month》中写过一句非常有名的话：
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
参考资料：https://en.wikipedia.org/wiki/The_Mythical_Man-Month
翻译过来就是：
用代码行数衡量程序员的工作，就像用飞机重量衡量飞机制造进度。
这句话后来被软件工程领域反复引用，因为软件开发有几个明显特征。
1、软件开发是一种创造性工作
软件开发更像：
- 工程设计
- 系统建模
- 创造性解决问题
而不是重复劳动。
两个工程师完成同一个任务，效率差异可能是数倍甚至十倍。但这种差异很难用简单指标衡量。
2、软件系统的复杂度极高
大型软件系统的复杂度通常呈指数增长。
很多工程工作的价值在于：
- 降低复杂度
- 提高可维护性
- 提高系统稳定性
这些价值往往很难短期量化。
3、很多技术价值具有延迟性
例如：
- 架构重构
- 技术债治理
- 自动化测试建设
- 基础设施优化
这些工作在短期 KPI 中往往看起来”没有产出”，但长期价值非常大。
三、Goodhart 定律：指标一旦成为目标就会失效
在经济学中有一个非常著名的定律：
Goodhart’s Law
参考资料：https://en.wikipedia.org/wiki/Goodhart%27s_law
它的核心观点是：
When a measure becomes a target, it ceases to be a good measure.
翻译成中文就是：
当一个指标变成目标时，它就不再是一个好的指标。
在软件团队中，这种现象非常常见。
例如：
如果 KPI 是 Bug 数量，研发可能会：
- 减少 Bug 记录
- 延迟 Bug 上报
如果 KPI 是 提交次数，工程师可能会：
- 刻意拆分 commit
当指标成为考核目标时，行为就会随之改变。
四、OKR 的出现：试图解决 KPI 的问题
OKR（Objectives and Key Results）最早由 Andy Grove 在 Intel 推广。
参考资料：https://en.wikipedia.org/wiki/OKR
后来被 Google 大规模使用。
Google 对 OKR 的解释可以参考：https://rework.withgoogle.com/guides/set-goals-with-okrs/
OKR 的核心思想是：
- 目标驱动，而不是指标驱动
- 鼓励挑战性目标
例如：
目标： 提升系统稳定性
关键结果：
- 故障率降低 50%
- 自动化测试覆盖率达到 80%
OKR 的设计初衷其实是：
弱化绩效考核的控制属性。
但在很多公司中，OKR 最终变成了：
另一种 KPI。
五、真实案例：当考核脱离管理目标
理论上的绩效考核是为了提升组织效率。
但在现实企业中，很多考核制度的出现，往往并不是出于管理设计，而是源于管理情绪。
下面是我自己经历过的一些真实案例。
案例一：一次”情绪驱动”的考核制度
有一次，公司发生了一件小事，让老板对研发团队有些不满。
第二天一早，公司突然推出了一套研发绩效考核方案。
这套方案的问题在于：
你一眼就能看出来，它几乎和研发效率没有关系。
很多指标明显只是为了增加约束，而不是为了提升效率。
在制度发布之前，公司的一些关键角色甚至提前给我打了”预防针”：
“这个事情你别发作，先配合一下，不然大家都不好看。”
原因也很简单：
- 这个方案不是我能改的
- 如果我公开反对，只会让场面更尴尬
于是我选择了沉默。
但结果很快就出现了。
制度发布后的第二天，接近一半研发成员找我谈离职。
大家的反馈几乎一致：
“这个考核明显不是为了做事。”
很快，老板也意识到问题的严重性。
这套考核制度上线没多久就不了了之了。
案例二：代码行数考核
有一次领导跟我讨论研发考核指标时，提到过一个想法：
“能不能把代码行数作为一个指标？”
这个想法其实非常典型。
因为从管理视角来看，代码似乎是最容易量化的东西。
但如果真的用代码行数考核，优化方法非常多：
- 重构代码
- 拆分函数
- 增加日志
- 自动格式化代码
甚至仅仅运行一次代码格式化工具，都可能增加大量代码行。
如果真这么考核，那我很可能很快就会成为：
全公司代码行数第一的”代码 king”。
但很显然，这并不意味着软件质量更好。
案例三：Bug 数量考核
还有一个朋友的公司曾经设计过这样一套考核制度：
- 研发团队考核： Bug 数量
- 测试团队考核： 提交 Bug 数量
乍一看似乎很合理。
但仔细想想就会发现一个问题：
双方的激励机制完全相反。
- 研发希望：Bug 越少越好
- 测试希望：Bug 越多越好
最终大家的目标就变成了一件事：
谁也别想好过。
这其实正好印证了 Goodhart 定律。
六、绩效考核什么时候才真正有用
这并不意味着绩效考核完全没有价值。
在某些情况下，绩效考核确实是必要的。
1、团队规模扩大
当团队规模达到几十人甚至上百人时：
管理者很难了解每个人的具体工作。
这时候考核体系可以作为一种管理工具。
2、团队效率明显下降
如果团队出现：
- 需求延期严重
- Bug 大量增加
- 工作推诿
考核体系可以帮助重新建立秩序。
3、组织进入成熟阶段
在成熟企业中，绩效考核往往用于：
- 奖金分配
- 人才梯队管理
七、优秀技术团队真正依赖的是什么
很多优秀的软件公司在工程文化上有一个共同特点：
高信任 + 高责任。
例如：
Netflix 工程文化强调：
Freedom and Responsibility
参考资料：https://jobs.netflix.com/culture
类似的工程文化也存在于：
- GitHub Engineering：https://github.blog/engineering/
- Basecamp：https://basecamp.com/books
这些公司更强调：
- 工程文化
- 团队责任
- 技术判断
而不是复杂的绩效体系。
八、一个现实观察
在很多公司中，当管理层开始：
- 强化 KPI
- 严格绩效排名
- 大量使用 PIP
往往意味着：
组织正在面对增长压力。
这并不一定意味着企业一定会失败。
但通常说明：
管理层开始用制度替代文化。
九、结论
软件研发是一种高度创造性的工作。
相比复杂的绩效制度，真正决定团队效率的往往是：
- 清晰的目标
- 优秀的人才
- 健康的工程文化
- 懂技术的管理者
如果这些因素存在，考核体系往往可以非常简单。
如果这些因素不存在，再复杂的 KPI 体系也很难解决问题。