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

到底为什么要做绩效评估

#

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

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

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

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

#

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

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

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

#

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

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

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

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

#

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

之后我用的议程

#

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

KPI只有因人而设才有效

#

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

我关注的几个方面：

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

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

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

我填的模板

#

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

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

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

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

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

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

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

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

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

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

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

自评问题

#

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

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

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

具体的反馈是什么样子

#

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

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

写下来

#

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

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

开会本身很容易

#

结构简单得有点不好意思。冲刺或项目阶段结束后，团队坐下来回答三个问题：

1. 哪些做得好？
2. 哪些没做好？
3. 有什么可以改进？

就这些。关键在于反馈循环：定期停下来，看看实际发生了什么，再把结论装回工作方式里。从不停下来的团队，只会原地打转。

有用的回顾会和吐槽大会的区别

#

首先是坦率。只有确信说出来不会被记账，大家才会讲真正的问题，所以会场的安全感比选了哪种形式重要得多。而且最敏锐的观察往往来自不爱说话的同事——只有组长在讲的回顾会，不过是多了道工序的例会。

另一半在于讨论之后发生什么。值得修的问题，离开会议室时都应该变成有负责人、有截止日期的行动项。然后——多数团队跳过的就是这一步——下一次回顾会，从检查上次的行动项开始。没有什么比大家默默意识到行动项只是摆设，更能快速杀死回顾会。

可以的话，带点数据来。“这个冲刺感觉很慢”这类感想只会绕圈子，一张图表通常就能定案。

常见的翻车方式

#

我近距离见过三种：开成批斗会的（要修的是系统，不是人）；一年到头用同一套形式、所有人进入自动驾驶的（换换花样）；以及完全没有跟进的。如前所述，最后一种是致命伤。

顺带说一句，这不只是软件行业的事。市场活动、活动运营、研究项目、制造业——凡是有重复周期的工作，这套循环都适用。但不管在哪儿开，检验标准只有一个：到下次回顾会之前，有没有什么真的变了？没有的话，那就只是聊了个天。

这是简短版。下面是详细版，因为反馈谈崩的方式在我这儿几乎每次都一样，次数多到我都不太好意思承认：我刚指出一个问题，对方肩膀一紧，从那一刻起，我们俩谁都没在真正听对方说话。

人为什么会起防御心

#

防御不是固执，至少一开始很少是。人感到受威胁时就会这样，而反馈带来的威胁感，比我们通常以为的要大。表面上你在聊一个 PR，或者一个没赶上的截止日期。对方听到的却是：我到底能不能胜任这份工作？我在这个团队里还有没有位置？你是不是憋了好几个月，一直这么想？

人一旦有了这种感觉，注意力就全拿去保护自己了，顾不上你要说的重点。你越使劲争，越坐实了那份威胁。所以下面那些管用的做法，大部分都是先把气氛里的风险感降下来，然后才谈正事。

还有一点值得记住：有些人进这种谈话的时候，身上本来就带着伤。以前的上司只在批评时才开口，或者待过的地方犯一次错就会被边缘化。这些过去你没法在一次谈话里抹平，但它能解释为什么一句挺温和的话，有时会换来大得多的反应。

谈之前

#

大多数反馈谈话，在开始之前结果就已经定了。下面几件事，是我现在会做、以前不会做的。

我只挑一件事。如果我攒了五个问题一起说，对方听到的是一场审判，不是反馈。另外四个可以等等，而且到头来往往只是第一个问题的症状。

我尽快谈。六周前的事现在才拿出来说，对方心里想的是“那你怎么现在才告诉我？”。问得合理，而且我没什么好答的。事情过去一两天正合适：够新鲜，又不至于两个人都还在气头上。

我私下谈，而且能不用聊天工具就不用。文字会丢掉语气，一个本来就戒备的人读的时候，会用最坏的版本把缺掉的语气补上。如果因为团队远程或者有时差只能写，我就写短一点，再问对方要不要打个电话。

还有，我会先看看自己的状态。我要是心里有气，不管措辞多讲究，对方第一句话就能感觉出来。我给过的一些反馈，要是等自己不烦了再说，效果会好得多。

具体怎么说

#

我反复用回去的结构，通常叫“情境、行为、影响”（SBI）：什么时候发生的，对方做了什么，造成了什么结果。关键在于每一部分都是看得见的。里面没有一句在说这个人是什么样的人，只说发生了什么。

