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