現象
近和一位項目經理聊天。這位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只能無奈的來加班，陪著甲去解決問題。
