你會常常因為需求變更被開發測試吐槽，被抱怨研發管理流程規範太多，流程太複雜，被領導質問為什麼延期需求那麼多嗎？對于産品經理或是項目經理來說，研發管理流程是極其繁瑣且難以規範化的工作，本篇文章将介紹大廠的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端産品經理，産品經理不僅要懂方法論，而且學會把方法論運用到實際中，大家有什麼想了解也可以留言～

本文由 @

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部