以上是個簡化的描述，但是和大多數(shù)初當PM的人碰到的現(xiàn)象大差不差。
對于項目經(jīng)理甲來說，他分包袱的工作太隨意，并且沒有跟蹤小組成員解包袱的進度，直接導致了終的結果:所有的包袱都在自己的手上。這是我所說的，掛包袱現(xiàn)象。
很多技術牛人，都會不服氣項目經(jīng)理，認為這個人只是在分配任務，整天追著我們要工作進度，自己不做事，碰到難題扔給我。但是一旦他自己做到了項目經(jīng)理的位置，他應該知道，分配任務，追著要進度，這是項目經(jīng)理的工作重心！
我只是說工作重心，不是全部的工作。我也不會說，項目經(jīng)理不需要寫代碼。項目經(jīng)理適當?shù)膶懶┐a，對控制項目會有很大的幫助。這個我們以后再討論。我們來分析下，項目經(jīng)理如何去規(guī)避“掛包袱”的問題，讓項目組成員能夠一起來完成項目呢?
改進
1. 首先，不要把組員想象的那么壞。
很多項目經(jīng)理，一旦看到項目組的組員棄自己不顧，徑直下班走了，會大發(fā)雷霆，然后把組員定義為：壞孩子。然后，不敢分配給組員任務了，什么東西不如自己做。經(jīng)常聽到有PM抱怨，現(xiàn)在80后不好管，沒有責任心。其實，我?guī)н^的80后，雖然個性強一點，但是責任心并沒有想象的那么糟糕。雖然也有責任心不強的，但是不會一個項目組都那么差吧。出了問題，要從自己身上找原因。
如果任務安排合理清晰，我想大多數(shù)工程師都會把任務的責任給擔起來的。所以要注意以下幾點：
a) 定義任務，一定要清晰明確。
b) 分配了任務，不能到后再去檢查。
c) 隨時根據(jù)任務完成情況，來調整后面的工作。
d) 不要隨意把任務收回來。
2. 其次，不要把組員想象的那么笨。
很多技術牛人提拔上來的PM，都不敢相信自己下屬的能力。他們一旦看到下屬的代碼寫的不好，結構不好，用的API不對，注釋不夠清晰等等，對下屬的技術能力打上一個叉叉。在之后的工作中，什么都不敢放給下屬做。下屬一旦工作有點失誤，大發(fā)雷霆。
記住，哪怕你的確是這個項目組里技術牛的，你也不要這么做。為什么？
a) 公司無法給10個像你這么牛的人，讓你做項目經(jīng)理
b) 如果真的給了10個人讓你來管，你未必管的了他們
c) 你如果太牛了，下屬哪里來的機會去犯錯。沒有犯錯的機會，怎么得到成長
3. 后，不要把自己想象的那么神。
這句話看上去跟前面兩句差不多，其實還是有差別的。大的意義是：不要什么事情都自己做。記住，PM的目標是把項目做好，不是一個人的表演。你再牛，你也沒法一個人做完10個人的項目。算你做完了，也是10個人的功勞，不是你一個人的。所以，要放手給下屬去做。
改進例子
我如果是項目經(jīng)理，以上那個例子，我會這么安排。
A去做難的###4模塊和framework。B做###2模塊，C做###3模塊，我自己做###1模塊。
第， 我不會立即開始做###1模塊。先看每人的工作。發(fā)現(xiàn)C做的代碼不好，安排B去輔導。
第二天， B告訴我###2模塊搞不定。我讓他自己解決。我開始做我的###1模塊。
第三天， B還是搞不定。我?guī)退阋簧衔纾野l(fā)現(xiàn)了問題，然后告訴他如何解決，讓B花一下午去解決。
第四天， B還需要幫助C，所以時間不夠了。我告訴B，你不要幫C了，你專心完成###2模塊吧。我自己來幫C。A來向我抱怨工作太多，我說表現(xiàn)你的技術實力的時候到了。
第五天， B又碰到問題了。我讓他先自己解決。C已經(jīng)完成了###3了，我讓C幫我做###4，我同時看B的問題。
第六天， 如果項目緊張，可以加班。如果在BUFF的控制范圍內，那可以在下周一完成。A做完了###4和framework，B的問題自己終于解決了，雖然我也解決了，但是我不告訴他，只是夸他做的很棒。C把###4也做完了，雖然我還要把###4再改進一下。
我想，雖然工作很緊張，但是大家都加班(或者項目里程碑延期)，基本上都搞定了。每個人都有機會做出貢獻，雖然忙，但是項目組的氣氛還是不錯的。
掛包袱現(xiàn)象，是我自己提煉的，希望能給才做PM的人，以及以后希望在這方面有發(fā)展的人一些幫助。
