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