純粹意義上的項(xiàng)目經(jīng)理是不用管技術(shù)的問題的,，只負(fù)責(zé)管理,，但是在一個中小公司可能出入就很大了，比如,，在我所在的公司,，項(xiàng)目經(jīng)理=客戶需求+項(xiàng)目管理+軟件架構(gòu)+程序編碼+部署+測試+項(xiàng)目驗(yàn)收,，如果需要的話也可以兼?zhèn)€DBA  ,還好，我以前的功底相對比較扎實(shí),，從linux到windows server到sqlserver 到oracle到j(luò)boss到websphere算不上精通也都基本能獨(dú)立搞定,，但要說效率有多高可能就不好說了.

我個人還是傾向于“分布式”，即各司其職,，有人設(shè)計(jì),，有人實(shí)現(xiàn)，有人管理,，有人維護(hù),，我還是欣賞我當(dāng)初參加工作時在北京網(wǎng)通小靈通賬務(wù)管理的項(xiàng)目中的人員分配的方式，現(xiàn)在想來還是比較合理,，在我們B/S組分配是：一名項(xiàng)目經(jīng)理,，主要負(fù)責(zé)總體和客戶的溝通，一名需求管理人員兼DBA,；一名技術(shù)經(jīng)理帶2 個后臺開發(fā)人員,；后臺開發(fā)人員各帶一名前臺開發(fā)人員；一名測試人員負(fù)責(zé)測試,，同時負(fù)責(zé)用戶平時的基本修改意見的匯總，如果有較大的變動則通過項(xiàng)目經(jīng)理,。而反觀我們現(xiàn)在的一些項(xiàng)目會發(fā)現(xiàn),，程序員居然和客戶溝通起來了，真是不怕天下大亂,，用戶A提一個問題,，程序員A修改了，過一段時間A又提一個問題給B,，B也修改了,，有一天程序員A和程序員B都走了，客戶覺得我的好多以前提的東西你們怎么現(xiàn)在的人都不知道??？雙方都受傷害。其實(shí),，合理的架構(gòu)才能保證有序的結(jié)果,，一個小打小鬧的團(tuán)隊(duì)怎么能應(yīng)付日益變化的客戶需求呢。

如果條件允許,，我建議一個具有競爭力的團(tuán)隊(duì)?wèi)?yīng)該是一名架構(gòu)設(shè)計(jì)人員,，一名DBA，3-5名中等水準(zhǔn)的開發(fā)人員,，一名美工,，一名測試，其中DBA和美工是共享人員，臨時參與,，測試放到一個更重要的位置,，即，始終跟蹤全部的客戶需求,，所有的修改變更都是通過測試人員,，程序員和客戶之間隔離開。其實(shí)這不就是“面向?qū)ο?#8221;么,？ 松耦合和緊耦合肯定不是一回事?，F(xiàn)在很多的公司的高層人員普遍比較短視，所謂的理由就是“成本”,，我的回答是：出來混遲早要還的,！現(xiàn)在不這么做，遲早要付出代價,。