那些年，被自己的技術者思維虐過的項目經理們

不論在哪個國家，IT 公司中的項目經理，很大一部分都是技術出身。的確，工程師背景的項目經理，在開發人員選擇，開發進度控制，客戶需求把握等諸多方面，有得天獨厚的優勢，從程序員到 leader 再到項目經理也是常見職場發展方向之一。

雷子個人認為，從普遍意義上講，在日本，只要勤奮努力，向上走是很容易的事。但到了管理崗位，即使勤奮努力，有時候思維沒有及時轉變，也可能遭遇慘敗。我就親見過智商一流，經驗豐富技術人員，初任項目經理時，分外努力卻搞得焦頭爛額，甚至在項目中途被換下，經過很久很久才熬到第二次被提拔……

職場上升之路，有時需要些時運，可能各有不同，但失敗的原因，有時卻很相似。那麼，技術者在初任項目經理時，經常會遇到哪些問題，給自己挖哪些坑呢？

故事一

有時候，謊話連篇的項目經理才是好經理

A 君，認識他時，他是個年輕的 leader，技術很不錯，還有開荒牛般的勤勉，性格也非常開朗坦誠，能力人品雙佳，當 leader 時成績斐然，自然的，他很快升到了項目經理，一時間意氣風發。

A 做 leader 時很受愛戴，成為了項目經理，依舊沿用了一貫的坦率作風，事無巨細，和大家分享所有和項目有關的事。甚至包括：客戶方面的負責人突然換人啊，咱們的契約很危險啊這些情報，也全都毫無保留地告訴給組員們。那麼，像A預期地一樣，全組擰成一股繩，項目圓滿順利地進行下去了嗎？

實際上，並沒有。在充分了解項目的同時，組員們也知道了大量的關於這個項目的不利因素，倍感不安。私底下，咱領導心裡也沒底啊，項目要撲街啊，這樣的議論越來越多，A明明比做技術時更加努力，但項目狀況卻每況越下，回天乏力。

最後，連部長都覺得「怎麼搞成這樣，哎，A還是太年輕。」無奈在項目中期換下了A，讓經驗豐富的B頂上。

B 是個待人和善，初次見面就會讓人印象很好的人。上任後，B和整個項目組的人挨個私聊，發現了問題所在——很多人對本來不用他們操心的事感到不安。這種不安，有時甚至影響到了他們的本職工作。

於是，B把大家召集到一起開會，「通過溝通，我了解了大家現在的想法，和對這個項目前景的擔心。不過這些擔心，很多都是針對潛在的風險的，還有一些問題，是我可以通過斡旋調節解決掉的，balabala……」總之，就是天空飄過幾個字兒，那都不是事兒。

這個會，開得效果很好，B自信滿滿，言之鑿鑿的一番話，很好的安撫了組員們的情緒，大家專心開發，項目進度竟慢慢地趕上了。

那麼B真的像他表現出來的一樣有自信嗎？

事情的真相是，他非常了解——這個破項目，問題一大把。和組員說的話，很多都是他信口胡謅的……

作為項目組的普通成員或者 leader，不管說什麼都要有根有據，信口胡謅是絕對不行的。但這不適用於項目經理。有時候就算是睜著眼說瞎話，也得把組員往正確的方向上帶。

「不管怎麼努力也來不及了」，一旦讓組員有了這種想法，那項目就必定要完。互相扯皮，產生信任危機，生產性下降，品質惡化，是一連串的連鎖反應。無論如何也要避免這種情況的發生。

教訓一

項目經理必須要讓組員相信：「這些情況早就在我的預料和控制之內，大家放心。」只有這樣，組員才能心無旁騖的做好自己的事情。給組員們吃定心丸——是項目管理的手段之一。

這時有的同學可能會說，很多項目從一開始就明擺著是坑，瞎子都能看出來。但即使是這樣，把真實情況全部如實傳達給組員，也是一點好處都沒有。就算項目真的無論如何也挽救不了，那也是項目經理一個人的責任。把真實情況隱瞞下來，讓組員們安心工作，多少還有一點希望。就算撲街，也不會姿勢太慘烈。反過來，把真實情況和盤托出，導致軍心渙散，那就真的一點兒機會也沒有了。

故事二

