多方協(xié)作研發(fā)項目管理

    最近應領(lǐng)導要求加入到一個(gè)進(jìn)行中的多方合作研發(fā)項目，項目涉及到公司標準產(chǎn)品、技術(shù)平臺框架、二次開(kāi)發(fā)以及客戶(hù)外包開(kāi)發(fā)業(yè)務(wù)四方的合作研發(fā)的項目，且技術(shù)平臺框架提供的WEB業(yè)務(wù)還處于新產(chǎn)品階段。整個(gè)項目面臨多方合作，技術(shù)攻堅等困難。項目進(jìn)展一個(gè)月，開(kāi)發(fā)進(jìn)度嚴重滯后，甚至連標準的測試和開(kāi)發(fā)環(huán)境都沒(méi)有搭建成功。由于業(yè)務(wù)依賴(lài)復雜，二次開(kāi)發(fā)和外包開(kāi)發(fā)必須依賴(lài)標準產(chǎn)品和技術(shù)平臺框架來(lái)進(jìn)行，技術(shù)平臺框架又處于新產(chǎn)品階段，不夠穩定，在開(kāi)發(fā)和測試環(huán)境中，即有標準產(chǎn)品出具的更新補丁，又有技術(shù)平臺開(kāi)發(fā)人員手工替換的jar包文件，腳本有的執行，有的沒(méi)有執行。安裝的補丁和替換的內容缺乏明細記錄，一旦發(fā)現問(wèn)題也很難確定是標準產(chǎn)品問(wèn)題、技術(shù)平臺問(wèn)題還是二次開(kāi)發(fā)或者外包開(kāi)發(fā)的代碼問(wèn)題，分析效率較為低下……。，開(kāi)發(fā)和測試人員甚至連一個(gè)穩定的環(huán)境都沒(méi)有，工作陷入困境。各方領(lǐng)導在人員上都給予了大力支持，但效果并不理想。抱怨的郵件一封接一封，但卻沒(méi)有有效的解決辦法。我參加了一次項目例會(huì )，并深入跟進(jìn)了項目一周的時(shí)間，大體上了解了項目存在的根結問(wèn)題，并采取了一系列的措施，經(jīng)過(guò)一個(gè)月的改變，項目終于走上正規，各項工作能夠有序有效的開(kāi)展。針對多方協(xié)作的研發(fā)項目總結了一些經(jīng)驗，在此分享。

　　多方協(xié)作研發(fā)項目存在的問(wèn)題：

　　1. 項目初期大多是人員的整合，卻不是項目的整合。牽扯的團隊多了，管理變得復雜，各團隊都注重各自任務(wù)的完成，而忽略了團隊間必要的協(xié)作，多一事不如少一事的心態(tài)較重。但當項目過(guò)程中各方工作產(chǎn)品相互交織和相互牽制的時(shí)侯就會(huì )暴露出嚴重的問(wèn)題。

　　2. 缺乏嚴謹的項目計劃和全面的風(fēng)險分析。多方協(xié)作研發(fā)的時(shí)侯，需要有經(jīng)驗的項目人員參與計劃的制定和風(fēng)險的分析，要考慮每個(gè)團隊的特點(diǎn)，并且結合項目可能存在的協(xié)作風(fēng)險。特別是在風(fēng)險暴露的時(shí)侯需要有效的風(fēng)險應對計劃和明細的解決策略。任何一個(gè)項目都具有不確定性，提前預知所有的問(wèn)題很難，但在項目過(guò)程中，需要有效的機制來(lái)保證項目的風(fēng)險的及時(shí)處理

　　3. 沒(méi)有規矩無(wú)以成方園，每個(gè)團隊有每個(gè)團隊的風(fēng)格，但同屬一個(gè)項目的時(shí)侯，必須有統一的游戲規則，項目管理就顯得尤為重要了，一份完善的《項目公約》是必不可少的，而且在前期對于規則的認識一致性非常重要，多在這方面花一些時(shí)間，在后期工作開(kāi)展的時(shí)侯就會(huì )少一些麻煩。

　　4. 多方協(xié)作的項目責任的劃分非常的重要，說(shuō)白了就是明確每個(gè)團隊要做哪些事，最后秋后算帳的時(shí)侯要找的到對應的責任人。多方協(xié)作常出現的一種現象就是踢皮球，不明確責任和義務(wù)，到時(shí)候就會(huì )陷入到混亂。責任和義務(wù)都明確清楚了，扯皮的事情也就少了，皮球也沒(méi)辦法踢了，工作才能順利的開(kāi)展。

　　5. 項目經(jīng)理，這個(gè)太重要了。在這里無(wú)法說(shuō)的很細節。項目管理的理論已經(jīng)很豐富了，關(guān)鍵是細節。項目經(jīng)理對于項目的了解和熟悉至關(guān)重要，不一定要是技術(shù)專(zhuān)家，但對基本的項目背景和業(yè)務(wù)復雜度有深入的認識，知道怎么去做才能改善。
    6. 最后想說(shuō)的，就是遇到問(wèn)題要思路清晰，找到解決問(wèn)題的方法和方案。大喊問(wèn)題很多沒(méi)用，大喊需要支持也沒(méi)用。

　　針對這個(gè)項目我采取的措施是(以下是我回復給項目組的郵件)：

　　從前期我們的過(guò)程來(lái)看，在測試環(huán)境以及產(chǎn)品質(zhì)量這兩塊存在較大的問(wèn)題，后續我們將嚴格規范相關(guān)工作，一切按照項目管理規范來(lái)做，對相關(guān)工作做重點(diǎn)說(shuō)明：

　　環(huán)境管理以及測試依據：

　　1. 從今天開(kāi)始，XX項目測試負責人為張小靜，測試服務(wù)器密碼將修改，補丁更新統一由張小靜負責處理

