這是最近兩天的一個感悟，得出來后，馬不停蹄地開始了這篇文章的撰寫，希望能快一點和大家分享。

這篇文章的靈感來自于哪呢？

來自于最近公司一年一度舉辦的任職資格晉級評審。

這次的任職資格評審，我部門里有一個小伙子參加，他不直接歸我管理，我屬于他的跨級領導。

在部門里表現的也是非常不錯，績效很高，也拿了不少獎。但是這一次答辯完之后，就有些悶悶不樂。

他的上級在識別到狀態有些問題后，單獨和他做了溝通，但還是不太開心，于是便讓我和他再聊聊。

下面就展開和大家分享下，具體發生了什么，以及我的具體感悟吧。

我在知道情況后，就盡快和他做了一次溝通。

（這是一個管理和帶人的小技巧：「及時反饋」，拖太久可能都忘記細節了。）

所以，我找了個會議室，我就開始問他：“怎么啦，這次答辯有出什么問題嗎？”

他說：“答辯完，我自己不是很滿意。評委問了一些問題，我發現我沒太多舉證材料。”

我問：“為什么會沒有呢？是準備不充分嗎？”

他說：“倒也不是，主要是現在我們的開發模式都是敏捷，幾周出一個小版本，都不需要做詳細的設計，但是評審里又要這些東西，我拿不出來。”

我答：“確實有這個狀況。”

他說：“我比較納悶的是，我感覺自己很努力，對自己要求也很高，像編碼質量、設計這些。在團隊里也取得了不錯的績效?！?/p>

他繼續說：“但到了任職評審的時候，我在準備材料的時候就感覺很吃力，發現哪哪都沒做好，都是一些比較零碎的內容，沒東西可以寫?！?/p>

大概陸續聊了一會，我已經比較清楚他的情況，以及為什么會有些消沉，我就開始說道：

“你現在職級還比較低，這些還好。但如果到了下一個職級的晉升，你講的這些問題就會成為障礙了?！?/p>

他立刻問道：“那要怎么解決？”

我說：“也簡單也不簡單，首先版本開發的工作還是會有，那接下來就是要去承接一些版本外的工作了，例如一些專項的改造。隨著產品的不斷開發，過程中會產生很多的技術債務，像卡慢、代碼耦合過重、架構老舊等等，要能站在技術角度識別到痛點，并且對業務是有幫助的，找到它并解決它。”

我繼續說：“比如整個產品的性能卡慢，你作為一個專項去設計和改造它，花上幾個月的時間從預研、設計、編碼都負責起來，那你的答辯材料還會空洞么？”

他說：“應該不會了?！?/p>

后面我們又探討了很多和發展相關的問題。。。。

總結一下這個案例吧：

員工的情況：

1. 高績效、自驅力強、有高追求；
2. 晉級答辯時，覺得沒東西寫，做的內容太零散。

怎么解決？

1. 開發過程中，從技術角度找到痛點，能夠把痛點形成專項，并能很好地解決它。

那延展開來講，就到我想分享的一些感悟了。過程中我在反思也和員工有了額外的一些探討。

為什么公司里或者是部門里，有很多高績效的員工，但是職級、崗位的發展并不快？

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

1. 高績效≠高發展
2. 高發展，建立在中高績效

什么意思？解釋一下：

1. 績效是你在這段考核期間內，在你所在的團隊里的評選結果。你比別人做的好，那就是A，差不多那就是B，做的差那就C。
2. 但取得A績效了，就代表你是當前職級里能力最強的，要往下一個職級晉升了么？肯定不是。
3. 晉升是有明確規則的，比如：要做過大模塊的設計、關鍵技術的障礙掃清之類。

打個比方：

你在小學三年級里考試能拿全班第一，但不代表這用四年級的題目考你，你就能及格。

那晉升的邏輯也是類似，你所工作的內容和晉升的標準沒太大關系，自然就寫不出東西來。

很多人在這個點上就卡住了，那公司給我安排的活就是這樣的啊，都是零碎事情，那我豈不是永遠都晉升不了了？

別急，在我的文章里，一般除了拋出問題，我還會給出一些過來人的建議。

那這道題怎么解？

我的答案是，做好手里的，發現痛點，包裝成大的事情，說服他，承接它并解決它，并形成循環。

我逐個解讀一下：

第一步，做好手里的

任何人，剛參加工作或者是換了一個崗位，切忌眼高手低。

還是得先深入到業務，參與到實際工作中去，這樣基礎的績效才有保障。

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

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

第二步，發現痛點

這一步的要求就比較高了，我發現很多做開發的同事，整活的想法會比較少，大部分都是在圍繞「第一步」。

那發現痛點，具體是要發現什么呢？

舉幾個例子：

