產品和項目兩手都要抓，兩手都要硬，方是真B端產品。

產品流程

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

1. 立項階段

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

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

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

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

2. 設計階段

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

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

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

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

• 列表顯示（實體的相關信息、列表需要顯示的字段、數據規模以及分頁）
• 查詢（哪幾個條件，條件對應的類型）
• 高級查詢（哪幾個條件，條件對應的類型）
• 新增（表單錄入字段，校驗規則）
• 編輯（只讀信息、可編輯信息、校驗規則）
• 啟用（規則）
• 停用（規則）
• 刪除（規則）

3. PRD階段

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

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

這樣有以下好處：

1. 一目了然，開發、UI設計不容易遺漏頁面
2. UI設計、研發實現工作量評估更加到位
3. UI設計師可以設計更好的UE效果，有更大的發揮空間
4. 節省產品經理自己的時間，高保真原型性價比太低

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

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

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

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

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

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

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

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

4. 開發計劃階段

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

5. 概要設計

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

6. 編碼實現階段

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

1. 原型、交互形式的改動
2. 用戶需求規格的補充
3. 追蹤推進進度，進行階段性的測試驗收。如客戶管理的列表查詢和新增編輯功能今天都能完成，要早上找到對應研發人員詢問進度情況。進度理想的情況下，下午讓研發先自測，然后去進行檢查。進度不理想要找出差距，尋找追趕的辦法。

7. 測試驗證階段

主要有以下工作：

1. 把握測試環境的部署和更新節奏
2. 守好需求驗證的關卡。根據主業務流程，編寫需求驗證清單，對產品進行需求測試。如果連主業務流程都跑不通，沒必要讓測試人員進行測試。
3. 修復前期遺漏的業務邏輯。不排除經過原型評審、需求評審、編碼實現，還有部分邏輯不在需求規格說明中。例如某個異常情況，需求規格沒寫處理邏輯，研發按照自己的想法做了。還是需要產品確認，并在需求規格中補充的。

8. 發布運營

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

1. 演示環境的搭建，準備數據的初始化
2. 針對營銷線的方案宣講，輸出解決方案和功能模塊清單
3. 針對實施、客服的系統實操培訓，輸出用戶操作說明書
4. APP上架文案和相關事項追蹤
5. EDM的設計
6. APP更新機制策略的評估，是灰度發布、提示更新還是強制更新
7. 用戶的反饋進入需求池，為后續迭代做準備
8. 支撐驗證客戶項目，包括方案講解、需求調研等

項目流程

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

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

1. 在意向階段介入，協助售前一起完善解決方案（一般是大客戶）。
2. 在投標階段初期切入，替代售前進行解決方案的講解，以及產品的演示（行業龍頭客戶）。
3. 在投標階段后期切入，負責客戶POC功能的調研和規劃落地。需要協調各方資源，在實施開發環境進行功能改造，并追蹤整體進度（此時未立項，替代項目經理）。
4. 在項目立項階段切入，作為公司的產品部代表出席立項會，維護客情。
5. 在藍圖規劃階段切入，支撐需求調研工作。如出差客戶現場，主導調研并輸出部分PRD。提供最新產品原型、PRD和組件庫，賦能實施人員。最后，還可能參與藍圖方案的輸出。
6. 在系統建設階段切入，可標準化的功能將由產品部實現。此時需要分配任務跟蹤進度，確保標準功能分批實現，滿足客戶訴求和各項目上線節點。同時關注客戶測試環境，確認穩定可靠。
7. 在上線推廣階段切入，主要是客情維護和系統培訓。另外，也需要輸出產品的用戶說明書，為一線實施人員提供彈藥。此階段已上線客戶生產環境，需要安排服務經理跟進，并做好出現緊急情況的預案。

作者：道·術 ，郵箱：olivercan.wunban@foxmail.com

本文由 @道·術 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash ，基于 CC0 協議