那些技術出身的項目經理們，都給自己挖過什麼坑？

新書

速遞

吳老的java版《selenium webdriver 實戰寶典》和python版《selenium Webdriver 3.0 自動化測試框架實戰指南》出版了，代碼拿來就能用。

文 | 

雷子

授權轉載

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

----------------------------------------

不論在哪個國家，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並沒有那麼做。像做工程師時一樣，在這個問題上刨根問底，但

整個過程卻只是他的自我滿足

本來項目經理和成員之間是互相信任的，由於這件事，信賴關係也出現了裂痕。

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

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

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

教訓二

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

（未完待續）

東京IT人

和小夥伴們分享島國趣事，

特別是IT相關。

歡迎大家踴躍提意見，

希望在大家的幫助下越辦越好！

程序bug造成天大的損失，要槍斃程序員嗎？

孤島化嚴重的日本IT行業將何去何從？

排名第一的大銀行，系統居然爛成這樣，我也是醉了

【搞笑視頻】看島國最黑科技，如何做到讓你下班瞬移回家

點此鏈接了解

2018web測試開發培訓一年期周六班！

請

在

喜馬拉雅

收聽「

光榮之路

光榮之路

招聘|徵稿|合作

|QQ群

735821166@qq.com

python群：457561756

性能群：415987441

招聘群：203715128

感謝認真閱讀的你！

?

推薦閱讀：