1. 你發現隨著數據量上去了，查詢性能越來越慢，并且接下來的需求還要持續增加字段，那業務肯定會出問題；
2. 你發現自家代碼還有別的部門也在做業務開發，經常出現了雙方相互影響，經常出現bug；
3. 你發現每次上線，都要耗費大量時間，而耗費時間的主要原因是在上傳新的代碼到服務器。。。

相信不少人在實際工作中，也是能發現一些障礙的，也都能說的上來。

但是說完之后，就過去了，自己還是負責自己的工作往下推進。

第三步，包裝成大的事情

這一步就非常重要了，怎么把痛點能系統性思考，并體系化規范化去設計、包裝、解決。

以上面查詢性能慢舉例：

有的人就會簡單做個索引，做一個緩存表，湊合著先用了。

也有的人會把整個業務的所有表格做一遍梳理，并結合產品經理未來一段時間的需求，去總體做設計，做一個能維持1-2年業務開展的方案。

換一個大家更好理解的例子「去工地搬磚，搬不過來」

有的人會加班，減少自己的休息時間，每天多搬一個小時，那就能搬完了；

也有的人會思考，是不是把搬磚的工序做調整，一個人負責把磚放到指定地點，一個人負責把磚搬上車，這樣去提升整體效率，做成一個流程、一個方案。

這兩個例子，我想說的是什么？

同樣是看到了一個問題，有的解決方法是「頭痛醫頭，腳痛醫腳」，太零散也不成體系。

有的是能體系思考，形成大的方案，能把問題解決的更好更徹底，還有預防或者是提升團隊整體效能。

兩者的區別是巨大的。

如果是按方式一做，那確實是會卡住沒法晉升，因為你就是在擰螺絲；

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

第四步，說服他

假設你按上面的步驟做了，也做好本職工作，也發現了痛點，也包裝成了大的價值點了，但是還是不夠。

還缺了一環。哪一環？

你還要讓你的上級領導，同意你這樣干。

每個領導的風格是不同的，包括觀念也是不同的。

打個比方，你們現在最趕的是業務發布，要趕緊去搶占市場，盡早推出產品，讓市場同事能去賣。

這個時候，你不想干版本開發，你想去做技術債，那怎么可能？

所以，你認為是對的事情，要盡量讓你的上級認可，如果你的上級拿不定主意，那要爭取獲得跨級的支持。

（注意，找跨級的前提是，你的上級沒法拍板，而不是你的上級不認可，如果上級不認可的情況下，最好是不要隨便越級匯報。）

你必須要獲得支持。那怎么獲得，就取決于你所發現的痛點與你的解決方案是否能打動他們了。

第五步，承接它并解決它

提出問題簡單，問題最終還是要被解決。

既然前面已經做了那么多的鋪墊了，這個時候，你就要把這件事情給攬下，并且要能做成。

有人還是會有顧慮：“那我去做專項改造了，不像日常版本開發，產出沒那么明顯，怎么辦？“

答案其實很簡單，你要以盡量不傷害領導業務為代價去達成目標。

什么意思？

舉個例子，上半年我識別到一個很關鍵的技術債，而產品經理那邊更關注發布業務，他們并不太想我去做。

但這件事情對日后開發的節奏會很有幫助，很多功能可以復用其他產品線的，開發能效會大幅提升。

我給產品經理提的是，這一兩個月會少一個人力，不會占用特別多，你的業務需求我會想辦法幫你解決，盡量不影響發布。

對你的干系人不會造成太大利益上的傷害，那自然他們就沒太多意見了。

那回到個人身上怎么做？

以性能改造舉個例子，那你可以這樣和你的領導講：最近的業務開發我想少投入一點，把時間放在性能改造上，業務版本大概按0.8來投入，你看是不是可以？我預計三到四個月，我就能把這個改造好，對整體的改善會很大。

自然，你肯定是需要額外多花一些時間去處理這些難題。

如果你既能把業務開發做的還算不錯，還能把專項也做好了，那對你的發展（在公司里、個人能力、思維）都是很大的幫助。

第六步，形成循環

當你按這個步驟走了一遍之后，就會發現，其實沒那么難。

完成基本工作，做好基本工作，發現痛點，提煉包裝成大的項目，承接和解決它，自然就是晉升了。

而且這個過程和普通的工作有什么區別呢？區別是很大的。

仍以搬磚舉例：

如果你是用加班加點的方式，你會發現短時間你的產出是上去了，你能加班一個月，但你能加班一年么？不加班后，是不是就產出下降了？而且，用這種方式，你的技能是不會得到提升的。

如果你是用設計流程、改變流程、改良工具的方式，你就會發現，前期好像確實更忙，不僅要搬磚，還要花額外的時間去思考和設計。但是，做成之后呢？你就不用再加班加點了，并且你的綜合能力也有了提升。

希望對看到這里的你有所啟發，感謝收看。