答覆小寶之“關於專案的人員組織結構”問題

關於專案的人員組織結構

專案組織結構的問題，不知道有沒有人有類似情況
專案情況，專案10個開發人員+1個專案經理+ 5個支援（測試、質控）
開發初期，選定結構1：
專案經理+主程式設計師+其他程式設計師。按照這樣的結構執行了一陣，發現，專案經理不僅要參與交流、管理，還參與了技術方案等，導致專案經理工作量加大。發現專案經理一旦參與了技術，導致配置、文件、溝通、測試等工作往往被專案經理輕視。專案經理的個人意願很大程度決定了專案的走向。專案出現以下情況：專案經理整天特累，開發人員和支援類人員（包括質控、測試、文件等）很多時間處於等待專案經理回覆問題的狀態，專案進度靠非專案經理的工作人員的工作態度和方式支撐。

覺察到以上問題後，調整結構成結構2：專案經理+技術經理+開發人員。
技術經理作技術相關的問題，專案經理就做專案控制、文件、溝通等。結果是專案經理對專案的技術實現和功能瞭解減少，專案中的很多問題專案經理沒法直接管理，在對專案的質量，專案的時間控制，漸漸轉到技術經理層面上。
甚至技術經理分管了技術人員的工作分配，專案經理轉漸轉為所謂的打雜人員且工作量少，專案經理權力減少，態度明顯有牴觸。專案經理也漸漸和技術經理在誰負責什麼問題上產生分歧。且重要的是專案經理和技術經理的工作不是忙，專案出現2個工作只有60%左右的經理。專案最終工作人員對專案人員結構質疑，且很多人開始出現工作推託的情況。

發覺上邊的這種結構也不好。

不知道各位在軟體過程中，開發的組織結構和開發過程中的職責是怎麼定義的？

專案組織結構的問題，不知道有沒有人有類似情況
專案情況，專案10個開發人員+1個專案經理+ 5個支援（測試、質控）
開發初期，選定結構1：
專案經理+主程式設計師+其他程式設計師。按照這樣的結構執行了一陣，發現，專案經理不僅要參與交流、管理，還參與了技術方案等，導致專案經理工作量加大。發現專案經理一旦參與了技術，導致配置、文件、溝通、測試等工作往往被專案經理輕視。專案經理的個人意願很大程度決定了專案的走向。專案出現以下情況：專案經理整天特累，開發人員和支援類人員（包括質控、測試、文件等）很多時間處於等待專案經理回覆問題的狀態，專案進度靠非專案經理的工作人員的工作態度和方式支撐。

覺察到以上問題後，調整結構成結構2：專案經理+技術經理+開發人員。
技術經理作技術相關的問題，專案經理就做專案控制、文件、溝通等。結果是專案經理對專案的技術實現和功能瞭解減少，專案中的很多問題專案經理沒法直接管理，在對專案的質量，專案的時間控制，漸漸轉到技術經理層面上。
甚至技術經理分管了技術人員的工作分配，專案經理轉漸轉為所謂的打雜人員且工作量少，專案經理權力減少，態度明顯有牴觸。專案經理也漸漸和技術經理在誰負責什麼問題上產生分歧。且重要的是專案經理和技術經理的工作不是忙，專案出現2個工作只有60%左右的經理。專案最終工作人員對專案人員結構質疑，且很多人開始出現工作推託的情況。

發覺上邊的這種結構也不好。

不知道各位在軟體過程中，開發的組織結構和開發過程中的職責是怎麼定義的？

穀雨霖答：

其實，不同單位的專案組織結構是不同的，沒有通吃的組織結構。那句俗話“沒有最好只有最適合”，呵呵。
從專案經理所處的未知，專案組織結構通常分為：
1、行政部門劃分：專案有一個協調員，類似通知員的人物。沒有什麼許可權。
2、矩陣管理模式：
弱矩陣：專案經理從某行政部門中出，權利較小。通常是重技術，輕管理型。
平衡矩陣：專案經理從某行政部門中出，權利較多，與部門經理許可權基本等同。技術、管理並舉，經理比較累。
強矩陣：專案經理從屬於獨立的專案經理部門，權利較大（多餘部門經理）。側重管理。
3、專案管理模式：
專案經理對專案所有成員擁有生殺大權，下配技術經理。通常在建築行業。

選擇什麼模式的專案組織，與行業、公司規模有很強關係。關鍵看公司一把手的傾向，以及其主導的專案管理流程，即公司授予專案經理什麼許可權。其實，術業有分工，無論專案經理自己是喜好技術還是喜好管理，頭上公司的緊箍咒制約著他，責任分明就好了。

在IT軟體行業，平衡矩陣、弱矩陣偏多。
我們公司的專案管理模式經歷了行政部門方式、弱矩陣和平衡矩陣幾個階段，目前根據業務特點又在調整。
變化也許是硬道理啊，呵呵。

建議你看看PMBOK前幾張，有專門介紹專案組織關係的。

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