[專案管理]弱勢專案管理與技術牛人的對抗問題

 下面是來自水木社群軟工板塊上的一個討論，比較有典型性，所以，重發在這裡。

發信人: redolence (雷德隆…還有一個斯), 信區: SoftEng
標  題: 很棘手的問題，求解。
發信站: 水木社群 (Sat Nov 14 15:13:29 2009), 站內

關於專案管理的

專案開發了一半，專案組加入一位牛人，於是發生了這些事：
1.大牛說原來寫的程式碼效率不高，構架繁冗，不方便後期維護，要求重構程式碼和資料庫。
2.老成員認為自己辛苦寫的程式碼被一票否決，心裡很不爽，但是也承認自己的程式碼質量不高。
3.我作為專案負責人，在牛人加入前已經彙報了一次專案開發進度，並已經演示了系統功能。已開發部分的功能已經被使用者接受並認可，且使用者至少目前沒有提出對效能的要求，但是預計將來會提到這個問題。到時候再重構，會更加麻煩。
4.領導認為我們的進度已經落後於計劃，急需完成剩餘部分功能的開發。在我演示了系統功能之後，已經申請了一次計劃調整，基本得到使用者的理解。

問題是：
1.如果系統重構，很有可能需要再次調整計劃，而使用者已經明確表示計劃是不可能再調整的了。
2.大牛在技術上沒有問題，但是缺乏時間觀念，且身兼多個專案，重構速度令人失望。
3.老成員一開始挺配合系統重構，但是隨著重構的深入，發現難度很大，基本等於重新開發。對大牛很有意見，開始不怎麼配合了。

請問，作為專案負責人，這個怎麼辦？

發信人: qingrun (青潤), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sat Nov 14 16:06:46 2009), 站內

似乎算是個典型案例了，一個魯莽但是經驗豐富的技術人員，粗魯的忽視了開發進度和客戶需求，進行單方面技術改進的要求，公司因為專案款項回收速度慢而指責團隊開發進度，一個無奈的弱勢專案經理缺乏經驗幾乎無法處理全部問題。呵呵
如果是我，會根據情況進行操作：
1、資源不緊張，則安排牛人的方法進行同步開發推動，原有團隊繼續原來的進度開發，牛人蔘與一些稽核工作，同時進行他的第二個版本的開發。
2、資源緊張，安排牛人的方法放在二期（第二個版本），他本人必須跟進原來的開發模式參與稽核，如果拒絕則進行疏導或者請其本人單獨先進性第二版本開發，原有團隊進度不變。

【 在 redolence (雷德隆…還有一個斯) 的大作中提到: 】
: 關於專案管理的
: 專案開發了一半，專案組加入一位牛人，於是發生了這些事：
: 1.大牛說原來寫的程式碼效率不高，構架繁冗，不方便後期維護，要求重構程式碼和資料庫。
: ...................

發信人: redolence (雷德隆…還有一個斯), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sat Nov 14 16:20:50 2009), 站內

那大牛曾說可以在一週之內重構完畢，且說計劃中分配給他的功能模組時間有冗餘，肯定不會影響開發進度，但是就同意了大牛的意見，團隊停止開發新功能，由他主導負責重構。
但是由於他的另一個專案的計劃也很緊張，且另一個專案的負責人也是我的領導，我在爭奪資源上處於劣勢。所以大牛隻有不到50％的精力參與其中。

現在一週已經過去，重構工作完成1/4，大牛堅持說不會影響進度，後面的功能模組用不了那麼長的時間。作為專案負責人，我覺得這個風險很大，所以有點灰心了。


【 在 qingrun (青潤) 的大作中提到: 】
似乎算是個典型案例了，一個魯莽但是經驗豐富的技術人員，粗魯的忽視了開發進度和客戶需求，進行單方面技術改進的要求，公司因為專案款項回收速度慢而指責團隊開發進度，一個無奈的弱勢專案經理缺乏經驗幾乎無法處理全部問題。呵呵
如果是我，會根據情況進行操作：
1、資源不緊張，則安排牛人的方法進行同步開發推動，原有團隊繼續原來的進度開發，牛人蔘與一些稽核工作，同時進行他的第二個版本的開發。
2、資源緊張，安排牛人的方法放在二期（第二個版本），他本人必須跟進原來的開發模式參與稽核，如果拒絕則進行疏導或者請其本人單獨先進性第二版本開發，原有團隊進度不變。

【 在 redolence (雷德隆…還有一個斯) 的大作中提到: 】
: 關於專案管理的
: 專案開發了一半，專案組加入一位牛人，於是發生了這些事：
: 1.大牛說原來寫的程式碼效率不高，構架繁冗，不方便後期維護，要求重構程式碼和資料庫。
: ...................

