这是最近两天的一个感悟，得出来后，马不停蹄地开始了这篇文章的撰写，希望能快一点和大家分享。

这篇文章的灵感来自于哪呢？

来自于最近公司一年一度举办的任职资格晋级评审。

这次的任职资格评审，我部门里有一个小伙子参加，他不直接归我管理，我属于他的跨级领导。

在部门里表现的也是非常不错，绩效很高，也拿了不少奖。但是这一次答辩完之后，就有些闷闷不乐。

他的上级在识别到状态有些问题后，单独和他做了沟通，但还是不太开心，于是便让我和他再聊聊。

下面就展开和大家分享下，具体发生了什么，以及我的具体感悟吧。

我在知道情况后，就尽快和他做了一次沟通。

（这是一个管理和带人的小技巧：「及时反馈」，拖太久可能都忘记细节了。）

所以，我找了个会议室，我就开始问他：“怎么啦，这次答辩有出什么问题吗？”

他说：“答辩完，我自己不是很满意。评委问了一些问题，我发现我没太多举证材料。”

我问：“为什么会没有呢？是准备不充分吗？”

他说：“倒也不是，主要是现在我们的开发模式都是敏捷，几周出一个小版本，都不需要做详细的设计，但是评审里又要这些东西，我拿不出来。”

我答：“确实有这个状况。”

他说：“我比较纳闷的是，我感觉自己很努力，对自己要求也很高，像编码质量、设计这些。在团队里也取得了不错的绩效。”

他继续说：“但到了任职评审的时候，我在准备材料的时候就感觉很吃力，发现哪哪都没做好，都是一些比较零碎的内容，没东西可以写。”

大概陆续聊了一会，我已经比较清楚他的情况，以及为什么会有些消沉，我就开始说道：

“你现在职级还比较低，这些还好。但如果到了下一个职级的晋升，你讲的这些问题就会成为障碍了。”

他立刻问道：“那要怎么解决？”

我说：“也简单也不简单，首先版本开发的工作还是会有，那接下来就是要去承接一些版本外的工作了，例如一些专项的改造。随着产品的不断开发，过程中会产生很多的技术债务，像卡慢、代码耦合过重、架构老旧等等，要能站在技术角度识别到痛点，并且对业务是有帮助的，找到它并解决它。”

我继续说：“比如整个产品的性能卡慢，你作为一个专项去设计和改造它，花上几个月的时间从预研、设计、编码都负责起来，那你的答辩材料还会空洞么？”

他说：“应该不会了。”

后面我们又探讨了很多和发展相关的问题。。。。

总结一下这个案例吧：

员工的情况：

1. 高绩效、自驱力强、有高追求；
2. 晋级答辩时，觉得没东西写，做的内容太零散。

怎么解决？

1. 开发过程中，从技术角度找到痛点，能够把痛点形成专项，并能很好地解决它。

那延展开来讲，就到我想分享的一些感悟了。过程中我在反思也和员工有了额外的一些探讨。

为什么公司里或者是部门里，有很多高绩效的员工，但是职级、岗位的发展并不快？

这次的交流完后，我有了一个初步的答案：

1. 高绩效≠高发展
2. 高发展，建立在中高绩效

什么意思？解释一下：

1. 绩效是你在这段考核期间内，在你所在的团队里的评选结果。你比别人做的好，那就是A，差不多那就是B，做的差那就C。
2. 但取得A绩效了，就代表你是当前职级里能力最强的，要往下一个职级晋升了么？肯定不是。
3. 晋升是有明确规则的，比如：要做过大模块的设计、关键技术的障碍扫清之类。

打个比方：

你在小学三年级里考试能拿全班第一，但不代表这用四年级的题目考你，你就能及格。

那晋升的逻辑也是类似，你所工作的内容和晋升的标准没太大关系，自然就写不出东西来。

很多人在这个点上就卡住了，那公司给我安排的活就是这样的啊，都是零碎事情，那我岂不是永远都晋升不了了？

别急，在我的文章里，一般除了抛出问题，我还会给出一些过来人的建议。

那这道题怎么解？

我的答案是，做好手里的，发现痛点，包装成大的事情，说服他，承接它并解决它，并形成循环。

我逐个解读一下：

第一步，做好手里的

任何人，刚参加工作或者是换了一个岗位，切忌眼高手低。

还是得先深入到业务，参与到实际工作中去，这样基础的绩效才有保障。

很多人只做好了第一步，做到了极致，所以拿了高绩效。

但是也只做完了这一步，所以发展并不快。

第二步，发现痛点

这一步的要求就比较高了，我发现很多做开发的同事，整活的想法会比较少，大部分都是在围绕「第一步」。

那发现痛点，具体是要发现什么呢？

举几个例子：

