最近應領導要求加入到一個進行中的多方合作研發(fā)項目，項目涉及到公司標準產(chǎn)品、技術平臺框架、二次開發(fā)以及客戶外包開發(fā)業(yè)務四方的合作研發(fā)的項目，且技術平臺框架提供的WEB業(yè)務還處于新產(chǎn)品階段。整個項目面臨多方合作，技術攻堅等困難。項目進展一個月，開發(fā)進度嚴重滯后，甚至連標準的測試和開發(fā)環(huán)境都沒有搭建成功。由于業(yè)務依賴復雜，二次開發(fā)和外包開發(fā)必須依賴標準產(chǎn)品和技術平臺框架來進行，技術平臺框架又處于新產(chǎn)品階段，不夠穩(wěn)定，在開發(fā)和測試環(huán)境中，即有標準產(chǎn)品出具的更新補丁，又有技術平臺開發(fā)人員手工替換的jar包文件，腳本有的執(zhí)行，有的沒有執(zhí)行。安裝的補丁和替換的內(nèi)容缺乏明細記錄，一旦發(fā)現(xiàn)問題也很難確定是標準產(chǎn)品問題、技術平臺問題還是二次開發(fā)或者外包開發(fā)的代碼問題，分析效率較為低下……。，開發(fā)和測試人員甚至連一個穩(wěn)定的環(huán)境都沒有，工作陷入困境。各方領導在人員上都給予了大力支持，但效果并不理想。抱怨的郵件一封接一封，但卻沒有有效的解決辦法。我參加了一次項目例會，并深入跟進了項目一周的時間，大體上了解了項目存在的根結問題，并采取了一系列的措施，經(jīng)過一個月的改變，項目終于走上正規(guī)，各項工作能夠有序有效的開展。針對多方協(xié)作的研發(fā)項目總結了一些經(jīng)驗，在此分享。
多方協(xié)作研發(fā)項目存在的問題：
1. 項目初期大多是人員的整合，卻不是項目的整合。牽扯的團隊多了，管理變得復雜，各團隊都注重各自任務的完成，而忽略了團隊間必要的協(xié)作，多一事不如少一事的心態(tài)較重。但當項目過程中各方工作產(chǎn)品相互交織和相互牽制的時侯就會暴露出嚴重的問題。
2. 缺乏嚴謹?shù)捻椖坑媱澓腿娴娘L險分析。多方協(xié)作研發(fā)的時侯，需要有經(jīng)驗的項目人員參與計劃的制定和風險的分析，要考慮每個團隊的特點，并且結合項目可能存在的協(xié)作風險。特別是在風險暴露的時侯需要有效的風險應對計劃和明細的解決策略。任何一個項目都具有不確定性，提前預知所有的問題很難，但在項目過程中，需要有效的機制來保證項目的風險的及時處理
3. 沒有規(guī)矩無以成方園，每個團隊有每個團隊的風格，但同屬一個項目的時侯，必須有統(tǒng)一的游戲規(guī)則，項目管理就顯得尤為重要了，一份完善的《項目公約》是必不可少的，而且在前期對于規(guī)則的認識一致性非常重要，多在這方面花一些時間，在后期工作開展的時侯就會少一些麻煩。
4. 多方協(xié)作的項目責任的劃分非常的重要，說白了就是明確每個團隊要做哪些事，最后秋后算帳的時侯要找的到對應的責任人。多方協(xié)作常出現(xiàn)的一種現(xiàn)象就是踢皮球，不明確責任和義務，到時候就會陷入到混亂。責任和義務都明確清楚了，扯皮的事情也就少了，皮球也沒辦法踢了，工作才能順利的開展。
5. 項目經(jīng)理，這個太重要了。在這里無法說的很細節(jié)。項目管理的理論已經(jīng)很豐富了，關鍵是細節(jié)。項目經(jīng)理對于項目的了解和熟悉至關重要，不一定要是技術專家，但對基本的項目背景和業(yè)務復雜度有深入的認識，知道怎么去做才能改善。
6. 最后想說的，就是遇到問題要思路清晰，找到解決問題的方法和方案。大喊問題很多沒用，大喊需要支持也沒用。
針對這個項目我采取的措施是(以下是我回復給項目組的郵件)：
從前期我們的過程來看，在測試環(huán)境以及產(chǎn)品質(zhì)量這兩塊存在較大的問題，后續(xù)我們將嚴格規(guī)范相關工作，一切按照項目管理規(guī)范來做，對相關工作做重點說明：
環(huán)境管理以及測試依據(jù)：
1. 從今天開始，XX項目測試負責人為張小靜，測試服務器密碼將修改，補丁更新統(tǒng)一由張小靜負責處理
2. 開發(fā)和測試環(huán)境明確規(guī)則，重新搭建標準的開發(fā)和測試環(huán)境，環(huán)境部署為 標準產(chǎn)品+技術平臺框架