項目研發管理流程

以前公司我除了帶架構和業務研發團隊，PMO也在我這邊管理，對於200多人的研發團隊，下面介紹下整個研發管理流程，瀑布式開發模式，雖然比較慢，不過很穩，適合傳統企業。

一、立項階段

發起人提出需求（公司領導/客戶等）、產品自身需求，產品部收到發起人通知或自身規劃需求後，作相應的競品分析、市場分析等評估工做，通過評估後，如須要以項目的形式繼續往下實施，則安排填寫《項目立項申請表》，並走流程進行確認，項目發起人通常是公司領導或來自客戶。

二、需求階段

MRD

項目立項後，產品部進入需求收集、分析、篩選、整理等工做，產品部輸出需求範圍或其它產品規劃文檔，需求範圍需同項目干係人進行討論、肯定，並最終由sponsor確認，需求範圍需體現是否會涉及到第三方或公司內部其餘部門（如財務、運營、客服等）的業務，需求範圍獲得明確後，將進入後續的產品設計階段。

PRD

根據需求範圍，原型設計編寫產品需求文檔及其它附屬文檔等，產品需求文檔產生後，召集相關部門對產品需求進行評審，產品需求文檔內容需包含（但不限於）以下部分：

★ 功能需求是否覆蓋

★ 性能需求是否覆蓋

★ 數據需求是否覆蓋

★ 監控需求是否覆蓋

★ 適配範圍需求

★ 新老平臺/系統的兼容性要求

★ 周邊系統的影響評估

★ 安全需求

★ 系統容量/併發需求

原型設計

根據需求範圍，對產品進行設計，並輸出產品原型，產品原型設計產生後，須召集相關部門進行評審，可與產品需求文檔PRD一塊兒進行評審，評審過程需造成會議紀要，評審經過後，將正式原型歸檔。

三、規劃階段

在項目正式啓動前，項目經理須要作一些項目前期規劃工做，規劃的內容和範圍主要包含：

Ø資源評估及規劃

Ø項目風險評估和管理計劃

Ø項目估時及時間計劃表

Ø項目Check List生成

資源評估及規劃

項目經理組織對項目的資源進行評估和規劃，項目資源主要包含內容以下：

★ 開發資源/工具規劃確認

★ 測試資源/工具規劃確認

★ 生產環境資源規劃確認

項目風險評估及管理計劃

項目經理組織項目組成員對項目的風險進行識別和評估，項目風險主要包含技術風險、資源風險、溝通風險、環境風險等，引導項目組採用頭腦風暴等方式，對風險進行識別，並對其嚴重程度及影響面進行評估，以綜合評估風險指數，針對識別出來的風險，須要給出相應的預防措施，以防變成問題，將風險降到最低點，最終生成風險評估及管理計劃，由項目經理實時跟進，並按期更新和維護風險管理計劃表。

項目估時及時間計劃表

項目經理召集相關研發經理、團隊成員進行計劃估時及制定，研發人員須要配合項目經理進行任務的分解和評估，同時對開發時間進行評估（估算的時間要儘可能確保合理），評估的時間粒度原則上能讓項目經理可有效的進行任務跟蹤，具體的粒度由項目經理根據項目實際狀況進行把握（按照國內的項目管理慣例，通常狀況下，最小粒度但願能細到1天，最長不能超過3天。）項目計劃所包含的維度需包含（但不限於）：

★ MRD

★ PRD

★ 研發設計

★ 編碼

★ 自測

★ 聯調

★ 測試

★ 驗收

★ 上線

★ 結項

項目經理根據開發、測試等部門評估的計劃，整理出整個項目計劃，做爲項目正式啓動的重要輸入之一。

項目正式啓動

項目規劃階段工做就緒後，項目經理髮起會議並召集項目組全部人員進行正式啓動會議，會議主要明確內容以下：

① 項目計劃同步和肯定

② 資源及人員職責的明確和肯定

③ 當前風險評估及管理表的宣講

④ 對項目目標的同步和明確

會議結束後，項目經理將以上4項明確後的結論作最終整理，並將其相關文檔提交到SVN上進行統一管理。

