你會(huì)常常因?yàn)樾枨笞兏婚_發(fā)測試吐槽，被抱怨研發(fā)管理流程規(guī)范太多，流程太復(fù)雜，被領(lǐng)導(dǎo)質(zhì)問為什么延期需求那么多嗎？對(duì)于產(chǎn)品經(jīng)理或是項(xiàng)目經(jīng)理來說，研發(fā)管理流程是極其繁瑣且難以規(guī)范化的工作，本篇文章將介紹大廠的B端產(chǎn)品研發(fā)管理流程以及管理中出現(xiàn)問題的解決方案。

一、研發(fā)管理流程

整個(gè)研發(fā)管理過程分為5個(gè)階段，需求階段，開發(fā)階段，測試階段，上線階段，驗(yàn)收階段，每個(gè)階段都有相應(yīng)的負(fù)責(zé)人，對(duì)階段內(nèi)的所有任務(wù)和節(jié)點(diǎn)的交付情況負(fù)責(zé)，保證節(jié)點(diǎn)正常推進(jìn)，而項(xiàng)目經(jīng)理則統(tǒng)籌起推進(jìn)全局的角色。

如果按照雙周發(fā)版的頻率，2次版本中間會(huì)有時(shí)間交叉，即上個(gè)版本的測試階段與下個(gè)版本的需求階段重合，這樣可以保證各個(gè)角色在每個(gè)階段都有工作任務(wù)，滿足快速迭代的要求。

1. 需求階段：產(chǎn)品經(jīng)理主導(dǎo)

• 產(chǎn)品經(jīng)理：評(píng)估并設(shè)計(jì)需求；提供需求清單；組織需求評(píng)審會(huì)，邀請(qǐng)開發(fā)測試參會(huì)
• 開發(fā)：評(píng)估本次版本需求可行性和工時(shí)，并輸出開發(fā)方案設(shè)計(jì)書（如有必要，組織需求反講會(huì)）
• 測試：評(píng)估本次版本需求工時(shí)
• 項(xiàng)目經(jīng)理：根據(jù)開發(fā)測試工作量確定需求排版情況

說明：整個(gè)需求階段會(huì)與上個(gè)版本的測試階段重合，測試人員工作重點(diǎn)會(huì)放在上個(gè)版本的測試工作上。

2. 開發(fā)階段：后端開發(fā)主導(dǎo)

• 產(chǎn)品經(jīng)理：對(duì)開發(fā)出現(xiàn)的問題進(jìn)行及時(shí)評(píng)估影響和重新設(shè)計(jì)方案
• 開發(fā)：進(jìn)行產(chǎn)品開發(fā)及自測，如有前后端交互的需求，需同時(shí)提供接口文檔，進(jìn)行前后端聯(lián)調(diào)
• 測試：根據(jù)需求說明文檔和開發(fā)設(shè)計(jì)文檔，輸出測試案例，并組織測試案例評(píng)審會(huì)
• 項(xiàng)目經(jīng)理：確保轉(zhuǎn)測節(jié)點(diǎn)正常推進(jìn)

3. 測試階段：測試主導(dǎo)

• 產(chǎn)品：上線前一天在UAT環(huán)境進(jìn)行測試，發(fā)送版本升級(jí)的客戶影響通知
• 開發(fā)：針對(duì)測試同學(xué)提出的bug進(jìn)行修復(fù)
• 測試：進(jìn)行功能測試，提出bug并修復(fù)跟進(jìn)，上線前一天進(jìn)行回收測試并發(fā)送測試報(bào)告
• 項(xiàng)目經(jīng)理：確保發(fā)版時(shí)間檢查完畢

4. 上線階段：運(yùn)維主導(dǎo)

• 開發(fā)：匯總產(chǎn)品變更內(nèi)容并提變更單
• 測試：發(fā)版上線后進(jìn)行正式環(huán)境生產(chǎn)驗(yàn)證
• 運(yùn)維：負(fù)責(zé)發(fā)版前置檢查，發(fā)版上線，上線后問題處理
• 項(xiàng)目經(jīng)理：跟進(jìn)發(fā)版進(jìn)度，對(duì)出現(xiàn)緊急問題及時(shí)處理

5. 驗(yàn)收階段：項(xiàng)目經(jīng)理主導(dǎo)

• 產(chǎn)品經(jīng)理：生產(chǎn)驗(yàn)收（只驗(yàn)收功能性的需求），客戶推廣及客戶培訓(xùn)
• 開發(fā)：如出現(xiàn)生產(chǎn)問題進(jìn)行問題修復(fù)
• 測試：總結(jié)bug原因
• 項(xiàng)目經(jīng)理：版本復(fù)盤，統(tǒng)計(jì)研發(fā)管理過程數(shù)據(jù)，如需緊急版本則負(fù)責(zé)版本的發(fā)起

