//本站點內容來自于 顛覆軟件
純粹意義上的項目經理是不用管技術的問題的，只負責管理，但是在一個中小公司可能出入就很大了，比如，在我所在的公司，項目經理=客戶需求+項目管理+軟件架構+程序編碼+部署+測試+項目驗收，如果需要的話也可以兼個DBA 
,還好，我以前的功底相對比較扎實，從linux到windows server到sqlserver 到oracle到jboss到websphere算不上精通也都基本能獨立搞定，但要說效率有多高可能就不好說了.
我個人還是傾向于“分布式”，即各司其職，有人設計，有人實現，有人管理，有人維護，我還是欣賞我當初參加工作時在北京網通小靈通賬務管理的項目中
的人員分配的方式，現在想來還是比較合理，在我們B/S組分配是：一名項目經理，主要負責總體和客戶的溝通，一名需求管理人員兼DBA；一名技術經理帶2
個
后臺開發人員；后臺開發人員各帶一名前臺開發人員；一名測試人員負責測試，同時負責用戶平時的基本修改意見的匯總，如果有較大的變動則通過項目經理。而反
觀我們現在的一些項目會發現，程序員居然和客戶溝通起來了，真是不怕天下大亂，用戶A提一個問題，程序員A修改了，過一段時間A又提一個問題給B，B也修
改了，有一天程序員A和程序員B都走了，客戶覺得我的好多以前提的東西你們怎么現在的人都不知道啊？
雙方都受傷害。其實，合理的架構才能保證有序的結果，一個小打小鬧的團隊怎么能應付日益變化的客戶需求呢。
如果條件允許，我建議一個具有競爭力的團隊應該是一名架構設計人員，一名DBA，3-5名中等水準的開發人員，一名美工，一名測試，其中DBA和美
工是共享人員，臨時參與，測試放到一個更重要的位置，即，始終跟蹤全部的客戶需求，所有的修改變更都是通過測試人員，程序員和客戶之間隔離開。其實這不就
是“面向對象”么？ 松耦合和緊耦合肯定不是一回事。現在很多的公司的高層人員普遍比較短視，所謂的理由就是“成本”，我的回答是：出來混遲早要還的！
現在不這么做，遲早要付出代價。