【干货】工作盲区:高绩效≠高发展,快速发展的技巧

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

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

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

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

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

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

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

(这是一个管理和带人的小技巧:「及时反馈」,拖太久可能都忘记细节了。)

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

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

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

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

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

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

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

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

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

他立刻问道:“那要怎么解决?”

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

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

他说:“应该不会了。”

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

总结一下这个案例吧:

员工的情况:

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

怎么解决?

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

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

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

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

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

什么意思?解释一下:

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

打个比方:

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

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

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

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

那这道题怎么解?

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

我逐个解读一下:

第一步,做好手里的

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

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

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

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

第二步,发现痛点

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

那发现痛点,具体是要发现什么呢?

举几个例子:

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

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

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

第三步,包装成大的事情

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

以上面查询性能慢举例:

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

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

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

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

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

这两个例子,我想说的是什么?

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

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

两者的区别是巨大的。

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

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

第四步,说服他

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

还缺了一环。哪一环?

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

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

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

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

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

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

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

第五步,承接它并解决它

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

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

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

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

什么意思?

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

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

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

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

那回到个人身上怎么做?

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

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

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

第六步,形成循环

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

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

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

仍以搬砖举例:

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

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

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

作者:鹏鹏的工作日记
公众号:鹏鹏的工作日记

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部