对软件工程师来说，有用的绩效评估是一场双向对话，而不是一纸判决。工程师带着自评来，经理带着具体的例子来，散会时双方手里有两三个一起商定的可衡量目标，还有一份书面记录。下面是我怎么主持一场评估、我填的模板，以及具体的反馈和含糊的反馈放在一起是什么样子。
今年开始带工程团队之后，绩效评估从“发生在我身上的事”变成了“我要负责主持的事”。写这篇文章一半是为了理清自己的思路，所以请把它当成摸索中的笔记，而不是标准答案。
到底为什么要做绩效评估#
不管什么级别，目的归根结底就两条：让人能持续成长，让表现超出角色期望的人真正得到回报。
很多小公司说自己没时间没资源做评估，于是默默退回到只看工龄：谁待得久，谁就“该升了”。我认为这是个错误，而且不只因为工龄是个偷懒的指标。跳过评估，等于砍掉了公司和员工之间的双向沟通渠道，工作关系会因此变质。
这是双向的。工程师可能真心相信自己在用对公司最好的方式工作，但习惯、方法、沟通风格却在不知不觉中跑偏，没有反馈，就没人能发现。反过来，从不通过正式渠道听员工说话的公司，会舒舒服服地对员工的真实想法一无所知。
双方各自该带着什么期待进场#
员工这边的清单并不复杂。他们想知道自己的工作和团队目标怎么对上，哪里做得好，哪里要改进，而且要具体，不是一句“加强沟通”。他们希望贡献被认可，希望认真聊聊职业发展和培训机会，希望整个流程公平、看工作本身而不是办公室政治。
站在我这边，我期待每个人带着自我评估来：自己觉得哪里做得好、哪里不行。我希望看到的是对反馈的开放态度，而不是辩护律师的开场陈词；希望能认真讨论未来目标，也希望听到他们对自己在团队中位置的真实感受。评估同时也是我做规划的时候：团队构成、潜在的晋升、谁需要哪种成长机会。
一套框架套不住所有工程师#
工程团队里的人文化背景、经验、专长各不相同，同一份评估剧本不可能对每个人都有效。“一视同仁”和“公平对待”不是一回事，方式必须随个人的需要、职业阶段和贡献而调整。底线是：每位工程师的角色和职责都清晰明确，并且和薪酬真正匹配。
最容易出问题的地方是头衔和薪水。当有人对自己的职级感到模糊，或觉得自己该晋升了，含糊的鼓励就是毒药。有效的是具体：一起商定作为下一级别基准的具体挑战或项目目标，让晋升有客观标准，而不是靠感觉。薪酬同理。如果有人觉得报酬偏低，或想承担更多责任，就把可衡量的目标写进他的计划，写清楚下次评估前要做到什么才能支撑这个变化。然后到了下次评估，双方都得对着这份约定说话。
改进类的反馈也一样。针对具体短板的具体培训、工作坊或项目，有用；“继续提升技能”，没用。
基准从第一次面谈就开始定#
和新下属的第一次评估面谈，主要就是定基线：这个角色到底包含什么、怎么支撑团队和公司目标；用哪些可衡量的结果来评判表现；近期和长期目标分别是什么。这也是聊公司文化和行为规范、反馈的频率和方式、可用的资源和导师支持、以及这个位置能看到的职业路径的好时机。没有一样是激动人心的，但做了这些，后面每一次评估都会轻松。
之后我用的议程#
- 闲聊。听起来不重要，但它能把房间里的紧张感卸掉，后面的对话会诚实得多。
- 过一遍议程，谁都不会被某个话题打个措手不及。
- 上次评估以来的成长。把进步明确说出来，人往往看不见自己的进步。
- 当前表现，先讲优点。
- 需要改进的地方，每一条都配上具体、现实的目标。
- 职业规划，以及现在的工作是否真的朝着那个方向。
- 下次评估前的目标和行动项。
KPI只有因人而设才有效#
产品团队里工程师的KPI，必须同时贴合团队目标和个人。前端、后端、全栈的职责不同，初级和资深的差别更大。提交量也许能说明一个初级开发者的状态，但对一个主要产出是架构决策的资深工程师毫无意义。所以KPI要在对话中商定，而不是从模板里抄。
我关注的几个方面：
- 代码质量：错误率、编码规范的遵守程度、返工修bug的频率
- 项目交付：里程碑和期限的达成
- 创新与解决问题：效率改进、真正啃下来的硬问题
- 协作：代码评审、对团队目标和讨论的贡献
- 个人成长：学习目标的完成、认证、新掌握的技术
- 客户影响：用户反馈、上线功能的使用情况
在可量化这一侧，我最近对单元测试越来越感兴趣。InfoQ的这篇文章讨论了怎么把单元测试纳入绩效评估，既讲落地的机制，也讲它对团队文化的影响，主张用定性加定量的方式衡量代码健康度。如果你在找不把工程师简化成代码行数的KPI，值得一读。
不管选什么，都要在评估或1:1里一起商定，并随着角色、项目、技术的变化及时调整。没人认可过的KPI，只是一根用来敲打人的棍子。
我填的模板#
我给每个人建一份文档，每次评估往里加一节，这样所有记录都在一个地方。骨架是这样的：
## 绩效评估：[姓名]，[周期]
**角色和职级：** [头衔，以及这个职级在本团队意味着什么]
**上次评估定下的目标：** [从上一节复制过来]
### 自评（工程师提前填写）
- 做得好的地方，举一两个例子
- 做得不好的地方，以及换作现在会怎么做
- 一年后想在做什么
### 上次目标的进展
- [目标]：达成 / 部分达成 / 未达成，附依据
### 优点（具体例子）
- [做了什么、什么时候、带来了什么改变]
### 待改进（每项配一个目标）
- [行为或技能] → [“更好”是什么样子]，截止 [日期]
### 职业发展与职级
- 对照下一个职级现在处在什么位置，还差什么
### 到下次评估前的目标
1. [可衡量的目标]
2. [可衡量的目标]
### 商定的行动项
- [谁] 在 [何时] 前 [做什么]自评在面谈前一两天交上来，绝不在面谈时当场写。先读过它，谈话就不一样了：有一半的时候，我准备提的事工程师自己已经点出来了，面谈就可以直接用来商量怎么办。
自评问题#
下面是我提前发出去的问题。它们故意问得很开放，这样回答告诉我的是一个人怎么看待自己的工作，而不只是做了哪些事：
- 上次评估以来，你最自豪的是什么？为什么是它？
- 你在哪里卡住过？什么能让你早点脱困？
- 队友或代码评审者给过你的哪条反馈，让你一直记着？
- 上次定的目标里，你觉得哪些达成了？哪些想放弃或调整？
- 接下来想学什么？现在的工作给了你这个机会吗？
- 作为你的经理，我哪些地方应该换个做法？
最后一个问题换来的尴尬沉默最多，换来的有用回答也最多。
具体的反馈是什么样子#
大多数糟糕的评估反馈并不刻薄，而是含糊。区别看下面，右边是我努力去写的那种：
| 含糊 | 具体 |
|---|---|
| “加强沟通。” | “支付系统迁移那次，延期是在Sprint评审会上才暴露出来的，而你两周前就发现了。下次一看到进度要滑，当天就在团队频道里说一声。” |
| “这个季度干得漂亮。” | “你写的那份缓存方案对比，让我们一次会就做了决定，不用开三次。凡是要花一天以上才能选定的事，都继续这样写。” |
| “要更有资深的样子。” | “到了下一个职级，我希望你能端到端地负责一个功能的设计。搜索改版的设计评审由你来主持，带两个方案和各自的取舍来。” |
| “代码质量有待提高。” | “你最近十个PR里有三个因为漏掉边界情况需要补修。提交评审前先把失败路径的测试补上，下个季度我们再看一次这个比例。” |
每一条具体的反馈都点出一件事，说明它带来了什么变化，再指向这个人接下来能做的事。这样写更费时间，所以我逼自己整个季度随手收集例子，而不是评估前一晚才拼命回想。
写下来#
面谈结束后，写一份纪要：讨论的要点、提出的问题、行动项、双方认可的目标。听着很官僚，但正是这份书面记录，能避免六个月后那句“我们当时没这么说吧”。写下来的问题会被持续跟进而不是蒸发，行动项直接成为下次评估的开场议程，落在纸面上的目标也会被认真对待。
说到底，整个体系就这么几条：第一天就把期望讲清楚，KPI贴着人来定，凡事留记录，每个行动项都跟进到底。缺少双向对话和可衡量结果的评估就是走过场，而工程师从收到日历邀请那一刻起，就能闻出走过场的味道。