出處：
現象
最近和一位專案經理聊天。這位pm之前是個技術大牛，沒什麼搞不定的東西，而且做事也認真，也賣命。領導沒理由不提拔這種牛人。所以，這個專案讓這哥們當pm。
聊著聊著，這位牛人發出一聲感慨，現在的員工不好帶啊，每天到了晚上7點，就只剩我和另乙個小組長了。專案組10多個人，都跑的精光。
我樂了。其實這種情況，我也是碰到過的，在我帶的第乙個專案，也是類似的情況。我不敢武斷的下決定，就跟他多聊了幾句。
問：那你大概幾點下班的？
答：每天都11點之後。
問：任務很重嗎？
答：其實也不重。
問：那些走了的人，你沒有安排任務給他們嗎？
答：安排不了。
問：為什麼不能給他們安排任務呢？
答：他們搞不定。
問：為什麼搞不定啊？
答：我也不知道。我嘗試給他們分配了任務，但是到頭來，那些問題又到我和***（另乙個小組長）手上了。
後面我也不需要多問了，大概就是我估計的情況。
我把這種情況，稱之為：掛包袱現象。
為什麼叫包袱現象呢？我們可以這麼來描述。
每個專案，其實是乙個大包袱。乙個公司有大大小小的許多包袱，每個包袱合理完整的解開了，裡面就有利潤。但是如果包袱解開不正確，就會減少利潤，甚至破壞利潤。
那麼每個包袱，都交給乙個專案經理來解。專案經理帶領一幫兄弟，負責把這個包袱合理的解開。而包袱是可分解的，也就是說，包袱可以分成大大小小的子包袱，如何解開子包袱，也是每個專案組成員的工作。
對於乙個專案經理來說，最重要的工作，是如何把大包袱，合理的分解成小包袱，然後合理的分配給專案組成員來解，並且需要隨時監控小包袱的解開情況，一旦發現有小包袱解開的步驟不合理，立即予以干預；如果發現有大包袱分解方式不合理，也必須盡早的改正。
專案經理最重要的工作是不是，自己親自擼袖子去解包袱呢？
答案很容易說，當然不是。但是，一般初次做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要改。
以上是個簡化的描述，但是和大多數初當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的問題。
第六天， 加班一天。a做完了###4和framework，b的問題自己終於解決了，雖然我也解決了，但是我不告訴他，只是誇他做的很棒。c把###4也做完了，雖然我還要把###4再改進一下。
我想，雖然工作很緊張，但是大家都加一天班，基本上就都搞定了。每個人都有機會做出貢獻，雖然忙，但是專案組的氣氛還是不錯的。
掛包袱現象，是我自己提煉的，希望能給才做pm的人，以及以後希望在這方面有發展的人一些幫助。
專案經理問 為什麼總是只有我在加班 掛包袱現象
現象 最近和一位專案經理聊天。這位pm之前是個技術大牛，沒什麼搞不定的東西，而且做事也認真，也賣命。領導沒理由不提拔這種牛人。所以，這個專案讓這哥們當pm。聊著聊著，這位牛人發出一聲感慨，現在的員工不好帶啊，每天到了晚上7點，就只剩我和另乙個小組長了。專案組10多個人，都跑的精光。我樂了。其實這種情...
專案經理問 為什麼總是只有我在加班 掛包袱現象
現象 最近和一位專案經理聊天。這位pm之前是個技術大牛，沒什麼搞不定的東西，而且做事也認真，也賣命。領導沒理由不提拔這種牛人。所以，這個專案讓這哥們當pm。聊著聊著，這位牛人發出一聲感慨，現在的員工不好帶啊，每天到了晚上7點，就只剩我和另乙個小組長了。專案組10多個人，都跑的精光。我樂了。其實這種情...
專案經理問 為什麼總是只有我在加班 掛包袱現象
出處 現象 最近和一位專案經理聊天。這位pm之前是個技術大牛，沒什麼搞不定的東西，而且做事也認真，也賣命。領導沒理由不提拔這種牛人。所以，這個專案讓這哥們當pm。聊著聊著，這位牛人發出一聲感慨，現在的員工不好帶啊，每天到了晚上7點，就只剩我和另乙個小組長了。專案組10多個人，都跑的精光。我樂了。其實...