【干货】工作盲区：高绩效≠高发展，快速发展的技巧
这篇文章的灵感来自于哪呢？
来自于最近公司一年一度举办的任职资格晋级评审。
这次的任职资格评审，我部门里有一个小伙子参加，他不直接归我管理，我属于他的跨级领导。
在部门里表现的也是非常不错，绩效很高，也拿了不少奖。但是这一次答辩完之后，就有些闷闷不乐。
他的上级在识别到状态有些问题后，单独和他做了沟通，但还是不太开心，于是便让我和他再聊聊。
下面就展开和大家分享下，具体发生了什么，以及我的具体感悟吧。
我在知道情况后，就尽快和他做了一次沟通。
（这是一个管理和带人的小技巧：「及时反馈」，拖太久可能都忘记细节了。）
所以，我找了个会议室，我就开始问他：“怎么啦，这次答辩有出什么问题吗？”
他说：“答辩完，我自己不是很满意。评委问了一些问题，我发现我没太多举证材料。”
我问：“为什么会没有呢？是准备不充分吗？”
他说：“倒也不是，主要是现在我们的开发模式都是敏捷，几周出一个小版本，都不需要做详细的设计，但是评审里又要这些东西，我拿不出来。”
我答：“确实有这个状况。”
他说：“我比较纳闷的是，我感觉自己很努力，对自己要求也很高，像编码质量、设计这些。在团队里也取得了不错的绩效。”
他继续说：“但到了任职评审的时候，我在准备材料的时候就感觉很吃力，发现哪哪都没做好，都是一些比较零碎的内容，没东西可以写。”
大概陆续聊了一会，我已经比较清楚他的情况，以及为什么会有些消沉，我就开始说道：
“你现在职级还比较低，这些还好。但如果到了下一个职级的晋升，你讲的这些问题就会成为障碍了。”
他立刻问道：“那要怎么解决？”
我说：“也简单也不简单，首先版本开发的工作还是会有，那接下来就是要去承接一些版本外的工作了，例如一些专项的改造。随着产品的不断开发，过程中会产生很多的技术债务，像卡慢、代码耦合过重、架构老旧等等，要能站在技术角度识别到痛点，并且对业务是有帮助的，找到它并解决它。”
我继续说：“比如整个产品的性能卡慢，你作为一个专项去设计和改造它，花上几个月的时间从预研、设计、编码都负责起来，那你的答辩材料还会空洞么？”
他说：“应该不会了。”
后面我们又探讨了很多和发展相关的问题。。。。
总结一下这个案例吧：
员工的情况：
- 高绩效、自驱力强、有高追求；
- 晋级答辩时，觉得没东西写，做的内容太零散。
怎么解决？
- 开发过程中，从技术角度找到痛点，能够把痛点形成专项，并能很好地解决它。
那延展开来讲，就到我想分享的一些感悟了。过程中我在反思也和员工有了额外的一些探讨。
为什么公司里或者是部门里，有很多高绩效的员工，但是职级、岗位的发展并不快？
这次的交流完后，我有了一个初步的答案：
- 高绩效≠高发展
- 高发展，建立在中高绩效
什么意思？解释一下：
- 绩效是你在这段考核期间内，在你所在的团队里的评选结果。你比别人做的好，那就是A，差不多那就是B，做的差那就C。
- 但取得A绩效了，就代表你是当前职级里能力最强的，要往下一个职级晋升了么？肯定不是。
- 晋升是有明确规则的，比如：要做过大模块的设计、关键技术的障碍扫清之类。
打个比方：
你在小学三年级里考试能拿全班第一，但不代表这用四年级的题目考你，你就能及格。
那晋升的逻辑也是类似，你所工作的内容和晋升的标准没太大关系，自然就写不出东西来。
很多人在这个点上就卡住了，那公司给我安排的活就是这样的啊，都是零碎事情，那我岂不是永远都晋升不了了？
别急，在我的文章里，一般除了抛出问题，我还会给出一些过来人的建议。
那这道题怎么解？
我的答案是，做好手里的，发现痛点，包装成大的事情，说服他，承接它并解决它，并形成循环。
我逐个解读一下：
第一步，做好手里的
任何人，刚参加工作或者是换了一个岗位，切忌眼高手低。
还是得先深入到业务，参与到实际工作中去，这样基础的绩效才有保障。
很多人只做好了第一步，做到了极致，所以拿了高绩效。
但是也只做完了这一步，所以发展并不快。
第二步，发现痛点
这一步的要求就比较高了，我发现很多做开发的同事，整活的想法会比较少，大部分都是在围绕「第一步」。
那发现痛点，具体是要发现什么呢？
举几个例子：
- 你发现随着数据量上去了，查询性能越来越慢，并且接下来的需求还要持续增加字段，那业务肯定会出问题；
- 你发现自家代码还有别的部门也在做业务开发，经常出现了双方相互影响，经常出现bug；
- 你发现每次上线，都要耗费大量时间，而耗费时间的主要原因是在上传新的代码到服务器。。。
相信不少人在实际工作中，也是能发现一些障碍的，也都能说的上来。
但是说完之后，就过去了，自己还是负责自己的工作往下推进。
第三步，包装成大的事情
这一步就非常重要了，怎么把痛点能系统性思考，并体系化规范化去设计、包装、解决。
以上面查询性能慢举例：
有的人就会简单做个索引，做一个缓存表，凑合着先用了。
也有的人会把整个业务的所有表格做一遍梳理，并结合产品经理未来一段时间的需求，去总体做设计，做一个能维持1-2年业务开展的方案。
换一个大家更好理解的例子「去工地搬砖，搬不过来」
有的人会加班，减少自己的休息时间，每天多搬一个小时，那就能搬完了；
也有的人会思考，是不是把搬砖的工序做调整，一个人负责把砖放到指定地点，一个人负责把砖搬上车，这样去提升整体效率，做成一个流程、一个方案。
这两个例子，我想说的是什么？
同样是看到了一个问题，有的解决方法是「头痛医头，脚痛医脚」，太零散也不成体系。
有的是能体系思考，形成大的方案，能把问题解决的更好更彻底，还有预防或者是提升团队整体效能。
两者的区别是巨大的。
如果是按方式一做，那确实是会卡住没法晋升，因为你就是在拧螺丝；
如果是按方式二做，那就很容易打开自己的上限。
第四步，说服他
假设你按上面的步骤做了，也做好本职工作，也发现了痛点，也包装成了大的价值点了，但是还是不够。
还缺了一环。哪一环？
你还要让你的上级领导，同意你这样干。
每个领导的风格是不同的，包括观念也是不同的。
打个比方，你们现在最赶的是业务发布，要赶紧去抢占市场，尽早推出产品，让市场同事能去卖。
这个时候，你不想干版本开发，你想去做技术债，那怎么可能？
所以，你认为是对的事情，要尽量让你的上级认可，如果你的上级拿不定主意，那要争取获得跨级的支持。
（注意，找跨级的前提是，你的上级没法拍板，而不是你的上级不认可，如果上级不认可的情况下，最好是不要随便越级汇报。）
你必须要获得支持。那怎么获得，就取决于你所发现的痛点与你的解决方案是否能打动他们了。
第五步，承接它并解决它
提出问题简单，问题最终还是要被解决。
既然前面已经做了那么多的铺垫了，这个时候，你就要把这件事情给揽下，并且要能做成。
有人还是会有顾虑：“那我去做专项改造了，不像日常版本开发，产出没那么明显，怎么办？“
答案其实很简单，你要以尽量不伤害领导业务为代价去达成目标。
什么意思？
举个例子，上半年我识别到一个很关键的技术债，而产品经理那边更关注发布业务，他们并不太想我去做。
但这件事情对日后开发的节奏会很有帮助，很多功能可以复用其他产品线的，开发能效会大幅提升。
我给产品经理提的是，这一两个月会少一个人力，不会占用特别多，你的业务需求我会想办法帮你解决，尽量不影响发布。
对你的干系人不会造成太大利益上的伤害，那自然他们就没太多意见了。
那回到个人身上怎么做？
以性能改造举个例子，那你可以这样和你的领导讲：最近的业务开发我想少投入一点，把时间放在性能改造上，业务版本大概按0.8来投入，你看是不是可以？我预计三到四个月，我就能把这个改造好，对整体的改善会很大。
自然，你肯定是需要额外多花一些时间去处理这些难题。
如果你既能把业务开发做的还算不错，还能把专项也做好了，那对你的发展（在公司里、个人能力、思维）都是很大的帮助。
第六步，形成循环
当你按这个步骤走了一遍之后，就会发现，其实没那么难。
完成基本工作，做好基本工作，发现痛点，提炼包装成大的项目，承接和解决它，自然就是晋升了。
而且这个过程和普通的工作有什么区别呢？区别是很大的。
仍以搬砖举例：
如果你是用加班加点的方式，你会发现短时间你的产出是上去了，你能加班一个月，但你能加班一年么？不加班后，是不是就产出下降了？而且，用这种方式，你的技能是不会得到提升的。
如果你是用设计流程、改变流程、改良工具的方式，你就会发现，前期好像确实更忙，不仅要搬砖，还要花额外的时间去思考和设计。但是，做成之后呢？你就不用再加班加点了，并且你的综合能力也有了提升。
希望对看到这里的你有所启发，感谢收看。
作者：鹏鹏的工作日记公众号：鹏鹏的工作日记
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