該流程僅展示在整個(gè)版本流程中各交付節(jié)點(diǎn)及其對(duì)應(yīng)角色的產(chǎn)出物，針對(duì)其他工作事項(xiàng)例，如產(chǎn)品經(jīng)理進(jìn)行競品調(diào)研，客戶調(diào)研等工作不一一列舉。

二、發(fā)現(xiàn)問題：研發(fā)管理報(bào)告

建議在整個(gè)研發(fā)管理過程中，需要制定一些指標(biāo)來發(fā)現(xiàn)研發(fā)管理過程中出現(xiàn)的最多的問題和影響面最大的問題，由此制定規(guī)范，對(duì)癥下藥解決問題。

指標(biāo)1：不規(guī)范行為次數(shù)

統(tǒng)計(jì)在整個(gè)研發(fā)管理過程中各角色人員出現(xiàn)不遵守規(guī)范的次數(shù)與情況，進(jìn)行積分排名，獎(jiǎng)懲并行

指標(biāo)2：bug數(shù)據(jù)

統(tǒng)計(jì)上線前的bug數(shù)，上線后bug數(shù)，包括但不局限于占比，趨勢變化情況，并分析各類bug出現(xiàn)的根本原因和責(zé)任人

指標(biāo)3：需求延期情況

統(tǒng)計(jì)每個(gè)版本的需求延期情況和延期原因，并跟進(jìn)需求延期造成的影響，對(duì)影響大的需求進(jìn)行根本問題處理

指標(biāo)4：需求變更

統(tǒng)計(jì)每個(gè)版本的需求變更次數(shù)及原因，對(duì)占比對(duì)大的原因進(jìn)行整改

其他指標(biāo)：需求溢出率，自動(dòng)化測試覆蓋率，漏洞處理率，版本回退率，sonar掃描率等。

三、常見問題及處理

研發(fā)管理問題是任何公司任何部門都會(huì)出現(xiàn)，需要協(xié)作的部門就需要管理，其本質(zhì)是能力問題，惰性問題和合作問題，能力問題會(huì)導(dǎo)致需求質(zhì)量，開發(fā)質(zhì)量，測試質(zhì)量差，惰性問題會(huì)導(dǎo)致各種節(jié)點(diǎn)延期，信息不統(tǒng)一的問題，而合作問題則會(huì)出現(xiàn)溝通障礙，協(xié)調(diào)合作問題。

能力需要培訓(xùn)，而惰性需要通過規(guī)范和獎(jiǎng)懲結(jié)合。面對(duì)研發(fā)管理過程各類的問題，并非所有的問題都需要立即處理，在解決問題的同時(shí)也會(huì)帶來一些問題，重要的是要針對(duì)影響最大出現(xiàn)頻率最大的問題進(jìn)行針對(duì)性處理，同時(shí)要有獎(jiǎng)勵(lì)制度，在整個(gè)研發(fā)管理過程主要有如下幾類問題：

1. 需求變更

• 問題：產(chǎn)品隨意更改需求的內(nèi)容/邏輯或開發(fā)修改開發(fā)方案；需求變更未通知到需求的全部相關(guān)人員（特別是測試和前端）；需求說明文檔或開發(fā)設(shè)計(jì)文檔無統(tǒng)一放置，溝通內(nèi)容無正式記錄
• 影響：需求變更導(dǎo)致開發(fā)或測試工作量增大或有重復(fù)工作量；需求通知不到位導(dǎo)致各角色獲取信息有偏差，需求上線后發(fā)現(xiàn)前后端不一致，或必要的測試點(diǎn)未測試導(dǎo)致未發(fā)現(xiàn)bug
• 方案：嚴(yán)格規(guī)范需求變更規(guī)范，需由變更人提起申請(qǐng)，經(jīng)由相關(guān)的產(chǎn)品，開發(fā)，測試，項(xiàng)目經(jīng)理，領(lǐng)導(dǎo)知會(huì)及同意后才允許變更，并記錄變更原因。變更內(nèi)容要求正式記錄，不允許口頭通知或提供聊天記錄

2. 節(jié)點(diǎn)延期

• 問題：由于工作量評(píng)估有誤或個(gè)人能力問題或拖延心理導(dǎo)致產(chǎn)品提供需求方案延期，開發(fā)提供設(shè)計(jì)方案延期，開發(fā)轉(zhuǎn)測延期，測試提供測試報(bào)告延期，
• 影響：研發(fā)過程節(jié)點(diǎn)延期導(dǎo)致后續(xù)流程都出現(xiàn)風(fēng)險(xiǎn)，最后導(dǎo)致功能/產(chǎn)品延期，客戶滿意度下降
• 解決：規(guī)范節(jié)點(diǎn)延期需說明必要原因，并要求在延期一天后進(jìn)行撤版或執(zhí)行臨時(shí)方案，做好客戶通知與安撫工作

3. 無統(tǒng)籌人

