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