專案經理問:為什麼總是隻有我在加班 – 掛包袱現象

出版圈郭志敏發表於2011-09-21

文章來源

現象

最近和一位專案經理聊天。這位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的人,以及以後希望在這方面有發展的人一些幫助。

相關文章