身在职场，KPI 是程序员绕不开的话题，自从互联网公司采用 361 的绩效方案以来，每年的年终绩效总归会引起一些争议。
为什么明明干的一样的活，别人的绩效比我好？为什么年初在制定 KPI 的时候，明显更容易拿到好绩效的工作轮不到我？这篇文章，我就从一个技术管理者的角度，通过几个案例，说说什么样的程序员更容易拿到好绩效。
给答案而不是提出问题
“业务开发团队经常反馈微服务监控告警太多，建议我们看一下能不能优化一下告警指标和策略。”
以上是我们中间件团队接到的一个需求，于是我就让团队的小伙伴去调研一下，给一个初步的方案。在不断催促下，2 周之后终于拿到了一个初步的改造方案。洋洋洒洒 2 千字的文档，从当前告警问题、到统计数据、再到 10 几个建议，需要投入人力超过 1 个月，连使用 AI 模型做告警识别都加上了。
你觉得这位同学做的怎么样？貌似看起来很认真，是位靠谱的同学。但是当我拿到这个文档的时候，就问了一个问题：你这 10 几个建议中，我采用哪几个可以解决现在 50% 的问题？令人失望的是，这位同学完全答不上来。
在我看来这位同学犯了很多技术同学常犯的错误，过于关注做事的过程，而忽略了结果。
给方案时需要给选择，而不是提出问题。哪怕你的方案完成不完美，评估也许不准确，但至少应该给出，我的第几个点解决什么问题，可以解决多大比例的问题。
方案中包含了超过30个工作日的开发工作量，显然这么大的投入，至少应该同时给出相应的收益指标，比如投入后可以解决多少问题，占比多少。
当一个任务的工作量超过 3 天时，说明这个任务需要在中间就做一次汇报，把你的思路跟 leader 简单沟通，而不是用超过 2 周时间攒一个大的。
我们常说的一个人“靠谱”，其实是指能从他那里拿到确定性的结果。这个结果不一定是把事情做成，也可以是给我一个不能做的原因。
当感觉自己做的事情跟别人差不多，但绩效差很多的时候，可以考虑一下上面的案例。如果是你面对这个需求，是不是可以做的更好。如果每次在给方案时，都能给答案而不是给问题，我相信你的绩效不会差。
多汇报永远不会错
「向上管理」这个词相信大家都听过，这里我想说的是，向上管理没有大家想的那么复杂，更不要把它跟「拍马屁」、「舔领导」这种词混为一谈。有时候能做到多汇报，向上管理可能就已经做到了一半以上了。
为什么要多汇报
很多人自认为我在干的事领导都知道，为什么还要汇报。但大部分情况是，你的 leader 他是真的不知道。
他或许知道这周你在干嘛，但是你做的事能不能按期完成、有没有卡点、需求方有没有变动，就一无所知了。等你当上 leader，就会知道有一个喜欢汇报的下属是多么美好的一件事情，哪怕他说的事情你都知道也没有关系。
如果你觉得你们团队人做的事情都差不多，大家都没什么亮点，那就多多汇报吧，反正也没什么损失不是吗？
抓住汇报的要点
相信很多人都在写周报和日报，但说实话内容能到 60 分的都很少。下面来举个例子，看看这些内容有没有出现在你的周报里面：
本周开发 xxx 功能，完成 30%
和 xxx 业务方讨论 xxx 需求
xxx 功能已上线
貌似没有什么大问题，这就是程序员朋友们的日常啊。但是仔细想想，你的 leader 能从这里面得到的信息其实不到 60 分。
完成 30% 到底是代码写了 30%，还是 10 个小功能完成 3 个？需求讨论的结论是什么，有没有疑问，业务方为什么提这个需求？功能做完了结果是什么，需求方用了吗，有什么反馈？这些要点统统没有。
那什么样的汇报算是抓住要点呢？其实只要抓住一点：你的 leader 是不是可以把你写的内容直接给他的老板。如果从这个角度检查你汇报的内容，像完成 30% 这样的条目应该就不会出现在你的汇报里面了。
不要只做份内的事
心理学领域有一个理论叫"中等以上幻觉"，指的是人们倾向于高估自己的能力和水平，即使实际上可能低于平均水平，他们仍认为自己处于中等偏上的位置。这种现象很普遍，比如人们在评价自己的智力、外貌等等，同样在自我评估绩效时也一样。
这么说的目的不是为了让大家妄自菲薄，如果想要评估自己的绩效是否在团队的前 30%，其实有一个标准可以参考一下：当你的上级岗位空缺，公司要从内部提拔一个人的时候，你会不会在名单上。
如果你觉得自己不在名单上，又想要努力进入前 30% 的话，可以考虑从下面几个方向努力。
想尽一切办法，多接触业务
在平常工作中，经常听到技术小伙伴这样的答复：
这个需求上就是这么写的，有问题去找产品；
让产品去问问需求方，这个需求提的有问题；
这个问题的原因是xxx，产品你去跟业务方说一下；
这个问题是前端的，你去问一下前端，我不知道他什么时候解决；
等等 ...
每当听到这类答复，其实我挺为这类同学惋惜的，因为他放弃了一次和业务方接触的机会。很多公司的价值观里都有一条「不要给自己设限」，如果甘愿缩在后面当无名英雄，结果往往是好绩效也轮不到你。
公司职位的分工只是为了效率最大化，不要怕你抢了产品和运营的事情，没有人在乎这件事应不应该你来做。在评绩效的时候，业务方一句话的影响等于你自己汇报时说 10 句，千万不要让到手的机会溜走。
争取跨级汇报的机会
当你没有什么亮点项目可以汇报，中后台部门跟业务接触的机会也很少，是不是绩效就只能看领导脸色了呢？其实也不是。程序员想办法提升自己的影响力，也是拿到好绩效的办法。这里的提升影响力，包括争取到跨级汇报的机会、或者是对内的技术分享。
这里要注意的是做的事情要跟业务相关。举个例子，在 AI 大模型出来之后，我们会发现一个现象，越是高管对这项技术的关注越高，原因是 AI 是实实在在可以降本增效的。而对于程序员来说，如果你能尽快的学习到大模型应用开发的相关技术，在公司内部做个技术分享，就会在领导心理留下一个先入为主的印象，对程序员的绩效绝对会有很大帮助。
总结
这个世界上没有什么绝对公平，评绩效也一样。大部分时候我们只需要稍微改变一下自己做事的方法，就可能有不一样的回报。
推荐一个程序员的生存指南：前大厂P9右军带领多名大厂技术专家出品，从案例出发，提供实用技巧和最佳实践，推荐加V：jianghu10002，加入联盟