1. 你发现随着数据量上去了，查询性能越来越慢，并且接下来的需求还要持续增加字段，那业务肯定会出问题；
2. 你发现自家代码还有别的部门也在做业务开发，经常出现了双方相互影响，经常出现bug；
3. 你发现每次上线，都要耗费大量时间，而耗费时间的主要原因是在上传新的代码到服务器。。。

相信不少人在实际工作中，也是能发现一些障碍的，也都能说的上来。

但是说完之后，就过去了，自己还是负责自己的工作往下推进。

第三步，包装成大的事情

这一步就非常重要了，怎么把痛点能系统性思考，并体系化规范化去设计、包装、解决。

以上面查询性能慢举例：

有的人就会简单做个索引，做一个缓存表，凑合着先用了。

也有的人会把整个业务的所有表格做一遍梳理，并结合产品经理未来一段时间的需求，去总体做设计，做一个能维持1-2年业务开展的方案。

换一个大家更好理解的例子「去工地搬砖，搬不过来」

有的人会加班，减少自己的休息时间，每天多搬一个小时，那就能搬完了；

也有的人会思考，是不是把搬砖的工序做调整，一个人负责把砖放到指定地点，一个人负责把砖搬上车，这样去提升整体效率，做成一个流程、一个方案。

这两个例子，我想说的是什么？

同样是看到了一个问题，有的解决方法是「头痛医头，脚痛医脚」，太零散也不成体系。

有的是能体系思考，形成大的方案，能把问题解决的更好更彻底，还有预防或者是提升团队整体效能。

两者的区别是巨大的。

如果是按方式一做，那确实是会卡住没法晋升，因为你就是在拧螺丝；

如果是按方式二做，那就很容易打开自己的上限。

第四步，说服他

假设你按上面的步骤做了，也做好本职工作，也发现了痛点，也包装成了大的价值点了，但是还是不够。

还缺了一环。哪一环？

你还要让你的上级领导，同意你这样干。

每个领导的风格是不同的，包括观念也是不同的。

打个比方，你们现在最赶的是业务发布，要赶紧去抢占市场，尽早推出产品，让市场同事能去卖。

这个时候，你不想干版本开发，你想去做技术债，那怎么可能？

所以，你认为是对的事情，要尽量让你的上级认可，如果你的上级拿不定主意，那要争取获得跨级的支持。

（注意，找跨级的前提是，你的上级没法拍板，而不是你的上级不认可，如果上级不认可的情况下，最好是不要随便越级汇报。）

你必须要获得支持。那怎么获得，就取决于你所发现的痛点与你的解决方案是否能打动他们了。

第五步，承接它并解决它

提出问题简单，问题最终还是要被解决。

既然前面已经做了那么多的铺垫了，这个时候，你就要把这件事情给揽下，并且要能做成。

有人还是会有顾虑：“那我去做专项改造了，不像日常版本开发，产出没那么明显，怎么办？“

答案其实很简单，你要以尽量不伤害领导业务为代价去达成目标。

什么意思？

举个例子，上半年我识别到一个很关键的技术债，而产品经理那边更关注发布业务，他们并不太想我去做。

但这件事情对日后开发的节奏会很有帮助，很多功能可以复用其他产品线的，开发能效会大幅提升。

我给产品经理提的是，这一两个月会少一个人力，不会占用特别多，你的业务需求我会想办法帮你解决，尽量不影响发布。

对你的干系人不会造成太大利益上的伤害，那自然他们就没太多意见了。

那回到个人身上怎么做？

以性能改造举个例子，那你可以这样和你的领导讲：最近的业务开发我想少投入一点，把时间放在性能改造上，业务版本大概按0.8来投入，你看是不是可以？我预计三到四个月，我就能把这个改造好，对整体的改善会很大。

自然，你肯定是需要额外多花一些时间去处理这些难题。

如果你既能把业务开发做的还算不错，还能把专项也做好了，那对你的发展（在公司里、个人能力、思维）都是很大的帮助。

第六步，形成循环

当你按这个步骤走了一遍之后，就会发现，其实没那么难。

完成基本工作，做好基本工作，发现痛点，提炼包装成大的项目，承接和解决它，自然就是晋升了。

而且这个过程和普通的工作有什么区别呢？区别是很大的。

仍以搬砖举例：

如果你是用加班加点的方式，你会发现短时间你的产出是上去了，你能加班一个月，但你能加班一年么？不加班后，是不是就产出下降了？而且，用这种方式，你的技能是不会得到提升的。

如果你是用设计流程、改变流程、改良工具的方式，你就会发现，前期好像确实更忙，不仅要搬砖，还要花额外的时间去思考和设计。但是，做成之后呢？你就不用再加班加点了，并且你的综合能力也有了提升。

希望对看到这里的你有所启发，感谢收看。