四、設計階段

技術調研

針對產品規劃過程當中所提出的技術風險、難題進行前期技術調研，技術調研要有必定的深度，評測結果要真實可信，其餘來源的數據僅能做爲參考，要以本身的測試結果爲主，調研工做結束後，需編寫《技術調研報告》，報告中要給出調研技術的分析和建議結論，調研過程當中涉及到相關的代碼和demo，須要在《技術調研報告》中體現，並說明具體放置的路徑，研報告輸出後，安排項目組相關人員對調研結果進行評審。

技術方案設計

開發人員根據產品需求文檔進行系統模塊的劃分和分解，分模塊進行系統分析，各個模塊的系統分析完成後，須要編寫《詳細設計文檔》、《數據庫設計文檔》等，各子系統間的交互須要編寫《系統內部接口文檔》，如本系統與其餘系統有交互，須要編寫《系統接口文檔》，針對《詳細設計文檔》、《系統接口文檔》及《數據庫設計文檔》需召集項目經理、產品經理、開發人員、測試人員等進行評審，詳細設計文檔包含（但不限於）如下內容：

★ 系統架構

★ 系統各模塊分解及功能說明

★ 各系統之間的關係及如何調用

★ 其餘部門的合做對接方案

★ 數據平滑遷移方案設計

★ 安全方案等

詳細設計文檔需以部門或系統爲單位，整合成一份文檔輸出，避免一個項目N份設計文檔。

測試用例設計及評審

測試人員根據產品需求文檔、詳細設計文檔進行測試用例的編寫和分解， 測試用例編寫完成後，須要組織相關人員進行評審，並輸出評審報告，測試用例的設計在實際項目操做過程當中，可能也會在產品設計階段確認以後就開始。

UI設計及評審

UI設計師根據產品原型、產品需求文檔對UI進行設計，UI設計稿，需同業務方、產品、開發等相關干係人進行評審，原則上產品經理對設計稿上功能、流程是否知足進行負責，設計師對設計稿上的外觀、審美進行負責，評審經過後，進行定稿並正式提交。

五、研發階段

編碼 

代碼格式須遵守《Java代碼編寫規範》等規範書寫，代碼需確保編譯經過，並天天入庫一次，代碼入庫前必須完成Code Review，在代碼編寫階段，須要嚴格按照項目計劃執行，並確保代碼質量。

單元測試

在代碼實現過程當中，需保證在一個迭代週期內完成單元測試（迭代週期視項目具體狀況而定），在一個迭代週期結束前，入庫的代碼需包含相應的單元測試代碼，單元測試代碼入庫前原則上也必須進行Code Reviewer，單元測試的最終結果是保證迭代週期內的代碼測試經過，以確保入庫代碼的質量。

聯調

在編碼及單元測試完成後，項目進入聯調階段工做，聯調工做主要包含：

★ 子系統間接口、功能聯調

★ 本系統與其它系統間的接口、功能聯調

聯調需確保各子系統間或相互調用的系統之間接口調通，正常流程的功能實現正常，爲後續測試奠基良好的基礎。

提測

聯調經過後，開發人員將代碼提交到指定的服務器地址，開發人員需填寫《xxx項目提測申請單》， 郵件提交給測試相關人員，版本提交申請單需包含如下內容：

★ 項目名及版本號

★ 聯調結果

★ 代碼的具體地址（包含SVN地址及SVN版本號）

★ 新增/修改的功能/bugs 清單及功能自測結果

六、測試階段

冒煙測試

測試部接收到版本後，安排進行冒煙測試，冒煙測試在測試環境上進行，冒煙測試過程當中，若是發現重大問題，導致測試沒法進行下去的，須要及時將問題highlight給項目經理及開發部，開發部需第一時間安排優先處理問題，直到冒煙測試經過。

系統測試

