很多公司研發的產品，由於缺乏規范化、標準化的流程，導致在產品整個研發生命周期過程中，出現各種各樣的問題，比如：需求隨意變更，研發質量差、版本延期，這些問題嚴重的影響瞭研發各項工作的正常開展。因此，我們需要規范研發流程，通過標準化的流程來指導研發成員工作，從而更好地達成研發目標。
- 意義范圍
1 規范流程的范圍
規范流程的范圍以研發部日常工作為主，主要包含需求對接、技術評審、代碼規范、Bug管理、腳本管理、發佈流程、數據庫安全保障、團隊管理、成員管理、績效考核等。
2 規范流程的意義
（1）可以指導成員開展工作，讓大傢很清楚地知道自己要做哪些工作，該怎麼去做這些工作，減少大傢工作中的個人主觀隨意性。
（2）可以讓新成員通過短暫的培訓學習，快速融入工作中。
（3）便於研發管理人員對成員的日常管理和考核。
（4）可以加深新成員對部門的認同感。
（5）可以沉淀下來作為部門的工作指導。
明確瞭規范流程的意義和范圍以後，那我們在日常工作過程中遇到各類問題，就可以很清晰地知道各個問題該采用哪種方案去應對和處理。
當遇到的問題，隻要符合我們規范流程范圍和意義中的任一條，這類問題就可以統一通過編寫規范流程來處理，避免今後再出現類似問題。一般像這類問題都是周期性的或者經常需要重復進行的，需要規范流程來加以約束與指導；比如：研發部各個端口的開發成員，他們代碼書寫不統一的問題；測試人員提交提交Bug不規范的問題等等,這些都是經常需要重復進行的操作，這類問題，我們可以通過制定規范流程來指導大傢。
當遇到的問題，不滿足我們規范流程范圍和意義中的任一條，這類問題可以直接修復並處理，沒有必要編寫規范流程文檔。一般像這類問題都是非周期性或非重復進行的問題，問題影響都是一時的，短暫的，發現問題第一時間修復即可。比如用戶反饋生產環境訂單無法指派；生產環境訂單導出報錯等等，這類問題，隻對當時反饋的問題產生個別影響，我們可以第一時間解決該問題，消除影響。
- 制作過程
一份好的規范流程，從梳理、編寫、宣貫到最後使用，需要認真推演。結合我們研發部實際輸出規范流程的整個制作過程，主要可以分為以下5個環節。
1 梳理問題
在梳理問題的過程中，主要從問題來源、分析過程兩個方面入手。
1.1問題來源
梳理問題的來源主要來自以下幾個方面：
- 研發內部工作開展，團隊配合中遇到的問題。
- 與其他兄弟部門合作過程中遇到的問題。
- Bug反饋群，業務部門直接反饋過來的問題。
- 研發部內部定期工作復盤發現的問題。
- 運維工作中反饋的問題。
- 測試每個月定期線上回歸測試發現的問題等。
1.2分析過程
問題分析過程，主要分為以下幾步：
- 問題收集人收集研發部工作過程中遇到的各類問題。
問題收集模板：
- 問題收集人將收集到的相關問題，以郵件的形式反饋給研發部管理層相關人員，征詢大傢的意見，是否需要制定規范流程。
- 研發部管理層依據規范流程的范圍跟意義，篩選反饋的問題。當符合我們梳理的范圍和意義時的問題，問題收集人需記錄這些問題，後續專門開會討論解決方案。
- 針對需要制定規范流程的問題，以管理層周例會、骨幹討論會議或召集問題相關人員開會的方式，大傢一起針對需要制定規范流程的問題，進行分析討論，給出初步解決方案。
2 討論解決方案
- 針對梳理出來的問題，研發部負責人組織研發骨幹召開會議進行問題討論，同時指定一名會議記錄人。
- 各骨幹針對問題解決方案提出各自的意見，大傢進行頭腦風暴，會議記錄人紀要大傢提出的意見。
- 會議記錄人結合大傢的建議，輸出一份問題解決方案，並郵件發給相關參會人員。
3 編寫規范流程
（1）部門負責人根據討論的解決方案，安排負責該工作的對應管理成員，制定出相應的規范流程，避免下次再出現類似的問題。
（2）規范流程負責人，根據之前討論得出的結論，開始著手編寫對應的規范流程文檔，當編寫完後，提交研發部管理層進行review審議。
（3）審議過程中，各成員提交各自的建議，規范流程負責人記錄大傢的建議後，再次修改。
- 規范流程負責人修改後，再次提交審議，審議通過後，郵件發給相關參會人員。
4 宣貫規范流程
- 規范流程負責人跟研發部全體成員，宣貫規范流程。
- 針對宣貫過程中成員提出的問題做答疑，同時記錄成員反饋的問題和建議。
- 經過采納的合理建議和方案，規范流程負責人需及時更新到規范流程文檔中，並將最終更新後的規范文檔郵件發給研發部全體成員。
5 觀察迭代
- 規范流程負責人需每周跟進規范流程運行的效果，收集各成員反饋的問題。
- 前3個月每個月末流程負責人需郵件反饋給流程實施結果，流程是否有不足和改進的地方，是否需要迭代。
- 流程負責人根據運行的結果反饋，修正規范流程文檔。
- 研發部管理層review審議規范流程，審議通過後，正式執行該規范；當審議不通過的時候，負責人需根據審議結果重新修改文檔。
- 規范流程負責人再次在研發部內部宣貫該規范流程。
- 研發部所有成員按照迭代後的規范流程開展相應工作。
- 具體參考
下面結合規范流程的制作過程，詳細介紹一下我們實際輸出規范流程的示例。
1 梳理問題階段
日常研發工作過程中，我們發現技術產品部和我們在需求對接過程中，經常存在非標操作，產品經理有需求經常直接私下跟對應的開發人員口頭溝通，也沒有書面的需求郵件，開發人員修復好以後，直接通知測試人員發佈上線，導致線上系統經常出現問題，且項目經理也不清楚這些需求，無法把控項目風險；
問題收集人針對這種情況，收集的問題列表如下：
根據梳理出來的這個問題後，大傢一致認為符合制定規范流程的范圍和意義，接下來我們組織研發部骨幹全體成員以及技術部對應的產品經理召開會議，一起溝通討論該問題，給出初步解決方案。
大傢給出的建議，如下：
2 討論解決方案階段
- 梳理清楚對接存在的非標問題後，研發部負責人專門組織研發骨幹召開會議進行問題詳細討論，同時根據問題的所屬責任人，安排項目經理作為會議記錄人；
- 大傢在討論的過程中，給出各自的建議，會議記錄人詳細記錄每個人給出的建議，如下：
3 編寫規范流程
項目經理結合大傢溝通討論的建議，開始著手編寫《研發與技術產品部需求對接流程制度》規范文檔；
4 宣貫規范流程
待研發部管理層審議通過後，項目經理跟研發部全體成員，宣貫《研發與技術產品部需求對接流程制度》規范文檔；
5 觀察迭代
項目經理觀察&收集規范流程實際使用過程中遇到的問題，發現實際執行過程中，還缺少瞭UI設計工作的規范，研發人員跟UI的對接很被動，經常要等待UI設計師給相關切圖，而不是在開發之前就及時交付給我們研發人員，從而影響開發進度；
迭代中發現的問題：
項目經理根據迭代發現的問題，重新完善《研發與技術產品部需求對接流程制度》規范文檔，最終我們輸出瞭下面一份詳細的規范流程文檔。
研發與技術產品對接流程制度 V1.1
目的
規范研發體系內，技術產品、UE/UI設計和研發的工作流程。
適用范圍
適用對象：
1、技術產品部：
技術產品經理、UE/UI設計師
2、研發部：
研發經理、研發工程師、測試工程師
需求分類：
1、 模塊化需求
模塊化或緊密相關聯的產品需求，通常有長期規劃，一般設為KPI
2、零碎迭代需求
小范圍迭代優化類需求，做為模塊化需求的補充需求或從各部門收集到操作層面的優化建議類需求，一般不設為KPI
原則
1、需求提交原則
模塊化需求，必須召開技術評審會，並通過技術評審，且有詳細的需求文檔
零碎迭代需求，必須通過釘釘-簡道雲/郵件提交，通過產品分析再流轉至研發
BUG，直接向研發部反饋
2、需求評估原則
需求目的與公司發展戰略相匹配
優先級跟隨公司發展節奏
產品方案綜合考慮研發成本ROI
產品方案是否符合技術實現邏輯
*研發部依據本原則進行需求評估，若不符合原則，研發部有權將需求駁回。
流程及要求
1、模塊化需求
· 流程：
· 要求：
流程節點
執行角色
時間要求
流轉標準
每月制定KPI
管理層
與KPI輸出時間一致
輸出KPI內容
制定計劃KPI完成時間
產品排期
技術產品經理
接收KPI指標後2個工作日內
制定計劃產品設計開始時間
制定計劃產品方案完成時間
制定計劃產品內部評審時間
制定計劃業務評審時間
制定計劃提交技術評審時間
產品設計
技術產品經理
按產品排期
輸出清晰的全局流程圖
輸出數據庫表結構骨架
輸出清晰的產品原型/用例圖
產品內部評審
發起角色：技術產品經理
評審角色：
技術產品部負責人
產品中心分管人
按產品排期
需求目的與公司發展戰略相匹配
優先級跟隨公司發展節奏
產品方案綜合考慮研發成本ROI
功能設計邏輯符合現階段整體產品規劃
整體方案把握核心需求
需求方評審
發起角色：技術產品經理
評審角色：需求方
按產品排期
整體流程符合業務邏輯
功能滿足業務核心需求
UE評審
發起角色：技術產品經理
評審角色：UE設計師
1個工作日內
從UE角度對需求原型提出優化建議，對不靠譜/無法實現的功能進行篩選，主要有兩個維度：
流程邏輯是否順暢
2、頁面佈局是否合理
技術評審
發起角色：技術產品經理
評審角色：
研發部負責人
研發經理
開發工程師
測試工程師
2個工作日內
1、需求目的與公司發展戰略相匹配
2、優先級跟隨公司發展節奏
3、產品方案綜合考慮研發成本ROI
4、產品方案是否符合技術實現邏輯
UI排期
設計組組長
1個工作日內
1、制定計劃UI設計稿完成時間
UI設計
UI設計師
按設計師排期
輸出高保真UI設計稿（初稿）
產品確認
技術產品經理
1個工作日
UI設計稿與原產品需求相匹配
整體設計效果滿意
需求文檔交付
技術產品經理
技術評審通過後1個工作日內
包含清晰的全局流程圖或流程說明文檔
如有原型，原型上需體現基本的交互用例，並附帶詳細的交互規則說明
需求文檔需要詳細記錄文檔版本號，如文檔產生更新，需及時同步至研發經理和相關的研發工程師、測試工程師
UI設計稿交付
UI設計師
按設計師排期
此環節需要交付的UI設計稿（終稿）有以下文檔：
UI設計最終效果圖
頁面切圖
頁面標註
研發排期
研發經理
需求文檔提交後2個工作日內
制定計劃開發完成時間
制定計劃提測時間
制定計劃研發完成時間
制定計劃提交產品驗收時間
研發設計
研發經理
按研發排期
1、分析和拆分功能
功能開發
開發工程師
按研發排期
1、輸出項目計劃
功能測試
測試工程師
按研發排期
1、測試組對整體項目計劃內容功能點進行測試
2、功能提測時同步進度給產品經理，為驗收、培訓/宣貫做準備
產品驗收
技術產品經理
研發測試完成後2個工作日內
主要功能點與原始需求保持一致
重點功能邏輯驗證無誤
設計師驗收
UI設計師
研發測試完成後2個工作日內
設計稿交付後，設計師需要跟進整個開發周期裡的最終效果和反饋問題
最終實現效果驗證合格
培訓與宣貫
發起角色：技術產品經理
講師角色：
產品運營經理
技術產品經理
驗收完成後2個工作日內
完成相關部門培訓與宣貫
發送培訓/宣貫郵件，附帶完整的培訓/宣貫資料
如需對供給端進行培訓，需提前預留足夠的時間給到供給中心培訓部，確保最終供給端培訓同步完成
部署上線
發起角色：研發經理
協助角色：測試工程師
按產品確定的上線時間
發佈前提前通知到受影響的相關部門
上線後對功能進行驗證確認無誤
上線後驗證完成同步通知技術產品經理
上線通知
技術產品經理
部署上線後1個工作日內
大范圍的功能升級需向公司全員發送通知郵件
小范圍的功能升級需向相關使用部門發送通知郵件
2、零碎迭代需求
·流程：
· 要求：
流程節點
執行角色
時間要求
流轉標準
釘釘上提交需求
需求方
（多為產品運營）
無
需求方可直接在釘釘上提交“技術產品需求管理”流程
產品運營經理每周從各部門收集到的需求匯總整理後在釘釘上提交“技術產品需求管理”流程
產品分析與排期
技術產品經理
按產品排期
產品經理記錄到需求管理表
按緊急程度來排優先級
反饋計劃向研發部提交需求時間
產品設計
技術產品經理
按產品排期
輸出清晰詳細的需求文檔
交付需求文檔
技術產品經理
緊急需求當周內完成提交
非緊急需求每兩周匯總提交
緊急需求需同步發起備案郵件提交研發，需求進度在釘釘中流轉與反饋
非緊急需求匯總後在釘釘上流轉
研發分析與排期
研發經理
2個工作日內
1、制定計劃開發完成時間
2、制定計劃提測時間
3、制定計劃研發完成時間
4、制定計劃提交產品驗收時間
研發設計
研發經理
按研發排期
1、分析和拆分功能
功能開發
開發工程師
按研發排期
1、輸出項目計劃
功能測試
測試工程師
按研發排期
1、測試組對整體項目計劃內容功能點進行測試
2、功能提測時同步進度給產品經理，為驗收、培訓/宣貫做準備
產品驗收
技術產品經理
2個工作日內
主要功能點與原始需求保持一致
重點功能邏輯驗證無誤
部署上線
發起角色：研發經理
協助角色：測試工程師
1個工作日內
發佈前提前通知到受影響的相關部門
上線後對功能進行驗證
上線通知
技術產品經理
1個工作日內
1、釘釘產品需求管理流程上反饋上線通知
3、對接過程問題和建議補充
一.需求改變，提醒不及時，文字描述不詳細。
建議：（1）流程補充迭代，需求改變–產品經理發起原因說明–項目經理確認–組織對應人員聽取需求講解。
（2）工具上再次提醒，需求更新後@對應需求相關人員。
二.產品上線時間，不確定含糊。（如研發開發完成瞭，是按研發進度呢還是按產品業務需要。）
建議：（1）需求技術評審通過，增加上線時間要求標註，是按研發進度還是按產品特定時間。
三．研發部的工作信息如何同步，需求來源、分類、進度、耗時（公司層面需要瞭解的信息）
建議：目前每周末周報有同步開發進度、耗時。跟技術產品部溝通，以後給的需求作備註：分類（如：企業業務、消費者業務）和來源，然後補充到周報裡面。
五、釘釘提交需求操作介紹
1、打開釘釘→進入“工作”→點擊“簡道雲”
2、點擊“發起流程”→選擇“技術產品需求管理”
3、按照頁面提示填寫相應的需求內容，最後點擊“提交”即可提交成功。
六、釘釘查看需求進度操作介紹
1、打開釘釘→進入“工作”→點擊“簡道雲”
2、點擊“產品工作流程”→選擇“技術產品需求管理”
3、點擊“我發起的”→點擊“流程狀態”
4、查看流程節點圖，如需查看流程日志，點擊“查看流程日志”即可。
小結
對於規范流程，首先梳理事情是否吻合意義范圍、有沒有必要制作流程制度、然後按5個推演環節設計；我們研發在實際過程中不管遇到問題，都可以有章可循，從而保證研發工作的順利推進，更高效地達成研發目標。