你會常常因為需求變更被開發測試吐槽，被抱怨研發管理流程規范太多，流程太復雜，被領導質問為什么延期需求那么多嗎？對于產品經理或是項目經理來說，研發管理流程是極其繁瑣且難以規范化的工作，本篇文章將介紹大廠的B端產品研發管理流程以及管理中出現問題的解決方案。
一、研發管理流程
整個研發管理過程分為5個階段，需求階段，開發階段，測試階段，上線階段，驗收階段，每個階段都有相應的負責人，對階段內的所有任務和節點的交付情況負責，保證節點正常推進，而項目經理則統籌起推進全局的角色。
如果按照雙周發版的頻率，2次版本中間會有時間交叉，即上個版本的測試階段與下個版本的需求階段重合，這樣可以保證各個角色在每個階段都有工作任務，滿足快速迭代的要求。
1. 需求階段：產品經理主導
- 產品經理：評估并設計需求；提供需求清單；組織需求評審會，邀請開發測試參會
- 開發：評估本次版本需求可行性和工時，并輸出開發方案設計書（如有必要，組織需求反講會）
- 測試：評估本次版本需求工時
- 項目經理：根據開發測試工作量確定需求排版情況
說明：整個需求階段會與上個版本的測試階段重合，測試人員工作重點會放在上個版本的測試工作上。
2. 開發階段：后端開發主導
- 產品經理：對開發出現的問題進行及時評估影響和重新設計方案
- 開發：進行產品開發及自測，如有前后端交互的需求，需同時提供接口文檔，進行前后端聯調
- 測試：根據需求說明文檔和開發設計文檔，輸出測試案例，并組織測試案例評審會
- 項目經理：確保轉測節點正常推進
3. 測試階段：測試主導
- 產品：上線前一天在UAT環境進行測試，發送版本升級的客戶影響通知
- 開發：針對測試同學提出的bug進行修復
- 測試：進行功能測試，提出bug并修復跟進，上線前一天進行回收測試并發送測試報告
- 項目經理：確保發版時間檢查完畢
4. 上線階段：運維主導
- 開發：匯總產品變更內容并提變更單
- 測試：發版上線后進行正式環境生產驗證
- 運維：負責發版前置檢查，發版上線，上線后問題處理
- 項目經理：跟進發版進度，對出現緊急問題及時處理
5. 驗收階段：項目經理主導
- 產品經理：生產驗收（只驗收功能性的需求），客戶推廣及客戶培訓
- 開發：如出現生產問題進行問題修復
- 測試：總結bug原因
- 項目經理：版本復盤，統計研發管理過程數據，如需緊急版本則負責版本的發起
該流程僅展示在整個版本流程中各交付節點及其對應角色的產出物，針對其他工作事項例，如產品經理進行競品調研，客戶調研等工作不一一列舉。
二、發現問題：研發管理報告
建議在整個研發管理過程中，需要制定一些指標來發現研發管理過程中出現的最多的問題和影響面最大的問題，由此制定規范，對癥下藥解決問題。
指標1：不規范行為次數
統計在整個研發管理過程中各角色人員出現不遵守規范的次數與情況，進行積分排名，獎懲并行
指標2：bug數據
統計上線前的bug數，上線后bug數，包括但不局限于占比，趨勢變化情況，并分析各類bug出現的根本原因和責任人
指標3：需求延期情況
統計每個版本的需求延期情況和延期原因，并跟進需求延期造成的影響，對影響大的需求進行根本問題處理
指標4：需求變更
統計每個版本的需求變更次數及原因，對占比對大的原因進行整改
其他指標：需求溢出率，自動化測試覆蓋率，漏洞處理率，版本回退率，sonar掃描率等。
三、常見問題及處理
研發管理問題是任何公司任何部門都會出現，需要協作的部門就需要管理，其本質是能力問題，惰性問題和合作問題，能力問題會導致需求質量，開發質量，測試質量差，惰性問題會導致各種節點延期，信息不統一的問題，而合作問題則會出現溝通障礙，協調合作問題。
能力需要培訓，而惰性需要通過規范和獎懲結合。面對研發管理過程各類的問題，并非所有的問題都需要立即處理，在解決問題的同時也會帶來一些問題，重要的是要針對影響最大出現頻率最大的問題進行針對性處理，同時要有獎勵制度，在整個研發管理過程主要有如下幾類問題：
1. 需求變更
- 問題：產品隨意更改需求的內容/邏輯或開發修改開發方案；需求變更未通知到需求的全部相關人員（特別是測試和前端）；需求說明文檔或開發設計文檔無統一放置，溝通內容無正式記錄
- 影響：需求變更導致開發或測試工作量增大或有重復工作量；需求通知不到位導致各角色獲取信息有偏差，需求上線后發現前后端不一致，或必要的測試點未測試導致未發現bug
- 方案：嚴格規范需求變更規范，需由變更人提起申請，經由相關的產品，開發，測試，項目經理，領導知會及同意后才允許變更，并記錄變更原因。變更內容要求正式記錄，不允許口頭通知或提供聊天記錄
2. 節點延期
- 問題：由于工作量評估有誤或個人能力問題或拖延心理導致產品提供需求方案延期，開發提供設計方案延期，開發轉測延期，測試提供測試報告延期，
- 影響：研發過程節點延期導致后續流程都出現風險，最后導致功能/產品延期，客戶滿意度下降
- 解決：規范節點延期需說明必要原因，并要求在延期一天后進行撤版或執行臨時方案，做好客戶通知與安撫工作
3. 無統籌人
- 問題：各個階段沒有對應的統籌人，大家只負責自己部分的工作，缺少統籌
- 影響：零散無人管理，無法識別整體影響
- 解決：每個階段確定主負責人統籌推進階段任務與交付情況，對節點交付物做檢驗，針對出現問題主動發起解決討論或會議
4. 測試質量差
- 問題：開發自測質量差，導致測試階段bug多；測試的測試案例有缺漏，測試覆蓋不全面，導致未發現bug
- 影響：開發修改bug占用開發時間，測試未發現bug導致上線有問題
- 解決：統計各類bug的數量及原因，針對主要原因進行規范整改，例如統計開發bug數并計入KPI；測試需組織測試案例評審會，推進使用自動化工具提升測試覆蓋率
5. 研發管理規范遵守度低
- 問題：研發管理規范頻繁變更，一是適應期會各角色還未養成習慣，二是存在僥幸心理和惰性心理，認為犯錯沒影響未遵守指定研發管理規范
- 影響：隨意違反研發管理規范，導致需求
- 解決：一是減少研發管理犯規變更次數，只針對重要問題，定期統一宣導并執行管理規范；二是對于規范的遵守情況獎懲并行，積分制規范管理嚴格化，對違反人員公示和處理
6. 缺少統一管理平臺
- 問題：一個需求的發起，開發，變更等步驟在多個平臺跟進和處理；項目經理需手工在不同平臺跟進版本進度或獲取研發管理數據
- 影響：多平臺操作導致工作效率降低，且容易遺漏部分環節導致需求風險
- 解決：盡量統一平臺管理和跟進需求的各節點交付情況，并開發研發管理工具，自動根據需求推進情況獲取當前交付情況
7. 人員沖突或工作安排不合理
- 問題：各板塊需求不平均，需求多的板塊的相關開發人員工作量多，其余工作量少，且出現緊急插單需求增加部分人員工作負擔
- 影響：工作量多的人需求未能按時完成，工作量少的人當月無產出
- 解決：產品提出需求時盡量平衡安排各個板塊內容；項目排版按照每個人員能在本次版本中能支持的工作量安排工作，包括緊急需求的工作量，不安排超過工作量的需求
8. 開發規范或文檔缺失
- 問題：缺失開發規范文檔，確實歷史的開發設計方案/需求設計方案
- 影響：缺少開發文檔導致開發方式不統一，后期系統架構混論；開發設計方案和需求設計方案確實導致工作交接無法追溯歷史追溯，只能靠猜存在極大風險
- 解決：每次版本須輸出相關方案文檔，并規定在固定平臺統一放置，不斷沉淀歷史資料
好的研發管理能夠明顯提高一個團隊工作效率，但每個部分都需要根據實際情況進行適配性的管理，如果有興趣，可以更多的關注項目管理的框架例如scurm框架，或許你會發現研發管理沒那么難。
我是一個對世界充滿好奇的B端產品經理，產品經理不僅要懂方法論，而且學會把方法論運用到實際中，大家有什么想了解也可以留言～
本文由 @?? 素夏 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。