測試負責人對任務進行分解到每位測試人員，並確保每條用例到具體負責人，測試人員收到測試版本及測試任務後，進行測試工做，測試人員的工做需按照項目計劃進行，如出現與項目計劃不符的，需及時提出，並與測試負責人及項目經理進行溝通，測試過程當中發現的bug提交及具體操做，請按照JIRA系統操做流程執行，測試過程當中，若是碰到嚴重問題而形成正常測試沒法進行的，需第一時間highlight出來給開發和項目經理，開發接到問題後需第一時間安排分析解決。測試負責人須要天天反饋測試進展狀況，並輸出項目測試日報。

測試報告評審

項目經理收到測試部發出的系統測試總結報告後，結合實際狀況，發起測試報告評審的會議，會議評審內容主要包含測試報告的內容及JIRA中的bug list。

測試報告評審的原則：

★ 針對N/A的部分須要說明具體緣由，並確認當前是否確實沒法測試；

★ Fail項是否都已提交到JIRA系統中進行管理。

Bug List評審原則：

★ 須要對每一個bug的最新狀態做確認；

★ 逐一討論bug，對每一個bug須要分析其嚴重程度、解決的優先級；

★ 每一個bug須要明確具體的負責人和解決時間點；

★ 對一些bug暫時不須要解決的（如需求不明確或嚴重程度低的），可作「掛起」處理。但過後須要特別對「掛起」問題，從新進行分析、討論，做爲後期完善、優化的一部份內容；

★ 針對「爭議」類的bug須要項目組作特別討論，並給出處理的結論。

根據評審完的報告和bug list，須要進一步明確下階段版本更新、系統測試的時間點以及測試範圍，根據評審的結果，項目組肯定版本是否可達到上線標準。

開發debug

開發人員須要主動查看分配給本身的Bug，並及時更新Bug狀態，開發在解決完bug後，要及時更新bug狀態，並對已解決bug註釋緣由及解決方案，針對Bug修改的代碼提交時，原則上不容許如下狀況：

★ 一次提交代碼中包含多個Bug修改；

★ 一次提交代碼中即包含Bug修改，又包含其餘功能的開發代碼。

七、驗收階段

產品驗收

當測試經過後，在提交上線申請前，產品經理需對產品進行驗收工做，驗收工做結束後，需輸出驗收報告，並在驗收報告中給出是否經過等結論，將產品驗收報告同步給項目組相關干係人。

八、上線階段

上線準備會

項目經理召集開發、產品、測試、運維等相關部門進行上線前準備會議，會議內容主要包含（但不限於）如下內容：

★上線前的上線方案是否準備完備

★上線的具體時間肯定

★上線的相關事項準備

★上線check list覈對

★上線人員肯定

★風險評估等

上線部署申請

指定的研發負責人在工單系統上發佈上線申請；審批經過後方可進行項目上線工做。

部署上線

上線申請單審批經過後，進行上線工做，上線結束後，運維人員須要驗證系統是否能正常運行，確保上線成功，上線結束後，上線人員須要將上線結果通知相關人員。

線上驗證

測試部門須要提早準備驗證測試的測試方案和測試用例，測試部門收到上線成功通知後，啓動線上驗證，線上驗證過程當中若是發現問題，須要及時將問題通知給項目經理、開發人員及運維人員等，項目經理獲得通知後需第一時間召集項目組相關人員進行討論，以肯定後面工做的安排，線上驗證經過後，測試部門需輸出線上驗證是否經過的郵件，周知項目組相關人員。

九、收尾階段

結項

當上線成功及系統穩定後，項目經理須安排項目組全部成員進行項目總結會，項目總結會，每一個項目組成員都須參與並積極發言，會議主要內容包含三大部分：

★ 從項目中獲得哪些收穫

★ 項目運行過程當中碰到問題及改進意見

★ 對後期項目指望是什麼

項目經理須要對會議內容進行總結，做爲項目的組織過程資產，以做爲後續項目的借鑑和經驗教訓，針對暴露問題的措施或解決方案，將其落實並完善項目管理體系，並更新項目管理流程及相應的模板，以PDCA閉合管理，需檢查項目在運行過程當中全部過程文檔及產出物是否已正式入庫。

須要資料的同窗關注我公號，聯繫做者。