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