---
title: 软件研发行业到底要不要考核？——从 KPI、OKR 到工程文化的一些思考
author: Gamehu
date: 2026-03-19 23:00:00
tags:
  - 技术管理
  - 团队建设
  - 绩效考核
  - 工程文化
categories:
  - 技术管理
---

在软件研发行业中，绩效考核几乎是一个绕不开的话题。

大多数公司都会有各种各样的考核体系：

- KPI
- OKR
- 绩效评级
- 末位淘汰
- PIP（Performance Improvement Plan）

但如果仔细观察技术行业，会发现一个很有意思的现象：

**越优秀的技术团队，往往越不依赖复杂的绩效考核体系。**

例如：

- Google 早期工程团队
- Netflix 工程文化
- GitHub 早期团队
- Basecamp（原 37signals）

这些团队在快速成长阶段，并没有复杂的 KPI 体系。

这就引出了一个值得思考的问题：

> 在软件研发行业中，绩效考核究竟解决了什么问题？

---

# 一、管理学视角：绩效考核从哪里来

绩效管理并不是现代互联网公司发明的概念。

早在 1954 年，管理学家 [Peter Drucker](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Andrew_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。**

---

# 五、真实案例：当考核脱离管理目标

理论上的绩效考核是为了提升组织效率。

但在现实企业中，很多考核制度的出现，往往并不是出于管理设计，而是源于管理情绪。

下面是我自己经历过的一些真实案例。

## 案例一：一次"情绪驱动"的考核制度

有一次，公司发生了一件小事，让老板对研发团队有些不满。

第二天一早，公司突然推出了一套研发绩效考核方案。

这套方案的问题在于：

**你一眼就能看出来，它几乎和研发效率没有关系。**

很多指标明显只是为了增加约束，而不是为了提升效率。

在制度发布之前，公司的一些关键角色甚至提前给我打了"预防针"：

> "这个事情你别发作，先配合一下，不然大家都不好看。"

原因也很简单：

- 这个方案不是我能改的
- 如果我公开反对，只会让场面更尴尬

于是我选择了沉默。

但结果很快就出现了。

<span class="highlight-text">制度发布后的第二天，接近一半研发成员找我谈离职。</span>

大家的反馈几乎一致：

> "这个考核明显不是为了做事。"

很快，老板也意识到问题的严重性。

这套考核制度上线没多久就**不了了之了**。

## 案例二：代码行数考核

有一次领导跟我讨论研发考核指标时，提到过一个想法：

> "能不能把代码行数作为一个指标？"

这个想法其实非常典型。

因为从管理视角来看，代码似乎是最容易量化的东西。

但如果真的用代码行数考核，优化方法非常多：

- 重构代码
- 拆分函数
- 增加日志
- 自动格式化代码

甚至仅仅运行一次代码格式化工具，都可能增加大量代码行。

如果真这么考核，那我很可能很快就会成为：

> **全公司代码行数第一的"代码 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 体系也很难解决问题。

---

# 参考资料

1. [Management by Objectives - Wikipedia](https://en.wikipedia.org/wiki/Management_by_objectives)
2. [Performance Indicator - Wikipedia](https://en.wikipedia.org/wiki/Performance_indicator)
3. [The Mythical Man-Month - Wikipedia](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)
4. [Goodhart's Law - Wikipedia](https://en.wikipedia.org/wiki/Goodhart%27s_law)
5. [OKR - Wikipedia](https://en.wikipedia.org/wiki/OKR)
6. [Google OKR Guide](https://rework.withgoogle.com/guides/set-goals-with-okrs/)
7. [Netflix Culture](https://jobs.netflix.com/culture)
8. [GitHub Engineering](https://github.blog/engineering/)
9. [Basecamp Books](https://basecamp.com/books)