不善言辭的程序員，如何「向上管理」？

我是一個着迷於產品和運營的技術人，樂於跨界的終身學習者。歡迎關注個人我的公衆號「跨界架構師」

每週五11：45 按時送達

個人第「114」篇原創敬上

你們好，我是Z哥。

不知道你是否以爲本身懷才不遇，遇不到一個賞識你的人呢？

又或者以爲一件事情本身已經很努力去作了，但仍是沒法知足上級的要求。

相似的這些狀況在不善言辭的程序員羣體中，尤爲地常見。

若是咱們找不到方式來主動改善這個問題，那就只能聽天由命了。看是否是恰巧天上掉一個「伯樂」下來看到你這匹「千里馬」。

當咱們初入職場的時候，可能對這一點的感知不是很強烈。

那是由於當時你仍是一個行業的新手，有不少知識層面的渴求，僅憑這個動力源就能推進你往前走。

可是，當你一旦進入到知識積累的「平臺期」，對咱們大部分人來講，若是你不在BAT之類的巨頭，缺少了業務難度上的挑戰，惟一剩下的動力源就是他人對你的承認了，特別是上級對你的承認。

不然你就要忍受將來更長期的一段苦悶期，「成就感」將會與你漸行漸遠。

可能不少人認爲「向上管理」中，拍馬屁佔了大部分。

我想每一個人曾經都或多或少有過相似的想法，Z哥我本身也不例外（無奈～）。心裏戲大概是這樣的：

• 我這我的很直接的，纔不會拍領導馬屁。

• 跟領導走的太近不太好吧，別人會怎麼看我。

• 沒有本事的人才成天圍着領導轉。

其實有這樣想法的人只是看到了一個表象。領導之因此能成爲你的上級，天然不傻，腦子是很清楚的，單憑拍馬屁並不會對你的仕途帶來多大的變化。

若是真的靠拍馬屁能上位，那這個企業的發展前景也不會太樂觀，畢竟你們的精力都用到拍馬屁上去了，事情誰來幹？

不過，雖然不少人並不會去拍馬屁，可是容易走到另外一個極端：爲了證實本身是不屑於獻媚領導的人，因此常常直言不諱，甚至非得在觀點、方案的優劣高低上爭出個勝負，最後鬧得你們都不愉快。不知道你身邊有這樣的例子發生嗎？

另外，一聽到「管理」這個詞，大多數人腦子裏第一浮現出來的後一個詞是「員工」或者「下屬」，也就是「管理員工」或者「管理下屬」。

咱們很天然的將一對多關係中的「一」套到「管理」這個詞上。認爲，「管理」是用於「向下」的，而不是「向上」。

其實我以爲偏偏相反。

陳春花教授有一個經典的解讀：

向上才須要管理，向下更應該是負責。

——陳春花：管理者要學會向下負責

我對此的理解是，「向下負責」本質就是對人的負責，對公司資源利用的負責。從因果關係來講，若是能對下作好負責，做爲管理者自己的績效天然也不會太差，因此並不須要刻意的向上表露出你有那麼的「負責」這種浮於表象的狀態。

反而「管理」是要向上的。由於「管理」相比「負責」更具調控色彩，顯得更「柔」，而「負責」則更「剛」一些。咱們具體去執行作一件事才須要「剛」，要達到使命必達的效果。可是與上級的關係處理上，若是「剛」的話，天然矛盾多多，因此更須要「柔」一些的「管理」。

那麼應該怎麼考慮呢？

我以爲這事應該以現代社會的「分工協做」這個角度來考慮。

從這個角度上來看，無論對方是上級仍是下級，本質上都是在與人協做。任何一我的必然有長短、優劣，因此這個事情就變成了一個如何「揚長補短」的事情。作好這個事情分爲三步。

01  構建上級的「用戶畫像」

你要第一件作的事就是想辦法把握各類機會和途徑，搞清楚「你的上級是一位怎樣的人？」。

這個就像CRM系統中的「用戶畫像」概念，你要慢慢地把你上級的一些特色打上標籤，逐漸造成一個清晰的、有血有肉的形象。

好比如下這些問題。

• 溝通風格。喜歡看文字報告仍是喜歡當面聊？
• 管理風格。受權型仍是掌控型？
• 作事風格。注重大局仍是扣細節？
• 性格。有哪些明顯的性格特色？
• 擅長什麼？
• 他如今面臨哪些壓力？
• 他的底線/原則是什麼？
• 他的關係鏈有哪些？與哪些人的信任度較高，哪些較低？
• ……

若是公司有統一的性格測試之類測試報告，如DSCI等，同時你有機會獲知的話，能夠更快的完成這件事情。

另外，你也能夠多關注你上級的作的那些「高頻」的事和說的那些「高頻」的話。

02 揚長

相對來講，一我的的長處相比短處更容易被人發現和識別。而且一我的的長處纔是他的立足之本。因此，咱們優先要考慮的就是如何去「揚長」。

分工協做的本質也就是拿你的長處去與別人的長處去作交換，彌補各自的短處。

