本文来自微信公众号：薯仔在发呆，作者：HenryYang，头图来自：AI生成

绩效考核是公司管理的排名工具，并非个人能力唯一标尺。低绩效不意味失败，高绩效也非全部反映实力。面对考核应战略上藐视（降低预期），战术上重视：明确目标对齐业务、高频向上沟通、主动汇报进度、合理领功/求助，通过持续闭环赢得信任，破除对绩效的盲目追逐。

• 👁️‍🗨️ 战略藐视绩效： 绩效考核具有主观性与变动性，需降低对其结果的过度期待。

• 🎯 目标精准对齐： 个人目标必须直接承接业务核心指标，避免自嗨式优化。

• 👥 高频向上管理： 主动与决策层沟通，明确期望并及时同步进展是破局关键。

• 📢 持续主动汇报： 定期展示工作进度与思考，保持信息透明增强leader掌控感。

• 🙋 功过显性表达： 有贡献应适时展现，遇困难需及时求助，避免“闷头吃亏”。

• 🔁 建立信任闭环： 通过持续可靠的行为在每一件小事中累积信任，改变被动处境。

上周刚结束的鹅厂 2025H1 的绩效考核，脉脉上、各种群里既有秀涨幅秀 rsu 的，也有“半年白干”的；而这里面不仅有刚入行的年轻人，也有不少高 T。大家都沉浸在绩效考核、职级晋升这盘大棋中无法自拔。作为一个平平无奇的打工人，到底，应该如何看待绩效考核？它是否是评判一个人工作能力的唯一工具？拿了低绩效到底意味着什么？今天一起盘一盘。

先说结论：绩效考核只是一个管理工具，仅此而已。

各个公司都有自己的一套对员工的考核体系，虽结构不尽相同，但目的殊途同归，最后给员工排名，并以此为年终奖、rsu、答辩晋升等提供依据。

鹅厂也不例外，一年两次考核，年中一次（H1），年终一次（H2）；结果分五档，即 1-5 星，4、5 星是高绩效，3 星中规中矩，1-2 星是低绩效。

拿到高绩效意味着年终奖的系数更高、rsu 可能给更多、答辩晋升时更好看、以前还会更可能涨薪；但如果是低绩效则完全相反，年终奖几乎不用期望、答辩涨薪一定没戏、而很多人直接因为一次低绩效就离职了。所以每到考核季，无论公司内外的平台上，相关的讨论一定是最火热的。

一

2020 年初，在外摸爬滚打了几年之后终于投入了鹅厂的怀抱。虽然在以前的公司也经历过绩效考核，但入职之初的我对鹅厂的高绩效还是有种仰望的感觉。我甚至拿着公司对 1-5 星的要求一条条地琢磨，对应到自己岗位上应该要做出哪些成绩，而后对已经拿了高绩效的同事有一种发自内心的膜拜，心想他们一定是个人能力顶尖、对团队和组织做出了不可磨灭的贡献、在他们的 leader 面前做出了远超预期的输出。不可否认，在大部分团队中，能拿高绩效一定是有类似的表现的。

但由于我入职的时间正好的疫情开始的时候，还没上两天班，就在远程办公和 AB 班之间反复横跳。这对于新人来说无疑有极大的伤害，因为缺少与同事和leader 的线下沟通、熟悉的机会，导致融入团队的进度慢，花了大量的时间在了解项目、理解需求和约会上。

虽然 2020H1 的绩效最终是个 3 星，但现在回过头看看也确实只做了最基础的事情，最开始的半年几乎都处在熟悉了解的过程中。

工作慢慢熟悉上手之后，发现组织的架构其实比较模糊，所有的一线岗位都隶属于项目组长之下，所以在前端这块只能找资深的同事聊工作计划，目标是能定出来了，但在大方向上的理解始终不如直接和leader聊来得更清晰。

在 PCG 的两年多，组长甚少直接和大家聊绩效，而是安排了同为一线员工的“老同事”和其他人聊；和我聊的时候，我现在依稀记得提到在前端要向 xxx 看齐，但当时的我心中有些许不忿，我已经把需求都完成得不错了，为什么还要被人鸡蛋里面挑骨头。

二

后来因为业务原因+实在有点心累，兜兜转转去了 TME（腾讯音乐集团）的全民K歌。在 K 歌的蜜月期，由于有新的业务，借着这个东风拿了高绩效、升了职级也涨了薪，那段时间可谓是有些意气风发，觉得去 TME 算是进腾讯之后第二次有大改变的选择。

不过很快娃出生了，有娃之后个人的重心明显转移到了家庭，每天想的都是能否早点下班回家看娃。这个不自觉地改变带来最大的问题就是和 leader 严重缺乏交流，渐渐地在工作上被边缘化，加之新业务很快就挂了，在已有业务上已经很难再做出亮眼的优化，最终还是领了礼包离开了 TME，彻底离开了鹅厂——这个个人认为在国内氛围最好的平台。

三

其实在鹅厂的时候我也在思考应该如何破局？作为团队新人应该如何快速得到同事、leader 甚至是 +2 的信任？为什么自己的长时间加班却换不来一个 4 星？这里借用教员的话还挺合适：战略上藐视敌人，战术上重视敌人。

