今年开始带工程团队之后，绩效评估从“发生在我身上的事”变成了“我要负责主持的事”。写这篇文章一半是为了理清自己的思路，所以请把它当成摸索中的笔记，而不是标准答案。

到底为什么要做绩效评估

#

不管什么级别，目的归根结底就两条：让人能持续成长，让表现超出角色期望的人真正得到回报。

很多小公司说自己没时间没资源做评估，于是默默退回到只看工龄：谁待得久，谁就“该升了”。我认为这是个错误，而且不只因为工龄是个偷懒的指标。跳过评估，等于砍掉了公司和员工之间的双向沟通渠道，工作关系会因此变质。

这是双向的。工程师可能真心相信自己在用对公司最好的方式工作，但习惯、方法、沟通风格却在不知不觉中跑偏，没有反馈，就没人能发现。反过来，从不通过正式渠道听员工说话的公司，会舒舒服服地对员工的真实想法一无所知。

双方各自该带着什么期待进场

#

员工这边的清单并不复杂。他们想知道自己的工作和团队目标怎么对上，哪里做得好，哪里要改进，而且要具体，不是一句“加强沟通”。他们希望贡献被认可，希望认真聊聊职业发展和培训机会，希望整个流程公平、看工作本身而不是办公室政治。

站在我这边，我期待每个人带着自我评估来：自己觉得哪里做得好、哪里不行。我希望看到的是对反馈的开放态度，而不是辩护律师的开场陈词；希望能认真讨论未来目标，也希望听到他们对自己在团队中位置的真实感受。评估同时也是我做规划的时候：团队构成、潜在的晋升、谁需要哪种成长机会。

一套框架套不住所有工程师

#

工程团队里的人文化背景、经验、专长各不相同，同一份评估剧本不可能对每个人都有效。“一视同仁”和“公平对待”不是一回事，方式必须随个人的需要、职业阶段和贡献而调整。底线是：每位工程师的角色和职责都清晰明确，并且和薪酬真正匹配。

最容易出问题的地方是头衔和薪水。当有人对自己的职级感到模糊，或觉得自己该晋升了，含糊的鼓励就是毒药。有效的是具体：一起商定作为下一级别基准的具体挑战或项目目标，让晋升有客观标准，而不是靠感觉。薪酬同理。如果有人觉得报酬偏低，或想承担更多责任，就把可衡量的目标写进他的计划，写清楚下次评估前要做到什么才能支撑这个变化。然后到了下次评估，双方都得对着这份约定说话。

改进类的反馈也一样。针对具体短板的具体培训、工作坊或项目，有用；“继续提升技能”，没用。

基准从第一次面谈就开始定

#

和新下属的第一次评估面谈，主要就是定基线：这个角色到底包含什么、怎么支撑团队和公司目标；用哪些可衡量的结果来评判表现；近期和长期目标分别是什么。这也是聊公司文化和行为规范、反馈的频率和方式、可用的资源和导师支持、以及这个位置能看到的职业路径的好时机。没有一样是激动人心的，但做了这些，后面每一次评估都会轻松。

之后我用的议程

#

1. 闲聊。听起来不重要，但它能把房间里的紧张感卸掉，后面的对话会诚实得多。
2. 过一遍议程，谁都不会被某个话题打个措手不及。
3. 上次评估以来的成长。把进步明确说出来，人往往看不见自己的进步。
4. 当前表现，先讲优点。
5. 需要改进的地方，每一条都配上具体、现实的目标。
6. 职业规划，以及现在的工作是否真的朝着那个方向。
7. 下次评估前的目标和行动项。

KPI只有因人而设才有效

#

产品团队里工程师的KPI，必须同时贴合团队目标和个人。前端、后端、全栈的职责不同，初级和资深的差别更大。提交量也许能说明一个初级开发者的状态，但对一个主要产出是架构决策的资深工程师毫无意义。所以KPI要在对话中商定，而不是从模板里抄。

我关注的几个方面：

• 代码质量：错误率、编码规范的遵守程度、返工修bug的频率
• 项目交付：里程碑和期限的达成
• 创新与解决问题：效率改进、真正啃下来的硬问题
• 协作：代码评审、对团队目标和讨论的贡献
• 个人成长：学习目标的完成、认证、新掌握的技术
• 客户影响：用户反馈、上线功能的使用情况

在可量化这一侧，我最近对单元测试越来越感兴趣。InfoQ的这篇文章讨论了怎么把单元测试纳入绩效评估，既讲落地的机制，也讲它对团队文化的影响，主张用定性加定量的方式衡量代码健康度。如果你在找不把工程师简化成代码行数的KPI，值得一读。

不管选什么，都要在评估或1:1里一起商定，并随着角色、项目、技术的变化及时调整。没人认可过的KPI，只是一根用来敲打人的棍子。

我填的模板

#

我给每个人建一份文档，每次评估往里加一节，这样所有记录都在一个地方。骨架是这样的：

## 绩效评估：[姓名]，[周期]

**角色和职级：** [头衔，以及这个职级在本团队意味着什么]
**上次评估定下的目标：** [从上一节复制过来]

### 自评（工程师提前填写）
- 做得好的地方，举一两个例子
- 做得不好的地方，以及换作现在会怎么做
- 一年后想在做什么

### 上次目标的进展
- [目标]：达成 / 部分达成 / 未达成，附依据

### 优点（具体例子）
- [做了什么、什么时候、带来了什么改变]

### 待改进（每项配一个目标）
- [行为或技能] → [“更好”是什么样子]，截止 [日期]

### 职业发展与职级
- 对照下一个职级现在处在什么位置，还差什么

### 到下次评估前的目标
1. [可衡量的目标]
2. [可衡量的目标]

### 商定的行动项
- [谁] 在 [何时] 前 [做什么]

自评在面谈前一两天交上来，绝不在面谈时当场写。先读过它，谈话就不一样了：有一半的时候，我准备提的事工程师自己已经点出来了，面谈就可以直接用来商量怎么办。

自评问题

#

下面是我提前发出去的问题。它们故意问得很开放，这样回答告诉我的是一个人怎么看待自己的工作，而不只是做了哪些事：

• 上次评估以来，你最自豪的是什么？为什么是它？
• 你在哪里卡住过？什么能让你早点脱困？
• 队友或代码评审者给过你的哪条反馈，让你一直记着？
• 上次定的目标里，你觉得哪些达成了？哪些想放弃或调整？
• 接下来想学什么？现在的工作给了你这个机会吗？
• 作为你的经理，我哪些地方应该换个做法？

最后一个问题换来的尴尬沉默最多，换来的有用回答也最多。

具体的反馈是什么样子

#

大多数糟糕的评估反馈并不刻薄，而是含糊。区别看下面，右边是我努力去写的那种：

每一条具体的反馈都点出一件事，说明它带来了什么变化，再指向这个人接下来能做的事。这样写更费时间，所以我逼自己整个季度随手收集例子，而不是评估前一晚才拼命回想。

写下来

#

面谈结束后，写一份纪要：讨论的要点、提出的问题、行动项、双方认可的目标。听着很官僚，但正是这份书面记录，能避免六个月后那句“我们当时没这么说吧”。写下来的问题会被持续跟进而不是蒸发，行动项直接成为下次评估的开场议程，落在纸面上的目标也会被认真对待。

说到底，整个体系就这么几条：第一天就把期望讲清楚，KPI贴着人来定，凡事留记录，每个行动项都跟进到底。缺少双向对话和可衡量结果的评估就是走过场，而工程师从收到日历邀请那一刻起，就能闻出走过场的味道。