　　2. 開(kāi)發(fā)和測試環(huán)境明確規則，重新搭建標準的開(kāi)發(fā)和測試環(huán)境，環(huán)境部署為 標準產(chǎn)品+技術(shù)平臺框架+二次開(kāi)發(fā)業(yè)務(wù)+外包開(kāi)發(fā)業(yè)務(wù)

　　3. 日后所有的開(kāi)發(fā)內容(技術(shù)平臺補丁、標準產(chǎn)品補丁、外包開(kāi)發(fā)團隊的功能內容)必須以標準補丁的形式更新測試環(huán)境，進(jìn)行測試。不允許在測試服務(wù)器上進(jìn)行手工操作，包括腳本的執行。

　　4. 原則上每日更新補丁測試，開(kāi)發(fā)人員對于bug的修改每日構建，第二天更新補丁進(jìn)行測試。如有緊急需求，張小靜可以增加補丁更新的頻度，但不允許替換jar的形式更新。

　　5. 測試環(huán)境保持唯一性和準確性，所有的內容都以補丁形式進(jìn)行驗證

　　6. 每條項目任務(wù)的通過(guò)以項目管理工具中項目任務(wù)通過(guò)為標準，項目進(jìn)度以及項目質(zhì)量全部以項目管理工具數據為準。在開(kāi)發(fā)機上測試結果不能作為任務(wù)通過(guò)標準。

　　質(zhì)量保障缺陷處理機制：

　　1. 測試中發(fā)現的所有問(wèn)題都必須以bug的形式在項目管理工具中更新，無(wú)論是環(huán)境問(wèn)題、標準產(chǎn)品問(wèn)題、技術(shù)平臺問(wèn)題、二次開(kāi)發(fā)內容還是外包開(kāi)發(fā)內容

　　2. 所有的任務(wù)和缺陷修復開(kāi)發(fā)人員必須做好單元測試，單元測試必須執行測試用例的1級用例或執行30%的核心用例，減少中斷等影響測試開(kāi)展的重大錯誤。測試人員保障業(yè)務(wù)流程的有效測試。

　　3. 項目問(wèn)題分析和處理機制：首先標準產(chǎn)品研發(fā)人員進(jìn)行分析，標準產(chǎn)品確認無(wú)誤后，二次開(kāi)發(fā)人員對二次開(kāi)發(fā)內容進(jìn)行分析，確認無(wú)誤后外包團隊開(kāi)展問(wèn)題分析，只至分析出問(wèn)題的所屬團隊，由對應團隊成員第一時(shí)間處理。

　　4. 幾種BUG處理機制

　　1) 除重復bug外，其余bug一律不允許打回

　　2) 測試人員提交bug給開(kāi)發(fā)人員A，如該bug不屬于開(kāi)發(fā)人員A處理，不得打回，應將bug轉交給對應的開(kāi)發(fā)人員，如不清楚該bug對應的開(kāi)發(fā)人員，將bug轉發(fā)給項目經(jīng)理，由項目經(jīng)理轉交給對應的開(kāi)發(fā)處理人。

　　3) 測試人員提交bug給外包團隊開(kāi)發(fā)人員A，開(kāi)發(fā)人員A發(fā)現該bug屬于技術(shù)平臺或標準產(chǎn)品或二次開(kāi)發(fā)影響導致，不得將bug打回，將bug轉發(fā)給項目經(jīng)理，由項目經(jīng)理協(xié)調相關(guān)人員進(jìn)行修改，待bug處理解決以后，標記已改提交給測試人員驗證
    4) 測試人員提交bug給開(kāi)發(fā)人員，開(kāi)發(fā)人員發(fā)現該bug屬于測試環(huán)境問(wèn)題，不得將bug打回，而是需要分析測試環(huán)境為什么會(huì )存在問(wèn)題，并告知環(huán)境解決的方法，如果有問(wèn)題，可以申請相關(guān)人員協(xié)助，如果無(wú)法發(fā)現問(wèn)題，將bug提交給項目經(jīng)理，由協(xié)調資源處理，待問(wèn)題解決，將bug標記已改提交測試驗證

　　5) 對于技術(shù)上存在難度或認為bug無(wú)需處理，可將bug標記暫不處理，且必須注明暫不處理的原因，并提交項目經(jīng)理。由項目經(jīng)理和我共同決策該bug是否可以不處理。原則上只有人機交互和產(chǎn)品建議可以不處理，其他bug不允許不處理。

　　6) 開(kāi)發(fā)人員和測試人員遇到爭議問(wèn)題要進(jìn)行充分溝通，保證對于產(chǎn)品缺陷的一致性，提升bug修改的效率和質(zhì)量

　　7) 所有的bug逐條關(guān)聯(lián)項目任務(wù)，直接反應項目任務(wù)的開(kāi)發(fā)質(zhì)量

　　8) 對于bug，開(kāi)發(fā)和測試人員必須及時(shí)處理，原則上提交的bug開(kāi)發(fā)必須在3天內處理完畢，重大中斷、數據等缺陷必須在1天內處理完畢，測試人員必須在2天內保證bug的驗證通過(guò)。

　　進(jìn)度和質(zhì)量的衡量標準

　　1. 項目任務(wù)的完成進(jìn)度以項目管理工具數據作為唯一標準，以項目任務(wù)的通過(guò)率作為項目任務(wù)進(jìn)度數據

　　2. 功能質(zhì)量以項目管理工具完成情況為依據。測試通過(guò)的任務(wù)視為有質(zhì)量保證的任務(wù)，測試未通過(guò)的項目任務(wù)一律認為存在質(zhì)量問(wèn)題，不納入進(jìn)度數據。

                                                                              2010-2-26