現象
最近和一位專案經理聊天。這位PM之前是個技術大牛，沒什麼搞不定的東西，而且做事也認真，也賣命。領導沒理由不提拔這種牛人。所以，這個專案讓這哥們當PM。
聊著聊著，這位牛人發出一聲感慨，現在的員工不好帶啊，每天到了晚上7點，就只剩我和另一個小組長了。專案組10多個人，都跑的精光。
我樂了。其實這種情況，我也是碰到過的，在我帶的第一個專案，也是類似的情況。我不敢武斷的下決定，就跟他多聊了幾句。
問：那你大概幾點下班的？
答：每天都11點之後。
問：任務很重嗎？
答：其實也不重。
問：那些走了的人，你沒有安排任務給他們嗎？
答：安排不了。
問：為什麼不能給他們安排任務呢？
答：他們搞不定。
問：為什麼搞不定啊？
答：我也不知道。我嘗試給他們分配了任務，但是到頭來，那些問題又到我和XXX（另一個小組長）手上了。
後面我也不需要多問了，大概就是我估計的情況。
我把這種情況，稱之為：掛包袱現象。
分析
為什麼叫包袱現象呢？我們可以這麼來描述。
每個專案，其實是一個大包袱。一個公司有大大小小的許多包袱，每個包袱合理完整的解開了，裡面就有利潤。但是如果包袱解開不正確，就會減少利潤，甚至破壞利潤。
那麼每個包袱，都交給一個專案經理來解。專案經理帶領一幫兄弟，負責把這個包袱合理的解開。而包袱是可分解的，也就是說，包袱可以分成大大小小的子包袱，如何解開子包袱，也是每個專案組成員的工作。
對於一個專案經理來說，最重要的工作，是如何把大包袱，合理的分解成小包袱，然後合理的分配給專案組成員來解，並且需要隨時監控小包袱的解開情況，一旦發現有小包袱解開的步驟不合理，立即予以干預；如果發現有大包袱分解方式不合理，也必須儘早的改正。
專案經理最重要的工作是不是，自己親自擼袖子去解包袱呢？
答案很容易說，當然不是。但是，一般初次做PM的人，就容易走進這個圈套。
例子
我們來說一個例子吧。
專案經理甲，在專案一開始分配任務的時候，這麼安排的：
A同學，你做###1模組；B同學，你做###2模組；C同學，你做###3模組。剩下最難的###4模組和framework我來做。要求5天完成。
OK，貌似挺合理的，ABC三位工程師就去幹活了。
A同學比較聰明，第一天就完成了50%，下班就走了。第二天就做完了，下班也走了，然後就優哉遊哉的玩了三天，等著最後的時候昂首挺胸的彙報佳績。
B同學很賣力，但是偏偏###2模組比較麻煩。B同學第一天完成了50%，加班到8點下班了。第二天碰到一個難題，搞不定了。於是向甲求助。甲無奈去幫B同學分析了一下午，終於把這個問題解決了。這時甲延遲半天。第三天，B同學又碰到一個難題，再次請教甲，甲分析了一上午，搞不定了，於是扔下一句話：這個等我有空來看吧。於是，B同學第三天努力的分析問題，加班到10點。第四天，B同學想著反正甲答應解決的，於是在下班後就回家了，也沒有加班。
C同學是個新人，對於環境也不熟悉。第一天熟悉了一天開發環境。第二天毛毛糙糙的做了一點東西，感覺還不錯。於是，第三天第四天，不用加班就把東西做出來了。第五天，C同學很開心的彙報說，工作做完了。
第五天下班的時候，甲自己已經延遲了2天的進度，其中1天是因為幫助B同學，還有1天是因為各種會議、各種報銷等閒雜事情，忙的焦頭爛額。甲隨便的問了下ABC的進度，發現A和C已經完成了，B的問題需要甲自己解決。
於是，甲週末來加班了。在吃午飯的時候，隨便瞄了一眼C的程式碼，乖乖，和自己的預期差的十萬八千里。於是，只好把C的東西去掉，自己開始從頭做。
於是第二週，ABC都在等著甲。A等著甲分配任務，B等著甲幫著解決問題，C等著甲改造自己的程式。而甲還得趕緊把###4模組做出來，framework還有一堆BUG要改。
於是，甲開始向周圍的人抱怨，說自己的專案組如何不努力。在公司領導的干預下，甲公佈了一條規定：每週一二三四，必須晚上9點鐘下班。
在第二週的週五，甲拖著疲憊的身軀，向大家宣佈：專案進展不順，週六加班。於是在抱怨聲中，ABC只能無奈的週末來加班，陪著甲去解決問題。
以上是個簡化的描述，但是和大多數初當PM的人碰到的現象大差不差。
對於專案經理甲來說，他分包袱的工作太隨意，並且沒有跟蹤小組成員解包袱的進度，直接導致了最終的結果：所有的包袱都在自己的手上。這就是我所說的，掛包袱現象。
很多技術牛人，都會不服氣專案經理，認為這個人只是在分配任務，整天追著我們要工作進度，自己不做事，碰到難題就扔給我。但是一旦他自己做到了專案經理的位置，他就應該知道，分配任務，追著要進度，這就是專案經理的工作重心！
我只是說工作重心，不是全部的工作。我也不會說，專案經理不需要寫程式碼。專案經理適當的寫些程式碼，對控制專案會有很大的幫助。這個我們以後再討論。我們來分析下，專案經理如何去規避“掛包袱”的問題，讓專案組成員能夠一起來完成專案呢？
改進
1、首先，不要把組員想象的那麼壞。
很多專案經理，一旦看到專案組的組員棄自己不顧，徑直就下班走了，就會大發雷霆，然後把組員定義為：壞孩子。然後，就不敢分配給組員任務了，什麼東西不如自己做。就經常聽到有PM抱怨，現在80後不好管，沒有責任心。其實，我帶過的80後，雖然個性強一點，但是責任心並沒有想象的那麼糟糕。雖然也有責任心不強的，但是不會一個專案組都那麼差吧。出了問題，要從自己身上找原因。
如果任務安排合理清晰，我想大多數工程師都會把任務的責任給擔起來的。所以要注意以下幾點：
a）定義任務，一定要清晰明確。
b）分配了任務，不能到最後再去檢查。
c）隨時根據任務完成情況，來調整後面的工作。
d）不要隨意把任務收回來。
2、其次，不要把組員想象的那麼笨。
很多技術牛人提拔上來的PM，都不敢相信自己下屬的能力。他們一旦看到下屬的程式碼寫的不好，結構不好，用的API不對，註釋不夠清晰等等，就對下屬的技術能力打上一個叉叉。在之後的工作中，什麼都不敢放給下屬做。下屬一旦工作有點失誤，就大發雷霆。
記住，哪怕你的確是這個專案組裡技術最牛的，你也不要這麼做。為什麼？
a）公司無法給10個像你這麼牛的人，讓你做專案經理
b）如果真的給了10個人讓你來管，你未必管的了他們
c）你如果太牛了，下屬哪裡來的機會去犯錯。沒有犯錯的機會，怎麼得到成長
3、最後，不要把自己想象的那麼神。
這句話看上去跟前面兩句差不多，其實還是有差別的。最大的意義就是：不要什麼事情都自己做。記住，PM的目標是把專案做好，不是一個人的表演。你再牛，你也沒法一個人做完10個人的專案。就算你做完了，也是10個人的功勞，不是你一個人的。所以，要放手給下屬去做。
改進例子
我如果是專案經理，以上那個例子，我會這麼安排。
A去做最難的###4模組和framework。B做###2模組，C做###3模組，我自己做###1模組。
第一天，我不會立即開始做###1模組。先看每人的工作。發現C做的程式碼不好，就安排B去輔導。
第二天，B告訴我###2模組搞不定。我讓他自己解決。我開始做我的###1模組。
第三天，B還是搞不定。我幫他搞一上午，我發現了問題，然後告訴他如何解決，讓B花一下午去解決。
第四天，B還需要幫助C，所以時間不夠了。我告訴B，你不要幫C了，你專心完成###2模組吧。我自己來幫C。A來向我抱怨工作太多，我說表現你的技術實力的時候到了。
第五天，B又碰到問題了。我讓他先自己解決。C已經完成了###3了，我讓C幫我做###4，我同時看B的問題。
第六天，如果專案緊張，可以加班一天。如果在BUFF的控制範圍內，那可以在下週一完成。A做完了###4和framework，B的問題自己終於解決了，雖然我也解決了，但是我不告訴他，只是誇他做的很棒。C把###4也做完了，雖然我還要把###4再改進一下。
我想，雖然工作很緊張，但是大家都加一天班（或者專案里程碑延期一天），基本上就都搞定了。每個人都有機會做出貢獻，雖然忙，但是專案組的氣氛還是不錯的。
掛包袱現象，是我自己提煉的，希望能給才做PM的人，以及以後希望在這方面有發展的人一些幫助。