• 問題：各個(gè)階段沒有對(duì)應(yīng)的統(tǒng)籌人，大家只負(fù)責(zé)自己部分的工作，缺少統(tǒng)籌
• 影響：零散無人管理，無法識(shí)別整體影響
• 解決：每個(gè)階段確定主負(fù)責(zé)人統(tǒng)籌推進(jìn)階段任務(wù)與交付情況，對(duì)節(jié)點(diǎn)交付物做檢驗(yàn)，針對(duì)出現(xiàn)問題主動(dòng)發(fā)起解決討論或會(huì)議

4. 測試質(zhì)量差

• 問題：開發(fā)自測質(zhì)量差，導(dǎo)致測試階段bug多；測試的測試案例有缺漏，測試覆蓋不全面，導(dǎo)致未發(fā)現(xiàn)bug
• 影響：開發(fā)修改bug占用開發(fā)時(shí)間，測試未發(fā)現(xiàn)bug導(dǎo)致上線有問題
• 解決：統(tǒng)計(jì)各類bug的數(shù)量及原因，針對(duì)主要原因進(jìn)行規(guī)范整改，例如統(tǒng)計(jì)開發(fā)bug數(shù)并計(jì)入KPI；測試需組織測試案例評(píng)審會(huì)，推進(jìn)使用自動(dòng)化工具提升測試覆蓋率

5. 研發(fā)管理規(guī)范遵守度低

• 問題：研發(fā)管理規(guī)范頻繁變更，一是適應(yīng)期會(huì)各角色還未養(yǎng)成習(xí)慣，二是存在僥幸心理和惰性心理，認(rèn)為犯錯(cuò)沒影響未遵守指定研發(fā)管理規(guī)范
• 影響：隨意違反研發(fā)管理規(guī)范，導(dǎo)致需求
• 解決：一是減少研發(fā)管理犯規(guī)變更次數(shù)，只針對(duì)重要問題，定期統(tǒng)一宣導(dǎo)并執(zhí)行管理規(guī)范；二是對(duì)于規(guī)范的遵守情況獎(jiǎng)懲并行，積分制規(guī)范管理嚴(yán)格化，對(duì)違反人員公示和處理

6. 缺少統(tǒng)一管理平臺(tái)

• 問題：一個(gè)需求的發(fā)起，開發(fā)，變更等步驟在多個(gè)平臺(tái)跟進(jìn)和處理；項(xiàng)目經(jīng)理需手工在不同平臺(tái)跟進(jìn)版本進(jìn)度或獲取研發(fā)管理數(shù)據(jù)
• 影響：多平臺(tái)操作導(dǎo)致工作效率降低，且容易遺漏部分環(huán)節(jié)導(dǎo)致需求風(fēng)險(xiǎn)
• 解決：盡量統(tǒng)一平臺(tái)管理和跟進(jìn)需求的各節(jié)點(diǎn)交付情況，并開發(fā)研發(fā)管理工具，自動(dòng)根據(jù)需求推進(jìn)情況獲取當(dāng)前交付情況

7. 人員沖突或工作安排不合理

• 問題：各板塊需求不平均，需求多的板塊的相關(guān)開發(fā)人員工作量多，其余工作量少，且出現(xiàn)緊急插單需求增加部分人員工作負(fù)擔(dān)
• 影響：工作量多的人需求未能按時(shí)完成，工作量少的人當(dāng)月無產(chǎn)出
• 解決：產(chǎn)品提出需求時(shí)盡量平衡安排各個(gè)板塊內(nèi)容；項(xiàng)目排版按照每個(gè)人員能在本次版本中能支持的工作量安排工作，包括緊急需求的工作量，不安排超過工作量的需求

8. 開發(fā)規(guī)范或文檔缺失

• 問題：缺失開發(fā)規(guī)范文檔，確實(shí)歷史的開發(fā)設(shè)計(jì)方案/需求設(shè)計(jì)方案
• 影響：缺少開發(fā)文檔導(dǎo)致開發(fā)方式不統(tǒng)一，后期系統(tǒng)架構(gòu)混論；開發(fā)設(shè)計(jì)方案和需求設(shè)計(jì)方案確實(shí)導(dǎo)致工作交接無法追溯歷史追溯，只能靠猜存在極大風(fēng)險(xiǎn)
• 解決：每次版本須輸出相關(guān)方案文檔，并規(guī)定在固定平臺(tái)統(tǒng)一放置，不斷沉淀歷史資料

好的研發(fā)管理能夠明顯提高一個(gè)團(tuán)隊(duì)工作效率，但每個(gè)部分都需要根據(jù)實(shí)際情況進(jìn)行適配性的管理，如果有興趣，可以更多的關(guān)注項(xiàng)目管理的框架例如scurm框架，或許你會(huì)發(fā)現(xiàn)研發(fā)管理沒那么難。

我是一個(gè)對(duì)世界充滿好奇的B端產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理不僅要懂方法論，而且學(xué)會(huì)把方法論運(yùn)用到實(shí)際中，大家有什么想了解也可以留言～

本文由 @? 素夏 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議