產(chǎn)品和項目兩手都要抓，兩手都要硬，方是真B端產(chǎn)品。

產(chǎn)品流程

產(chǎn)品研發(fā)流程大體分為：立項階段、設計階段、開發(fā)階段、測試階段、上線階段、運營階段。

1. 立項階段

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

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

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

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

2. 設計階段

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

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

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

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

• 列表顯示（實體的相關信息、列表需要顯示的字段、數(shù)據(jù)規(guī)模以及分頁）

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

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

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

• 編輯（只讀信息、可編輯信息、校驗規(guī)則）

• 啟用（規(guī)則）

• 停用（規(guī)則）

• 刪除（規(guī)則）

3. PRD階段

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

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

這樣有以下好處：

1. 一目了然，開發(fā)、UI設計不容易遺漏頁面

2. UI設計、研發(fā)實現(xiàn)工作量評估更加到位

3. UI設計師可以設計更好的UE效果，有更大的發(fā)揮空間

4. 節(jié)省產(chǎn)品經(jīng)理自己的時間，高保真原型性價比太低

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

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

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

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

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

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

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

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

4. 開發(fā)計劃階段

主要是進行項目的計劃排期，不展開講。內(nèi)部有開發(fā)經(jīng)理角色，可以將這個任務交給開發(fā)經(jīng)理。

5. 概要設計

如果不是第一個大版本，基本是業(yè)務時序圖、數(shù)據(jù)結構的設計。由研發(fā)輸出，測試、產(chǎn)品進行評審。

6. 編碼實現(xiàn)階段

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

1. 原型、交互形式的改動

2. 用戶需求規(guī)格的補充

3. 追蹤推進進度，進行階段性的測試驗收。如客戶管理的列表查詢和新增編輯功能今天都能完成，要早上找到對應研發(fā)人員詢問進度情況。進度理想的情況下，下午讓研發(fā)先自測，然后去進行檢查。進度不理想要找出差距，尋找追趕的辦法。

7. 測試驗證階段

主要有以下工作：

1. 把握測試環(huán)境的部署和更新節(jié)奏

2. 守好需求驗證的關卡。根據(jù)主業(yè)務流程，編寫需求驗證清單，對產(chǎn)品進行需求測試。如果連主業(yè)務流程都跑不通，沒必要讓測試人員進行測試。

3. 修復前期遺漏的業(yè)務邏輯。不排除經(jīng)過原型評審、需求評審、編碼實現(xiàn)，還有部分邏輯不在需求規(guī)格說明中。例如某個異常情況，需求規(guī)格沒寫處理邏輯，研發(fā)按照自己的想法做了。還是需要產(chǎn)品確認，并在需求規(guī)格中補充的。

8. 發(fā)布運營

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

1. 演示環(huán)境的搭建，準備數(shù)據(jù)的初始化

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

3. 針對實施、客服的系統(tǒng)實操培訓，輸出用戶操作說明書

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

5. EDM的設計

6. APP更新機制策略的評估，是灰度發(fā)布、提示更新還是強制更新

7. 用戶的反饋進入需求池，為后續(xù)迭代做準備

8. 支撐驗證客戶項目，包括方案講解、需求調(diào)研等

項目流程

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

整個大流程里面，產(chǎn)品經(jīng)理可能會在涉及以下工作：

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

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

3. 在投標階段后期切入，負責客戶POC功能的調(diào)研和規(guī)劃落地。需要協(xié)調(diào)各方資源，在實施開發(fā)環(huán)境進行功能改造，并追蹤整體進度（此時未立項，替代項目經(jīng)理）。

4. 在項目立項階段切入，作為公司的產(chǎn)品部代表出席立項會，維護客情。

5. 在藍圖規(guī)劃階段切入，支撐需求調(diào)研工作。如出差客戶現(xiàn)場，主導調(diào)研并輸出部分PRD。提供最新產(chǎn)品原型、PRD和組件庫，賦能實施人員。最后，還可能參與藍圖方案的輸出。

6. 在系統(tǒng)建設階段切入，可標準化的功能將由產(chǎn)品部實現(xiàn)。此時需要分配任務跟蹤進度，確保標準功能分批實現(xiàn)，滿足客戶訴求和各項目上線節(jié)點。同時關注客戶測試環(huán)境，確認穩(wěn)定可靠。

7. 在上線推廣階段切入，主要是客情維護和系統(tǒng)培訓。另外，也需要輸出產(chǎn)品的用戶說明書，為一線實施人員提供彈藥。此階段已上線客戶生產(chǎn)環(huán)境，需要安排服務經(jīng)理跟進，并做好出現(xiàn)緊急情況的預案。