發信人: qingrun (青潤), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sat Nov 14 17:50:59 2009), 站內

我 上面這樣說就是因為我很清楚大牛為什麼會如此提出他的考慮，即使他一個星期可以重構完畢，重構結束後的新架構其他技術人員是否能夠適應，是否能夠儘快上手 進行開發和補充修訂，這都是問題。不是說，他認為一個星期完畢，就如何如何，一個專案的風險不能依靠一個人來解決，那樣，他個人就成了整個專案最大的風 險，一旦他生病，住院，出車禍，難道說，他就可以保證自己100%不會發生意外麼？這些生活中的意外都不可避免，專案中也可能會有他沒有評估到的地方。
從你的回答中看出來，你的經驗實在太少了，你應該去看看人月神話，人件，人件集，死亡之旅這幾本書，就能明白我為什麼會有上面的兩種建議。
即使對於微軟這種大公司，他們的新產品核心架構的推出都是需要分階段的，也不是一次性完成的。
你們這位大牛的做法其實是集中了風險應力點，一旦這個風險發生，專案就會直接終止，他的建議最多適用於第二版本開發或者公司資金資源剩餘情況下的產品化開發。專案，尤其是工程專案，應該考慮的是分散風險，降低風險，而不是風險集中。
【 在 redolence (雷德隆…還有一個斯) 的大作中提到: 】
: 那大牛曾說可以在一週之內重構完畢，且說計劃中分配給他的功能模組時間有冗餘，肯定不會影響開發進度，但是就同意了大牛的意見，團隊停止開發新功能，由他主導負責重構。
: 但是由於他的另一個專案的計劃也很緊張，且另一個專案的負責人也是我的領導，我在爭奪資源上處於劣勢。所以大牛隻有不到50％的精力參與其中。
: 現在一週已經過去，重構工作完成1/4，大牛堅持說不會影響進度，後面的功能模組用不了那麼長的時間。作為專案負責人，我覺得這個風險很大，所以有點灰心了。
: ...................

發信人: redolence (雷德隆…還有一個斯), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sat Nov 14 19:46:33 2009), 站內

確實沒有經驗，第一個負責的專案
謝謝回覆，學習了。
【 在 qingrun (青潤) 的大作中提到: 】
我 上面這樣說就是因為我很清楚大牛為什麼會如此提出他的考慮，即使他一個星期可以重構完畢，重構結束後的新架構其他技術人員是否能夠適應，是否能夠儘快上手 進行開發和補充修訂，這都是問題。不是說，他認為一個星期完畢，就如何如何，一個專案的風險不能依靠一個人來解決，那樣，他個人就成了整個專案最大的風 險，一旦他生病，住院，出車禍，難道說，他就可以保證自己100%不會發生意外麼？這些生活中的意外都不可避免，專案中也可能會有他沒有評估到的地方。
從你的回答中看出來，你的經驗實在太少了，你應該去看看人月神話，人件，人件集，死亡之旅這幾本書，就能明白我為什麼會有上面的兩種建議。
即使對於微軟這種大公司，他們的新產品核心架構的推出都是需要分階段的，也不是一次性完成的。
你們這位大牛的做法其實是集中了風險應力點，一旦這個風險發生，專案就會直接終止，他的建議最多適用於第二版本開發或者公司資金資源剩餘情況下的產品化開發。專案，尤其是工程專案，應該考慮的是分散風險，降低風險，而不是風險集中。
【 在 redolence (雷德隆…還有一個斯) 的大作中提到: 】
: 那大牛曾說可以在一週之內重構完畢，且說計劃中分配給他的功能模組時間有冗餘，肯定不會影響開發進度，但是就同意了大牛的意見，團隊停止開發新功能，由他主導負責重構。
: 但是由於他的另一個專案的計劃也很緊張，且另一個專案的負責人也是我的領導，我在爭奪資源上處於劣勢。所以大牛隻有不到50％的精力參與其中。
: 現在一週已經過去，重構工作完成1/4，大牛堅持說不會影響進度，後面的功能模組用不了那麼長的時間。作為專案負責人，我覺得這個風險很大，所以有點灰心了。
: ...................

發信人: qlw (錢五哥), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sat Nov 14 20:49:19 2009), 站內


同意qingrun的說法，我看到這個案例後的第一反應就是將大牛的方案
放入下個版本，不影響本次開發，但是在接下來的開發中要考慮到大牛
的建議，便於將程式碼重用到下個版本，同時也讓專案組成員逐步熟悉
並思考新方案。

