版權宣告：本文為博主原創文章，未經博主允許不得轉載。    https://blog.csdn.net/u010825142/article/details/52814415
有朋友提到：

我們的專案經理都是實施 實施不懂技術 不懂估算工時、進度至做需求調研但是調研效果非常不好。

我們現在專案組成是這樣一個實施+一個軟體負責人作為專案經理。

我們分實施部和開發部，但都很委屈不管是實施專案經理，還是軟體負責人。

俺的建議：

讓實施的做專案經理，這樣也很不錯噢！
好過讓只懂專案管理大道理的人來做。
估算、進度、需求做不好，最後做實施時就很受罪。
所以，你們的專案經理應該有條件和前提做好前面這些事情的。

實施部和開發部的同事可以坐下來好好談，或者打一架也行。

主因就是你們因為分屬於兩個部門，利益沒有能擰在一起的原因。從公司大領導的角度看，這樣的部門設定和專案崗位設定，導致了這樣的問題。大領導應該指導唯一的專案經理，統管全域性。

開發部經理和實施部經理可以商量，每個專案只設立一個大頭，由他統管全部。例如：專案1可以由開發部做頭，專案2由實施部做頭。不固定，大家都有機會做頭。開發部經理和實施部經理，在專案啟動會上要求所有人必須全力為專案服務，聽從專案經理的安排。

至於互相不理解對方工作的問題，可這樣解決：
開發部門需要派人常住實施部，實施部反之也要派人常駐開發部。

至於這個問題：缺乏能統籌管理的專案經理角色
這個問題首先是授權的問題，這個專案經理不能統管開發和實施。授權到位，人才能往這個方向發展，統籌專案全域性的人很快就會誕生的了。
一般來說，開發的去熟悉實施，相對來說比較容易；實施要去懂寫程式碼，就比較難，但實施因為經常戰鬥在第一線，接觸客戶，他的優勢也是很明顯的。

開發部老大應該和實施部老大好好談談，再拉上上面的老大，三人一起談。梳理清楚關係，明確大家都要以公司利益為根本出發點。如果你們公司沒有什麼特殊的辦公室政治環境，應該可以解決這個問題。如果有特殊的一些辦公室政治關係，就不好說了，只能祝你好運

問題延伸：

戰鬥在第一線的，直接面對客戶的實施，他們的反饋往往是最有價值的，但往往得不到重視。而直接開發產品的部門，確經常躲在後面，不能直接面對需求和客戶。 

很多公司做大後，會按照軟體生命週期模型劃分若干個部門，例如：產品部（需求部）、研發部、質量部、實施部等，這些部門往往會將研發的過程切割為若干個上下游。成立這些部門的初衷是希望可以各環節做得更專業，但帶來的副作用就是各部門只看自己部門職責，沒有回到專案利益和公司利益為根本出發點，各部門協作成本大大提升等。 

強矩陣的部門架構才比較合適，專案小組成員來自不同部門，由專案經理統管，都需要為專案的成功負責。可惜很多公司採用的是弱矩陣架構，專案小組成員來自不同部門，各自對自己工作環節負責，沒有一個“大頭”來統管全域性。
--------------------- 
作者：張傳波 
來源：CSDN 
原文：https://blog.csdn.net/fireball1975/article/details/52814415 
版權宣告：本文為博主原創文章，轉載請附上博文連結！