作者：道·術?（轉載已取得授權）

產品研發流程大體分為：立項階段、設計階段、開發階段、測試階段、上線階段、運營階段。

1. 立項階段

主要分為需求搜集和PMO（或產品委員會）立項。需求搜集階段可以很長，包括如下內容：

如果是從0到1或者徹底重構的產品，要先進行BRD的輸出。包括整體行業的分析，到競爭對手分析，再到roadmap和對應資源匹配。用BRD進行宣講，才能向上申請資源進行立項。

然后，可能是MRD的輸出或者拆解執行。MRD在很多公司會以年度規劃的形式提前進行輸出，主要是產品roadmap和進度計劃。到了某個立項階段，會根據市場、戰略、競品、技術、渠道等情況，調整版本實現的功能模塊以及優先級。當然，還有最重要的項目里程碑計劃。

最終輸出物基本是立項報告，然后邀請PMO或產品委員會進行立項評審。

2. 設計階段

主要分為需求池和PRD兩大塊：

基于立項階段的MRD、上版本遺留問題和運營反饋的問題，列出概要清單。

然后召集項目成員，進行概要評審。這個評審一般是可行性、優先級以及成本的評審。評審通過的功能，細化成功能清單。

也存在研發業務背景較弱，概要已經要很細，功能清單要更細，以評估合適的工作量。上述的一個概要，需要拆成：

• 列表顯示（實體的相關信息、列表需要顯示的字段、數據規模以及分頁）

• 查詢（哪幾個條件，條件對應的類型）

• 高級查詢（哪幾個條件，條件對應的類型）

• 新增（表單錄入字段，校驗規則）

• 編輯（只讀信息、可編輯信息、校驗規則）

• 啟用（規則）

• 停用（規則）

• 刪除（規則）

3. PRD階段

主要輸出物是原型和需求規格說明書，部分小版本甚至不輸出需求規格說明書，業務流程、頁面流程、交互說明和異常處理都會在原型上體現。

B端比較重視文檔，在部分敏捷開發的C端，原型也是以逐個拆解的線框圖為主。

這樣有以下好處：

一目了然，開發、UI設計不容易遺漏頁面

UI設計、研發實現工作量評估更加到位

UI設計師可以設計更好的UE效果，有更大的發揮空間

節省產品經理自己的時間，高保真原型性價比太低

繪制原型之前要進行整體的業務建模，力求梳理清楚全部的業務流程和必要信息。

在繪制草圖時，要多和UI設計師交流，找到更合適的呈現形式。

在原型評審的時候，先介紹這些流程，再看具體的原型頁面。原型評審結束，前端研發可以開始部分頁面的UI開發，UI設計師準備視覺界面的輸出。

需求規格說明書，需要拆分各業務領域進行輸出。一個產品一個需求規格說明書，整個文檔會非常的大。加上大量的修訂和批注，產品人員維護起來很痛苦。編寫需求規格說明書期間，要保持和架構師（開發經理）的溝通，在文檔中完善業務邏輯。為了保障文檔質量，目前文檔是基于用例的形式編寫的：

這樣能更好的和測試進行溝通，減輕測試用例輸出的工作，更專注于自動化測試。

需求規格輸出完成，需要進行需求評審。由于內部項目動輒3個月，這個會議至少需要1-2小時。拿著幾十上百頁的文檔過，開始還好，半小時后大家就注意力渙散了。

目前使用PPT進行需求評審，只關注業務流程和關鍵因素，反饋效果很好：

具體文檔可以回去后進行查看，配合項目管理工具登記具體的問題，產品人員進行修復。

4. 開發計劃階段

主要是進行項目的計劃排期，不展開講。內部有開發經理角色，可以將這個任務交給開發經理。

5. 概要設計

如果不是第一個大版本，基本是業務時序圖、數據結構的設計。由研發輸出，測試、產品進行評審。

6. 編碼實現階段

該階段事情最為繁雜的，包括但不限于：

原型、交互形式的改動

用戶需求規格的補充

追蹤推進進度，進行階段性的測試驗收。

如客戶管理的列表查詢和新增編輯功能今天都能完成，要早上找到對應研發人員詢問進度情況。

進度理想的情況下，下午讓研發先自測，然后去進行檢查。

進度不理想要找出差距，尋找追趕的辦法。

7. 測試驗證階段

主要有以下工作：

把握測試環境的部署和更新節奏

守好需求驗證的關卡。

根據主業務流程，編寫需求驗證清單，對產品進行需求測試。

如果連主業務流程都跑不通，沒必要讓測試人員進行測試。

修復前期遺漏的業務邏輯。

不排除經過原型評審、需求評審、編碼實現，還有部分邏輯不在需求規格說明中。

例如某個異常情況，需求規格沒寫處理邏輯，研發按照自己的想法做了。

還是需要產品確認，并在需求規格中補充的。

8. 發布運營

發布運營階段很重要，工作也比較零散：

演示環境的搭建，準備數據的初始化

針對營銷線的方案宣講，輸出解決方案和功能模塊清單

針對實施、客服的系統實操培訓，輸出用戶操作說明書

APP上架文案和相關事項追蹤

EDM的設計

APP更新機制策略的評估，是灰度發布、提示更新還是強制更新

用戶的反饋進入需求池，為后續迭代做準備

支撐驗證客戶項目，包括方案講解、需求調研等

項目流程

B端客戶一般有定制化訴求，會以項目交付的形式進行落地。并且公司內部要求每個版本有驗證客戶，完善產品到實施的知識轉移。工作流程如下：

整個大流程里面，產品經理可能會在涉及以下工作：

在意向階段介入，協助售前一起完善解決方案（一般是大客戶）。

在投標階段初期切入，替代售前進行解決方案的講解，以及產品的演示（行業龍頭客戶）。

在投標階段后期切入，負責客戶POC功能的調研和規劃落地。

需要協調各方資源，在實施開發環境進行功能改造，并追蹤整體進度（此時未立項，替代項目經理）。

在項目立項階段切入，作為公司的產品部代表出席立項會，維護客情。

在藍圖規劃階段切入，支撐需求調研工作。

如出差客戶現場，主導調研并輸出部分PRD。

提供最新產品原型、PRD和組件庫，賦能實施人員。

最后，還可能參與藍圖方案的輸出。

在系統建設階段切入，可標準化的功能將由產品部實現。

此時需要分配任務跟蹤進度，確保標準功能分批實現，滿足客戶訴求和各項目上線節點。

同時關注客戶測試環境，確認穩定可靠。

在上線推廣階段切入，主要是客情維護和系統培訓。

另外，也需要輸出產品的用戶說明書，為一線實施人員提供彈藥。

此階段已上線客戶生產環境，需要安排服務經理跟進，并做好出現緊急情況的預案。

視頻號推薦

最后也歡迎有問題的小伙伴加微信：yw5201a1?溝通交流。

更多干貨可關注微信公眾號：產品劉

想學習更多關于產品、職場、心理、認知等干貨，可長按右邊二維碼，關注我們。

RECOMMEND

推薦閱讀

再分享個競品分析報告

最全的B端產品經理干貨知識（2）

線下實戰2.0

二面面試官都會問啥？

點擊“閱讀原文”

總結

以上是生活随笔為你收集整理的B端SaaS产品工作流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。