举个实际的例子。假设一位开发者周五下午没等代码审查就合并了一个改动，结果周末结账功能挂了。

让人立刻竖起防线的说法：“你总是急着上线。你得更仔细一点。”

还有机会谈下去的说法：“周五那个支付的改动没经过审查就合进去了，周六结账挂了好几个小时。我想弄清楚是怎么回事，因为我不觉得是你粗心。”

第二种只讲了一件事，直白地说出了代价，最后还默认对方是出于好意。杀伤力最大的就是“总是”和“从来不”这类词。它们把一次事故变成了对人品的判决，而对方会马上想到一个反例来证明你错了。

我也会尽量把观察说成是我自己的。“我注意到”“我有点担心”，老老实实表明这是我的看法，是从我这边说出来的，也给我留了看漏什么的余地。而我常常确实看漏了。

然后我就闭嘴，问一句：“从你那边看是什么情况？”通常会有我不知道的背景，比如死线是别人定的，或者负责审查的人正好请了病假。就算没有，这一问也在告诉对方：这是一场对话，不是一份判决。

反馈附上一条出路，也会好接受得多。不是一串问题清单，而是“下次我们能不能……”。要是这条出路是对方自己提出来的，就更好了。

对方还是反驳了怎么办

#

你可以每一步都做对，照样遇到抵触。抵触通常有几种认得出来的样子，每种都要稍微换个应对方式。

最常见的是否认：“事情不是这样的。”别争。回到两个人都看得见的东西上，比如那次提交、那条消息、那个日期，然后问问自己漏了什么。如果事实真有争议，说一句“我们都再看看，明天接着聊”完全没问题。

然后是转移话题：“需求一直在变啊”，或者“某某也这么干”。这里面常常有几分道理，所以别一口否定，先认下来：“这话没错，需求的问题我们也得解决。”再轻轻拉回来：“这个先放一边，我想聊聊审查这一步。”

反击，比如“你自己不也经常不走审查就合代码”，是最难忍住不回嘴的一种。先深呼吸。如果对方说得对，就承认，这是让气氛降温最快的办法，而且你正好示范了你希望对方拿出的那种开放态度。然后再回到原来的话题。

把自己关起来，不管是沉默，还是一句“行，你说了算”，看起来像同意，其实不是。我会轻轻点出来，比如“看起来这话你听着不太舒服，这没关系”，然后提出改天再接着聊。逼一个已经缩回去的人表态，你只会得到一个假的回应。

过度道歉（“我太差劲了，真的对不起”）也是一种防御，只不过矛头朝向了自己。对方抢先把批评说出口，以此保护自己。告诉对方这只是一件具体的事，不是对他整体表现的评价，然后把话题转到接下来怎么做。

不管遇到哪一种，我都尽量守住一条：别跟着对方的情绪走。对方一防御，我的本能也是马上防御回去，而这一招保证能把谈话搞砸。只要我稳得住，气氛通常会自己降下来。把感受直接说出来也有用，比如“我知道这话听着挺憋屈的”，总比假装屋里没有火药味强。

知道什么时候该停

#

有时候这些都不管用，墙就是不倒。这时候再使劲毫无意义。把话题先放一放，过一两天等情绪落定再谈就行。反馈说的事到明天也还成立，而且人睡过一晚之后，往往冷静得多，也更愿意反思。我经历过的几次最好的后续谈话，都是对方先开口：“你上次说的，我想了想。”

这一条，我学得最慢。

谈完之后

#

接下来一周发生的事，和谈话本身一样重要。如果对方改了，就说你注意到了，要明明白白地说，而且要尽快说。这样对方才知道，从你这儿来的反馈不全是坏消息，下一次谈话也会容易些。

合适的时候，也可以问问对方，这次反馈听着怎么样。一句“我这么说公平吗？”能让对话更对等，也把你希望对方拿出的开放态度先做给对方看。我转去做管理之后，开始习惯性地这么问，有那么几次，正是这一问让我发现：我脑子里想得清清楚楚，说出口却没讲明白。

简单来说

#

先把威胁感降下来，再谈问题。一次只挑一件事，私下谈、尽快谈，讲行为和影响，不评价人，提出解决办法之前先听听对方的说法。对方反驳时，别跟着加码。承认情绪，回到事实，也愿意先停下、改天再谈。之后记得跟进，因为信任恰恰是在那场谈话之后的谈话里建立起来的。