所谓战略上藐视敌人，其实是不要对绩效考核抱有过高的期望。你可能做了很多事，但 leader 有自己的一套考核标准，并且很有可能这套考核标准一直在变。也许前两个月 leader 会关注组员的具体表现，并根据其表现做详细的记录；但很可能到了考核前夕，一个小问题没处理好，直接摧毁掉之前的努力。毕竟越近的记忆对人的影响越大。

所以这套工具具体怎么用，leader 给组员排名的依据是什么，谁也不知道，可能连 leader 自己都不知道。

而所谓战术上重视，意思是向上管理。虽然很多人不屑于做，特别是做技术的，觉得技术能力做好了就能独步天下。但人始终是群居动物，工作在本质上还是沟通，要做好协作还得通过沟通理解他人的想法。

具体有以下方法可供参考：

1. 和 leader/重点角色沟通

这个角色必须是能决定你的绩效的人，你需要通过 TA 来了解组织中现在的具体目标是什么。在鹅厂经常会听高层们的讲话，他们讲话的内容很广泛、目标很宏大，对于一线员工很难通过这些高层的讲话精准地匹配到自己的工作内容。而对于能决定自己绩效的角色，一般来说都是组织架构上一层的人，而他们接收到的目标已经被他们的 leader 细化过了，所以最终落到自己身上的，一定是可以付诸实践的目标。

如果还有能力向上管理到 +2，那是更好不过的了。没错，和 +2 的关系如果能维护也是要维护的，但在 +2 面前不再是炫技的时候，而是展现个人大局观的机会。和 +2 聊就不用再着眼于动作了，而是要让 +2 看到你对业务的理解、对宏观目标的看法。所谓刷脸，这也是其中的一种方式。

2. 和 leader 确认目标

目标不是定完就完了，一定要和 leader 确认自己提出的目标是合理的、是能帮助到业务的短期目标的。

有一部分朋友对 OKR 的理解是从自身出发，基于自己对项目和团队的理解，结合组织的要求提出一系列的目标，然后去拆解关键结果。

但其实目标的提出应该是基于组织对项目和团队的要求，再结合自己的能力优势去提出目标。

这两句话看上去好像没什么区别，但如果理解不到位，很容易引发后续的动作变形。

假设组织的目标是要快速发展项目，希望项目能尽量地满足用户的需要，从而达到 DAU、MAU、营收等数据的大幅增长，那么就要围绕这个目标拆解自己的目标，例如完成多少需求、bug 率控制在 x% 以下、线上问题响应/解决时间控制在 xx 分钟内等等。

但有些朋友可能在熟悉了团队情况之后，发现了一些和业务无关的问题，例如代码复用程度不够、项目的组件化做得不够、开发自测流程不规范等，然后依据这些优化点强行套用到组织的目标上。

这些问题有优化的必要吗？当然是有的，但不是近期的目标，所有的优化都需要为业务目标让路。如果连组织的目标都没达成，项目的代码层面做得再完美、再规范也不过是花拳绣腿。

如果遇到靠谱的 leader，可能还会手把手地教如何正确地拆解目标，反之，leader 在看到你的 OKR 的一瞬间，心里就已经把下一次的低绩效 quota 预定了。

3. 定时汇报

有很多朋友一个考核周期中，填OKR的平台只打开两次，一次是填 OKR 的时候，一次是做总结的时候，中间的时间只是自顾自地干活，事情做到哪里了、和目标还有多少差距、当前进度是多少等问题完全不关心。可能哪天 leader 想起来了问你一下，如果一个考核周期 leader 忙到没时间确认进度，直到最后才发现你的进度有问题，那结果可能又是一个低绩效了。

所谓定时汇报，也就是主动反馈，这是 leader 们最喜欢见到的。因为这不仅能了解团队内的现状和细节，更能体现出主动性，主动性不是向上跪舔，而是客观地告诉 leader 现在的工作进行到哪一步了。否则 leader 自己心里也没底，你的 leader 不了解团队内的实时情况，TA 就无法向 TA 的 leader 汇报，如此往复，组织很快就会垮掉。所以你可以“不合群”，但请一定要主动。

4. 有功要领，有难要说

我既见过默默无闻地做贡献之后甚少甚至不领功的人，也见过遇到困难一头栽进困难中，不把南墙撞碎不吭声的人。特别是做技术的，只想两耳不闻窗外事，一心只想写代码。可惜这样不过是在告诉 leader，来呀，下次的低绩效给我吧。

工作中遇到困难是再正常不过的了，无论是技术问题，还是协作问题，亦或是资源问题，只要有问题，先想 leader 能不能帮自己。对于大部分 leader 来说，宁愿经常听到组员有困难需要帮助，也不愿组内长期安静如鸡。

5. 信任闭环

通过将上述步骤融入每一个需求中、每一件大事小情中、每一次线上问题中，无论是同事还是 leader，必定会对你另眼相看。每一件事情如果都能做到让 leader 对你增加一点信任感，一个考核周期下来你在 leader 心中的分量必定会有大幅度的增长。换个角度看，并不是 leader 在领导你，而是你带着 leader 完成了一个又一个小目标。

方法论实操起来并不困难，希望大家能切实地实践一波，即便团队内的绩效结果可能在考核周期开始的时候就确定了，可如果能将这套方法论实践一个考核周期，哪怕在现在的团队中没有结果，自身也能感受到极大的成长。

本文来自微信公众号：薯仔在发呆，作者：HenryYang（互联网从业者、全栈工程师、独立开发者、代码+产品体验强迫症患者、生活体验家、旅行爱好人士）