產(chǎn)品和項目兩手都要抓，兩手都要硬，方是真B端產(chǎn)品。
產(chǎn)品研發(fā)流程大體分為： 立項階段、設(shè)計階段、開發(fā)階段、測試階段、上線階段、運營階段。
主要分為需求搜集和PMO（或產(chǎn)品委員會）立項。需求搜集階段可以很長，包括如下內(nèi)容：
如果是從0到1或者徹底重構(gòu)的產(chǎn)品，要先進行BRD的輸出。包括整體行業(yè)的分析，到競爭對手分析，再到roadmap和對應(yīng)資源匹配。用BRD進行宣講，才能向上申請資源進行立項。
然后，可能是MRD的輸出或者拆解執(zhí)行。MRD在很多公司會以年度規(guī)劃的形式提前進行輸出，主要是產(chǎn)品roadmap和進度計劃。到了某個立項階段，會根據(jù)市場、戰(zhàn)略、競品、技術(shù)、渠道等情況，調(diào)整版本實現(xiàn)的功能模塊以及優(yōu)先級。當(dāng)然，還有最重要的項目里程碑計劃。
最終輸出物基本是立項報告，然后邀請PMO或產(chǎn)品委員會進行立項評審。
主要分為需求池和PRD兩大塊：
基于立項階段的MRD、上版本遺留問題和運營反饋的問題，列出概要清單。
然后召集項目成員，進行概要評審。這個評審一般是可行性、優(yōu)先級以及成本的評審。評審?fù)ㄟ^的功能，細化成功能清單。
也存在研發(fā)業(yè)務(wù)背景較弱，概要已經(jīng)要很細，功能清單要更細，以評估合適的工作量。上述的一個概要，需要拆成：
列表顯示（實體的相關(guān)信息、列表需要顯示的字段、數(shù)據(jù)規(guī)模以及分頁）
查詢（哪幾個條件，條件對應(yīng)的類型）
高級查詢（哪幾個條件，條件對應(yīng)的類型）
新增（表單錄入字段，校驗規(guī)則）
編輯（只讀信息、可編輯信息、校驗規(guī)則）
啟用（規(guī)則）
停用（規(guī)則）
刪除（規(guī)則）
主要輸出物是原型和需求規(guī)格說明書，部分小版本甚至不輸出需求規(guī)格說明書，業(yè)務(wù)流程、頁面流程、交互說明和異常處理都會在原型上體現(xiàn)。
B端比較重視文檔，在部分敏捷開發(fā)的C端，原型也是以逐個拆解的線框圖為主。
這樣有以下好處：
一目了然，開發(fā)、UI設(shè)計不容易遺漏頁面
UI設(shè)計、研發(fā)實現(xiàn)工作量評估更加到位
UI設(shè)計師可以設(shè)計更好的UE效果，有更大的發(fā)揮空間
節(jié)省產(chǎn)品經(jīng)理自己的時間，高保真原型性價比太低
繪制原型之前要進行整體的業(yè)務(wù)建模，力求梳理清楚全部的業(yè)務(wù)流程和必要信息。
在繪制草圖時，要多和UI設(shè)計師交流，找到更合適的呈現(xiàn)形式。
在原型評審的時候，先介紹這些流程，再看具體的原型頁面。原型評審結(jié)束，前端研發(fā)可以開始部分頁面的UI開發(fā)，UI設(shè)計師準(zhǔn)備視覺界面的輸出。
需求規(guī)格說明書，需要拆分各業(yè)務(wù)領(lǐng)域進行輸出。一個產(chǎn)品一個需求規(guī)格說明書，整個文檔會非常的大。加上大量的修訂和批注，產(chǎn)品人員維護起來很痛苦。編寫需求規(guī)格說明書期間，要保持和架構(gòu)師（開發(fā)經(jīng)理）的溝通，在文檔中完善業(yè)務(wù)邏輯。為了保障文檔質(zhì)量，目前文檔是基于用例的形式編寫的：
這樣能更好的和測試進行溝通，減輕測試用例輸出的工作，更專注于自動化測試。
需求規(guī)格輸出完成，需要進行需求評審。由于內(nèi)部項目動輒3個月，這個會議至少需要1-2小時。拿著幾十上百頁的文檔過，開始還好，半小時后大家就注意力渙散了。
目前使用PPT進行需求評審，只關(guān)注業(yè)務(wù)流程和關(guān)鍵因素，反饋效果很好：
具體文檔可以回去后進行查看，配合項目管理工具登記具體的問題，產(chǎn)品人員進行修復(fù)。
主要是進行項目的計劃排期，不展開講。內(nèi)部有開發(fā)經(jīng)理角色，可以將這個任務(wù)交給開發(fā)經(jīng)理。
如果不是第一個大版本，基本是業(yè)務(wù)時序圖、數(shù)據(jù)結(jié)構(gòu)的設(shè)計。由研發(fā)輸出，測試、產(chǎn)品進行評審。
該階段事情最為繁雜的，包括但不限于：
原型、交互形式的改動
用戶需求規(guī)格的補充
追蹤推進進度，進行階段性的測試驗收。如客戶管理的列表查詢和新增編輯功能今天都能完成，要早上找到對應(yīng)研發(fā)人員詢問進度情況。進度理想的情況下，下午讓研發(fā)先自測，然后去進行檢查。進度不理想要找出差距，尋找追趕的辦法。
主要有以下工作：
把握測試環(huán)境的部署和更新節(jié)奏
守好需求驗證的關(guān)卡。根據(jù)主業(yè)務(wù)流程，編寫需求驗證清單，對產(chǎn)品進行需求測試。如果連主業(yè)務(wù)流程都跑不通，沒必要讓測試人員進行測試。
修復(fù)前期遺漏的業(yè)務(wù)邏輯。不排除經(jīng)過原型評審、需求評審、編碼實現(xiàn)，還有部分邏輯不在需求規(guī)格說明中。例如某個異常情況，需求規(guī)格沒寫處理邏輯，研發(fā)按照自己的想法做了。還是需要產(chǎn)品確認(rèn)，并在需求規(guī)格中補充的。
發(fā)布運營階段很重要，工作也比較零散：
演示環(huán)境的搭建，準(zhǔn)備數(shù)據(jù)的初始化
針對營銷線的方案宣講，輸出解決方案和功能模塊清單
針對實施、客服的系統(tǒng)實操培訓(xùn)，輸出用戶操作說明書
APP上架文案和相關(guān)事項追蹤
EDM的設(shè)計
APP更新機制策略的評估，是灰度發(fā)布、提示更新還是強制更新
用戶的反饋進入需求池，為后續(xù)迭代做準(zhǔn)備
支撐驗證客戶項目，包括方案講解、需求調(diào)研等
B端客戶一般有定制化訴求，會以項目交付的形式進行落地。并且公司內(nèi)部要求每個版本有驗證客戶，完善產(chǎn)品到實施的知識轉(zhuǎn)移。工作流程如下：
整個大流程里面，產(chǎn)品經(jīng)理可能會在涉及以下工作：
在意向階段介入，協(xié)助售前一起完善解決方案（一般是大客戶）。
在投標(biāo)階段初期切入，替代售前進行解決方案的講解，以及產(chǎn)品的演示（行業(yè)龍頭客戶）。
在投標(biāo)階段后期切入，負責(zé)客戶POC功能的調(diào)研和規(guī)劃落地。需要協(xié)調(diào)各方資源，在實施開發(fā)環(huán)境進行功能改造，并追蹤整體進度（此時未立項，替代項目經(jīng)理）。
在項目立項階段切入，作為公司的產(chǎn)品部代表出席立項會，維護客情。
在藍圖規(guī)劃階段切入，支撐需求調(diào)研工作。如出差客戶現(xiàn)場，主導(dǎo)調(diào)研并輸出部分PRD。提供最新產(chǎn)品原型、PRD和組件庫，賦能實施人員。最后，還可能參與藍圖方案的輸出。
在系統(tǒng)建設(shè)階段切入，可標(biāo)準(zhǔn)化的功能將由產(chǎn)品部實現(xiàn)。此時需要分配任務(wù)跟蹤進度，確保標(biāo)準(zhǔn)功能分批實現(xiàn)，滿足客戶訴求和各項目上線節(jié)點。同時關(guān)注客戶測試環(huán)境，確認(rèn)穩(wěn)定可靠。
在上線推廣階段切入，主要是客情維護和系統(tǒng)培訓(xùn)。另外，也需要輸出產(chǎn)品的用戶說明書，為一線實施人員提供彈藥。此階段已上線客戶生產(chǎn)環(huán)境，需要安排服務(wù)經(jīng)理跟進，并做好出現(xiàn)緊急情況的預(yù)案。