好比，你會作寫程序，可是不會賣東西；而銷售會賣東西，不會寫程序。那麼你就把程序交換給銷售去用，讓他能夠賣的更多，而後銷售賺的錢和你一塊兒分。

另外，上級的長處對你來講其實就是一種資源，不少人看不到這一層價值，寧願本身埋頭苦幹。

好比，他的信息渠道比你廣，除了信息量比你大以外，認知能力大機率也比你高。因此不少時候若是能多去請教一下，能夠少走不少彎路。（固然不是拿來主義的請教，帶着本身的思考結果去）

因此，充分利用好你上級的長處，對你作事有事半功倍的效果。

03 補短

這裏有一個很容易陷入的誤區，認爲作下屬的就應該服從領導的安排。其實「服從」不等於「盲從」，由於每一個人都存在短板之處。

也正由於是這樣，因此上級在某些短板的方面對事物的理解和判斷老是偏頗的。這個時候其實你不能聽任上級的不切實際的想法，而要去補上這個「短板的缺口」。

好比說，你的上級是作測試出身的，這時候你做爲一位開發人員，應該在軟件架構、技術選型上給出可維護性、性能、成熟度等等方面的意見，而不是上級說用哪一個就用哪一個。

作好「補短」除了發揮本身的長處、專業性以外，前提是作好一件事——「主動溝通」。這很重要，經過溝通讓你的「長板」與你上級的「短板」作一次對齊。

不然你能夠想象一下，上級對你的指望實際上是你所認爲的300%，你怎麼努力作到120%都沒法讓他滿意。長期以往，你上級對你就會貼上不靠譜的標籤，而你又是啞吧吃黃連，有苦說不出。最終的出路惟有分道揚鑣。

而且，溝通其實也是在上級面前樹立你在本身領域內專業度的機會。

思路清楚了，具體該怎麼作呢？下面舉幾個常見的場景來講說。

01 接收需求/任務

這個場景每一個人都遇到，甚至是每天在發生，由於這件事中你是被動方。

可是有很多人可能接任務的「姿式」並不對。他們會認爲，這有什麼難的，上級讓作啥，就作啥。

雖然工做一兩年以後咱們已經擺脫了初入職場時的須要手把手教的階段，但這種思想也仍是一種很稚嫩的職場思惟。

由於不少時候上級傳遞對信息多是不完整的，或者是沒清楚的，甚至是錯的。

若是你每次來啥接啥，那你大機率會忙的焦頭爛額（其實有一些996是能夠避免的）。最終還會失去上級對你的信任，認爲你不靠譜。

因此，接收任務的時候，你先得作出判斷。最多見的是下面3個問題。

1.這個任務須要往大了考慮仍是往小了考慮？

好比說，上級讓你找一個MQ的中間件來用。有的人會花不少時間整理一份具體的某MQ實施方案出來；有的人則是整理一份多個MQ中間件的優缺點以及與當下實際場景的契合度的文檔。前者就是往小了考慮，後者就是往大了考慮。

若是你不作這個判斷，那你有50%的可能性作的是不符合上級預期的。

2.是真的要作？仍是隻是試探一下你？

通常來講，若是一件事你以爲很大，可是上級又沒明顯給你足夠的資源，甚至是連打算給你多少資源都沒說的話，基本就能判斷這是一件試探性的事情。此時，上級並不肯定這件事值不值得去作。

這個時候比較穩妥的方式是，你花盡量小的成本去幫他完成這個「試探」。

好比，上級和你說：「我看如今你們都在推行Docker，運維效率和擴容速度都能有明顯的提升，咱們也用起來吧」。這個時候他沒說給你多少時間、多少人力去作這個事情，哪怕你真的想去推動這個事情都不必定推的動。

此時你應該找一個與你關係最好的團隊中的最邊緣的業務去嘗試用起來。這樣的話，你既交了差，畢竟這個事你去作了嘛。並且還能獲得一個實際的真實狀況，幫助上級完成了這個「試探」的事情，畢竟網上的文章寫的事情並不必定與你實際狀況相符。後續是否繼續開展就是另外一回事了。

固然，有些事可能很大，大到沒法小規模試運行。這個時候你儘可能去找一些案例型的文章，將這些案例中反映出來的問題收集起來，畢竟案例是很是具體的，不太多是做假、吹牛，甚至其中有一些知名公司作背書，結論的說服力就更強了。

3.任務已經很重了，任務怎麼接？

這個時候必定不要勉強接下，不少不必的996就是這麼產生的。

誠懇地說清楚本身手頭有哪些事，若是要接這個任務的話，是否有什麼任務的安排要順延。

不少人怕說本身接不了任務，以爲會下降上次對本身能力的評價。其實只要是誠懇的溝通，有理有據，凡是一個明理的上級確定會接受的。甚至反而會對你的條理性、作事有主次印象深入。

哪怕最終因爲特殊的重要性，仍是強壓下來作了，那麼至少在將來給你的任務安排上會更剋制一些。畢竟你已經明確的給他了一個反饋，告訴了他本身的負荷上限在哪。