另外，軟體專案的PM是需要明白技術的，至少能夠估計到工作量，大牛
再牛，也有估計不到的地方，更何況還有時間問題。

【 在 qingrun (青潤) 的大作中提到: 】
: 我上面這樣說就是因為我很清楚大牛為什麼會如此提出他的考慮，即使他一個星期可以重構完畢，重構結束後的新架構其他技術人員是否能夠適應，是否能夠儘快上手進行開發和補充修訂，這都是問題。不是說，他認為一個星期完畢，就如何如何，一個專案的風險不能依靠一個人來解
: 從你的回答中看出來，你的經驗實在太少了，你應該去看看人月神話，人件，人件集，死亡之旅這幾本書，就能明白我為什麼會有上面的兩種建議。
: 即使對於微軟這種大公司，他們的新產品核心架構的推出都是需要分階段的，也不是一次性完成的。
: ...................

發信人: qingrun (青潤), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sat Nov 14 21:33:02 2009), 站內

五 哥，我覺得，專案經理如果不懂得技術，也可以做好專案經理，那就需要更好的態度和更多的配合和詢問，更多的增加內部的交流，但是，他必須有足夠的邏輯判斷 能力，而不能糊塗，畢竟專案經理要負責整個專案的成敗，失敗了，他應該是責任承擔者，絕對不能推卸責任。這樣的專案經理我定義為弱勢專案經理，和強勢專案 經理相對，也就是非技術主導形態的專案經理存在方式。
強勢專案經理可以在一些判斷中，先下結論執行後解釋，而若是專案經理永遠要以解釋和討論為主 導，後下結論或者說後執行。這樣的形態，加上好的態度，也一樣可以很好的控制專案的進度——我05年-06年在中科院自動化所模式識別實驗室的角色，就是 弱勢專案經理的做法，畢竟不是我所長的傳統工程軟體的開發技術，最後的效果還是很不錯的，呵呵。
【 在 qlw (錢五哥) 的大作中提到: 】
: 同意qingrun的說法，我看到這個案例後的第一反應就是將大牛的方案
: 放入下個版本，不影響本次開發，但是在接下來的開發中要考慮到大牛
: 的建議，便於將程式碼重用到下個版本，同時也讓專案組成員逐步熟悉
: ...................
: 另外，軟體專案的PM是需要明白技術的，至少能夠估計到工作量，大牛
: 再牛，也有估計不到的地方，更何況還有時間問題。

發信人: qlw (錢五哥), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sun Nov 15 02:55:55 2009), 站內


不反對你的提法，是有各種型別的軟體專案經理。能管理好一個
軟體專案，有兩大要求，一是要思路清晰，善於交流溝通，二是要明白
具體技術要求，從技術性較弱的開發流程技術到技術性較強的開發
技術。我見過各種PM，思路清晰和善於交流是最為重要的，明白技術
並非最為重要，但是在專案時間緊、風險高的專案中，技術能力
強的PM更能把控專案的進度、人員安排和風險。


【 在 qingrun (青潤) 的大作中提到: 】
: 五哥，我覺得，專案經理如果不懂得技術，也可以做好專案經理，那就需要更好的態度和更多的配合和詢問，更多的增加內部的交流，但是，他必須有足夠的邏輯判斷能力，而不能糊塗，畢竟專案經理要負責整個專案的成敗，失敗了，他應該是責任承擔者，絕對不能推卸責任。這樣的
: 強勢專案經理可以在一些判斷中，先下結論執行後解釋，而若是專案經理永遠要以解釋和討論為主導，後下結論或者說後執行。這樣的形態，加上好的態度，也一樣 可以很好的控制專案的進度——我05年-06年在中科院自動化所模式識別實驗室的角色，就是若是專案經理的做法，畢竟

發信人: qingrun (青潤), 信區: SoftEng
標  題: Re: 很棘手的問題，求解。
發信站: 水木社群 (Sun Nov 15 11:39:28 2009), 站內

是的，技術的強弱有時候是有促進作用的，前提是PM頭腦清晰，不陷入自己對自己的過度信任中。
我這麼提也主要是為了反駁國內曾經一度十分盛行的所謂專案經理必須懂技術甚至必須是這一行業技術高手的說法和認識。呵呵

【 在 qlw (錢五哥) 的大作中提到: 】
: 不反對你的提法，是有各種型別的軟體專案經理。能管理好一個
: 軟體專案，有兩大要求，一是要思路清晰，善於交流溝通，二是要明白
: 具體技術要求，從技術性較弱的開發流程技術到技術性較強的開發
: ...................

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-619634/，如需轉載，請註明出處，否則將追究法律責任。