有時候，不會較真的項目經理才是好經理

C 君做工程師的時候，非常優秀。思維敏捷，邏輯清晰，精通各種開發語言。最重要的是，發生問題時，他一定要刨根問底的追查，不僅要找到解決方法還要找到問題的根本原因，從流程上改進，防止再發。這樣的思考方式和做法，很多工程師都有。

當時的上司和同事們對C君都是絕對地信賴，即使有時他在刨根問底上花費了太多時間，導致進度延遲，上司也都是積極地同客戶調整進度或者加人，從不給他臉色看。

當得知C申請做項目管理，而不是走技術路線的時候，大家都挺吃驚的。不過他作為項目經理，負責的前兩個小型案件都完成得滿好。這時他的上司有些放心了，覺得聰明又努力的人，做什麼都會做得不錯吧。

之後，他被指定去負責一個具有一定規模的項目。這個項目所開發的系統，有十幾個子模塊，每個模塊有3～4 個成員負責。

一天，C收到了客戶發來的郵件「項目進度全體看起來很順利，但是幾個子模塊開發進度為什麼有些延遲？什麼地方出了問題嗎？」

C 作為整個案件的項目經理，通常是掌握項目的大體情況，對於每個子模塊開發的具體細節並沒有過問。第一次被客戶質問開發進度延遲的理由，C有點坐不住了，而且他也產生了同樣的疑問。

於是，C君詢問了這個模塊的每個開發人員，得到的回答是：該模塊所使用的部分第三方產品，有兼容性問題，加上調用方法不對，不斷試錯導致了這部分的開發延遲。可是C還是有疑問：「產品兼容性和調用方法不對，真的會導致生產性這麼大的降低嗎？」

於是C又開始了他對於問題刨根問底式的追查。把每個項目組成員負責的工作細細地捋了一遍，得出的結論是——恩，和他們說的一樣。於是，他向客戶如實地彙報了原因，客戶也接受了他的解釋。

但是他這麼一折騰，本就有點兒延遲的項目，又浪費掉了更多的工數，給組員和他自己又加重了負擔。

本來對客戶作出最初的解釋就完全夠了，可是C並沒有那麼做。像做工程師時一樣，在這個問題上刨根問底，但整個過程卻只是他的自我滿足。本來項目經理和成員之間是互相信任的，由於這件事，信賴關係也出現了裂痕。

在分析問題原因這件事上，項目經理追求的目標應該是客戶的滿足感。如果弄錯了這個目標，花費了大量的精力，那就得不償失了。

比如說客戶問，為什麼這個系統能夠運行？這個時候只要從產品框架的程度上給客戶作出解釋就完全夠了。如果真要從編程語言和計算機原理的開始講給客戶聽，只會讓客戶一頭霧水吧。

確實，如果花費大量的時間精力，去把一個問題徹底弄清，非黑即白，對今後的工作是有幫助的。但這是工程師該做的事情，而不是項目經理。

教訓二

項目經理應該把更多的精力放在客戶和成員的組織協調方面。有時候，不得不對問題的正確性和精準性做出妥協。從工程師出身的經理，往往在這一點上很難轉變。

故事三

有時候，不會和部下同甘共苦的項目經理才是好經理

第三個故事，是我的故事。

大多數工程師都是很單純很熱心的人。如果組裡的其他成員遇到了什麼問題卡住了，很多工程師會留下來加班幫他一起把問題解決掉。但這種做法並不適用於項目經理。

我以前當工程師的時候，一次遇到客戶要求調查一個問題，要的很急。我和項目經理兩個人一直調查到很晚，都沒有做完。眼看要趕不上終電了，項目經理一臉抱歉地對我說：「不好意思啊雷子君，今天就辛苦一下，加個通宵的班吧。」

客戶要求的，也沒有辦法，所以我就很爽快地答應了。本來以為項目經理也會留下來和我一起加班，沒想到這個大哥說了一句「後面的就拜託了！」然後拎包就回家了，只剩下我坐在那裡獨自凌亂。

雖然明知項目經理留下陪我加班沒有意義，但當時不免心裡是頗有微詞的。直到後來我自己也當上了項目經理，才體會到他的做法完全正確。