第一個場景寫的有點長，由於這的確對每一個人都很常見。可是後續一些偏主動的事情可能有很多人從未考慮去作。

02 工做彙報

無論是對接收的需求/任務的彙報，仍是由本身發起的彙報。本質上就是一個「如何更快更準的將你的信息傳遞給對方」的過程，固然還能夠順帶尋求一下建議。

這裏面體現了對上級兩個資源的利用，「時間」和「信息」。

不少人在彙報的時候，內容視角是「本身」而不是「對方」。啪啦啪啦只注重本身要說什麼，而不是注重對方想聽什麼？須要聽什麼？

可是要作好這一點，取決於在你這裏上級的「用戶畫像」是否完整，沒有其它的辦法。

不過彙報的內容仍是有一些技巧可循的，我建議的是，使用「總-分」或者「總-分-總」的語言組織形式。

結論先行能夠確保後續的內容有一根「總線」給拉着，不至於讓對方聽到哪思惟就被帶到哪，沒有重點，不知道你在說什麼。本質上也是在作「目標對齊」。

大體是這樣的結構：

• 總（what）：這是一件什麼事。須要你（上級）作什麼。

• 分：事情的前因後果（why），或者分門別類講一下細節（how）。

這個比較好理解，就不展開了。只是在聊「分」的時候注重一些層次感，要儘可能符合線性思惟，按部就班，不要跳來跳去。

03 爭取資源

資源有兩種得到方式。一種是你的價值已經被人承認，主動給你資源。另一種是還未被承認，須要本身主動去爭取資源。這裏聊的是第二種狀況。（與世無爭的不在討論範圍內）

不少人對於爭取資源有一些誤區，在你的價值還未被承認的時候，其實你提供再多過去的成績，也只能算是錦上添花。相比之下，更重要的是你要闡述得到這些資源以後你能夠帶來什麼？

好比最多見的，你但願能升職加薪，啪啦啪啦說了一堆本身作了哪些成績，最後來一句，因此我想漲薪XX，能升職XX。

從形態上，這是一種相互對立的關係。

假如你這麼說，我但願在新的一年能夠加薪XX、能升職到XX。升職以後我有了更多的資源和發揮空間，能夠作XX、XX事情，這些事情能夠帶來XX、XX的效益、價值，因此我值得得到加薪XX。（這也是總-分的內容結構）

從形態上，這是一種並肩做戰的關係。

若是你是上級，你以爲哪一個更容易打動你？

咱們這一輩人想像上一輩那樣在一家企業呆到退休的可能性愈來愈低了。

想要在整個行業、社會上更容易立足，就須要不斷作出更大的成績。而這些都離不開資源的支持。

你的上級是每一個人最近在咫尺的資源，因此，作好「向上管理」是每一個人提升自我價值、更好地在社會立足的關鍵第一步。

人性是趨利避害的，咱們老是想付出更少收穫更多。可是若是你的上級績效沒作好，總的資源包就沒多少，天然分下來也就沒多少。因此，你團隊的績效、甚至是你的績效都取決於你上級的績效，你首先得幫助他成功。

一旦你成了他的得力助手，就至關於你搶佔了他身邊的一個「生態位」。只要他在，你就在。不少人都在尋求的不可替代性就天然而然造成了。

生態位：描述了一個物種在其羣落生境中的功能做用，它是一個物種爲求生存而所需的廣義「資源」。

——維基百科

好比，樹須要陽光和水才能生長，這裏陽光和水便佔了兩個圍繞樹的生態位，缺一不可。

好了，咱們總結一下。

這篇呢，Z哥先分享了一個個人觀點。在工做上得到承認對你的職業道路健康發展很重要，而想要得到承認，作好「向上管理」很重要。

而後闡述了廣泛的兩個誤區。「向上管理就是怕馬屁」，或者「不須要向上管理，向下才須要管理」。

其實咱們應該以「分工協做」的角度來考慮這個問題。搞清楚上級的「用戶畫像」，而後「揚長避短」。

最後分享了三個工做中常見的場景應該如何進行「向上管理」。

但願對你有所啓發。

無論怎樣，但願每一個人至少都能找到你的「生態位」。固然，可以「被向上管理」就更好了。

推薦閱讀：

• 認知的高度 = 人生的高度
• 你們在尋找的高級程序員究竟是什麼樣子的？

做者：Zachary

出處：https://zacharyfan.com/archives/977.html

若是你喜歡這篇文章，能夠點一下右下角的「愛心」，支持個人創做～

▶ 關於做者：張帆（Zachary，我的微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。本文首發於公衆號：「 跨界架構師」（ID：Zachary_ZF）。

若是你是初級程序員，想提高但不知道如何下手。又或者作程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注個人公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思惟導圖。

若是你是運營，面對不斷變化的市場一籌莫展。又或者想了解主流的運營策略，以豐富本身的「倉庫」。歡迎關注個人公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思惟導圖。

按期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些深度思考。