我作為一個個體的工程師，只要對項目經理一個人負責就可以了。但是項目經理需要對整個項目負責，對客戶負責。如果他留下來陪我一起加班，第二天早晨一起回家的話，那麼第二天的項目推進誰來管？如果客戶對於調查結果有追加的疑問，讓誰來對應？就算他第二天不回家，一直留下來完成自身的工作，那恐怕也是精疲力盡，效率會大打折扣吧。

上面這張圖是網上流傳很久的，leader 和項目經理的區別。作為 leader，和成員們同甘共苦，是很有必要的，但項目經理絕對不可以。反過來，leader 和成員們只要低頭努力工作就夠了，但項目經理坐的位置，決定了只有他才能看到前方有沒有深淵，後面有沒有猛獸。這一點誰都代替不了。

教訓三

技術者升級為項目經理，切不可再像做工程師的時候那樣事事親力親為。懂得自己該做什麼，懂得找擅長的人去做他擅長的事情，才是經營之道。

故事四

有時候，想著「等前提條件都確定了再開工」的項目經理不是好經理

這個故事是個段子。

某日，老師在課堂問一個學生： 「樹上有十隻鳥，開槍打死一隻，還剩幾隻？」

學生反問「是無聲手槍或別的無聲的槍嗎？」

「不是。」

「槍聲有多大？」

「80-100 分貝。」

「那就是說會震的耳朵疼？」

「是。」

「在這個城市裡打鳥犯不犯法？」

「不犯。」

「您確定那隻鳥真的被打死啦？」

「確定。」老師已經不耐煩了「拜託，你告訴我還剩幾隻就行了，OK？」

「OK，樹上的鳥里有沒有聾子？」

「沒有。」

「有沒有關在籠子里的？」

「沒有。」

「邊上還有沒有其他的樹，樹上還有沒有其他鳥？」

「沒有。」

「有沒有殘疾的或餓的飛不動的鳥？」

「沒有。」

「算不算懷孕肚子里的小鳥？」

「不算。」

「打鳥的人眼有沒有花？保證是十隻？」

「沒有花，就十隻。」 老師已經滿腦門是汗，且下課鈴響，但學生繼續問,

「有沒有傻的不怕死的？」

「都怕死。」

「會不會一槍打死兩隻？」

「不會。」

「所有的鳥都可以自由活動嗎？」

「完全可以。」

「如果沒有其他前提條件，」學生滿懷信心的說，「打死的鳥要是掛在樹上沒掉下來，那麼就剩一隻，如果掉下來，就一隻不剩。」

老師擦了擦汗說：「你一定是個程序員……」

編程做久了，往往思維方式會發生固化。工程師都對事物的邏輯性和因果關係有著執拗的追求，「把前提條件全都告訴我」，是工程師的常用語。當然，從工程師的角度來看，前提條件不明確就開工，最後能做出什麼樣的東西來，只有上帝才知道。

但是，這個世界上從來就沒有過從最開始就明確了所有前提和需求的項目。這個時候，就需要對案件的情況做出各種假設，分析可能性，然後在保證最大正確性的前提下開工。如果在項目途中，前提條件或者需求發生了改變，那就再根據具體情況進行調整——這考驗的是項目經理的能力。不這麼做的話，項目永遠也開始不了。在設計第一台月球車的時候，如果 NASA 宇航局的工程師說：「請把月球表面的詳細情報告訴我，否則我沒法設計」，這樣的話人類可能永遠只能在地球上晃悠。當時，月球表面的狀態只能從望遠鏡里觀測到的景象進行推測。雖然前提條件很不充分，但也只有基於最大可能性開始設計，別無他法。

做項目也是一樣。設計系統的時候，要假設各種各樣的前提：系統使用年限，最大並發訪問數，相關的法律會不會更改（特別是政府項目或者和金融相關的系統）……

教訓四

先從最確定，可能性最大的部分開始做起，當需求和前提漸漸明確，再逐步調整進度和人員安排。對於項目全局的把握和大局觀，往往是工程師初任項目經理時，最為欠缺的部分。

今天，和大家分享了幾個小故事，願大家在職場上升道路上避免這些有可能走的彎路，少付出一些成長的代價。

看法淺薄，期待與大家更多的交流討論。更加歡迎老司機們向大家分享自己看到過，經歷過的職場經驗。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！