起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識10個步驟，拆解實用的B端產品工作流
作為一個B端產品經理，筆者將結合自己的工作實踐和認知，與大家分享一下自己的B端產品經理的工作流以及每一個流程中具體的思考點和注意點，希望能提供一個真正實用的工作流程，給與大家啟發和思考。
看過一些總結B端產品經理工作流程的方法論或指南，總體來說步驟差距不大，但大部分會比較空，告訴步驟點到為止，缺少真正的實用性和啟發。筆者作為一個B端產品經理，結合自己的工作實踐和認知，與大家分享一下自己的B端產品經理的工作流以及每一個流程中具體的思考點和注意點，希望能提供一個真正實用的工作流程，給與大家啟發和思考。
作為一個轉行的產品經理，最初看了很多介紹產品經理工作流程的文章及書籍，為了幫助自己能盡快上手，但發小大部分都是介紹的很簡單，只給了步驟或者大體方法，自己在實踐過程中照做了，但是該踩的坑一個都沒少，通過2年產品的工作經歷以及自己的工作內容及行業性質，總結了自己的工作流，特別是每個步驟中需要的思考點，特別適用于B端產品經理。
我的整體工作流程：
看起來步驟會比較多，如果是大項目，基本每一步都會需要，小項目或優化類，根據實際需要做刪減即可。其實整體工作流程和很多作者總結的工作流大同小異，如下圖是另外一位作者寫總結的B端工作流，也給了我一些啟發，大家也可以去閱讀一下。
摘自：人人都是產品經理文章《我的B端產品工作流》
那下面重點為大家詳細介紹，在我的每一個工作流步驟中，需要注意的點以及思考方向，這些內容也是自己在一次次項目過程及項目復盤中總結出來的，希望給大家在實際工作中有一定啟發。
01 收集需求
在業務型公司中，大部分業務提出需求其實會相對比較片面，很多沒有詳細思考就提出，或者僅解決一個臨時問題，因此在對業務提出的需求溝通中，產品經理需要了解清楚需求本質，引導業務思考。主要需要收集以下信息，以下內容可以作為【產品需求收集表】來要求業務提交需求時填寫，同時也是幫助業務自己對需求進行思考。
- 需求類型：優化，bug，新功能等。
- 優先級：需求的緊急程度。
- 功能使用頻率：這里也是之前自己遇到了坑，業務提出一個功能優化需求，做好上線以后，發現業務基本就不使用這個功能，導致上線后沒有實際意義。因此在需求收集階段，特別是針對某功能優化，一定要清楚業務對這個功能的使用頻率。
- 需求背景或原因
- 需求目的/解決什么痛點/實現什么效益
- 需求詳情：對需求的詳細描述。
在收集需求階段，若能了解到以上內容，說明該需求是業務仔細思考過的，同時也幫助自己后面對該需求合理性的判斷。
02 思考需求合理性
這一點在做產品初期沒有意識到這個問題的重要性，導致很容易做著做著就變成了需求輸出工具，后來做了很多項目復盤，才意識到業務很多提出的需求不合理，很臨時性，會導致系統功能臃腫，因此當收集完業務的需求后，一定要思考需求的合理性，盡量讓每個需求做的都有價值。主要思考點可以圍繞一下幾點：
- 復盤業務提出的需求內容：根據收集到的業務需求，詳細了解業務訴求，核對其真實性及是否有邏輯沖突。
- 數據調研：很多需求或項目的提出，在啟動之前都需要從現有數據上進行一定程度的分析預估可到達的目標，同時也可看該功能的使用數據情況，考慮其有沒有優化價值。
- 需求內容的適用場景：很多業務會提一些特殊場景的優化或者特殊處理邏輯，產品做功能邏輯盡量能統一化，避免特殊邏輯，后期會不好管理，也容易留坑。
- 技術架構的影響：有的需求也許看起來很簡單，但其實技術實現非常復雜或者現有架構不支持，若遇到這種拿不準的情況可以先和開發聊一下，簡單評估一下，這樣對項目的定位也會更清晰。比如我遇到一個場景，業務提出希望訂單能合并發貨，我認為也很合理，可以做，但后來評審發現，我們現在WMS系統架構是很難支持的，如果要做需要全面重整架構，很大的工程量，因此重新評估該項目，就先暫緩了。
- 是否需要其他系統/部門的支撐：做B端產品，會涉及到大量相互關聯的邏輯及流程，比如我做訂單系統，會涉及到和商品系統、物流系統、倉儲系統的各種對接。因此在該階段，可以大致思考一下是否需要其他系統支持，若需要可以提前安排溝通，避免后面需要了才臨時對接，這也是我自己血的教訓。
03 項目初步立項
需求確定沒問題，就可以做初步的立項了，大部分公司不會說非常要求這點，比如項目立項報告之類的，主要是產品自己要做對應的工作計劃安排，后續更規范的項目安排會在評審通過，確定上線時間后發出，這個也和各公司團隊的習慣有關，根據實際情況做調整即可。該階段主要確定：
- 項目大體背景、目的、優先級、邊界、內容
- 大體時間安排：主要是產品設計時間
04 需求調研
B端產品的需求調研相對C端的會簡單一些，主要方式為：訪談+競品。訪談需要提前列出自己希望獲取的關鍵信息，可根據思考需求合理性階段得出的結果和疑問點歸納得出，讓需求調研訪談更具目的性和有效性。
B端競品相對比較難獲取到，我大部分會看一些第三方開發的ERP軟件，去試用借鑒一下。
調研這個自己也還在摸索階段，還有很多空間可以發揮，歡迎大家補充。
05 產品設計
說了這么多終于到產品設計環節了，其實B端產品如果只是說畫原型的話，其實很簡單，不會花很多時間。主要難點是在于整個產品方案的設計，邏輯的梳理以及各個模塊考慮周全。下面是我在整體產品方案涉及中主要會考慮的點，以及會輸出的內容，也是自己踩了很多坑總結下來的。
各種圖
很多總結的產品經理的工作流程中，會說要需要畫用例圖，流程圖，產品功能結構圖，產品信息結構圖等等。個人認為，這里沒必要一定要按部就班每個都要畫，更多輸出這些圖是幫助你梳理邏輯，想清楚即可，不用太苛求形式。我個人在這部分主要會比較常用到以下幾種：
1）流程圖
流程圖是在B端流程產品設計中，最常用的東西。主要幫助理清楚各種關聯邏輯。我常用的流程圖主要是以下幾種：
- 業務流程圖：主要用于幫助理清楚業務的流程，也幫助自己更好的了解業務。
- 系統流程圖：系統整體的操作流程。
- 數據流程圖：這個一點很多產品容易忽視，大部分做到系統流程就完事了，但是產品想要做的更好，更深入，一定要清楚數據流。同時理清楚數據流，也能更好的幫助你做功能設計，以及考慮的更加全面。
再這個階段還需要注意一點就是，不要僅限于你做的這個系統或者功能的流程，還需要考慮到其上游及下游的關聯性，是否需要上游支持？下游是否有消費使用你產生的數據？是否需要一起聯動修改？等等，都需要在產品設計中考慮完善，避免之后發現了才做臨時處理。這點也是我之前做項目留下的刻骨銘心的教訓，之前做OMS系統，沒有考慮到商品系統以及物流倉儲系統的關聯性，導致上線后出現了很多問題，那個時候再來臨時趕工處理。
2）產品信息結構/產品功能結構圖
這兩個圖，我平時用的不多，主要是在大項目中使用到，大項目中主要通過這兩個圖，可以總結出你系統功能結構以及系統邊界，幫助后續做產品功能設計。
需求清單
通過邏輯的梳理，能確定本期項目需要開發的內容及需求內容。需求內容可以明確羅列出來，幫助開發清晰知道需求點，也方便產品直接對著清單，做后面的產品設計，會非常清晰，這也是我最近做項目中總結出來的。注意，這里說的需求內容不是業務提出的需求點，而是產品通過前面總結，所確認出了本期項目的開發需求清單。
畫產品原型
基本上通過上面一系列圖及需求清單輸出后，就可以開始畫原型頁面了。大部分B端產品，原型不需要高保真，只需要描述清晰，結構清楚即可，不用去苛求于畫的很多交互，重要的是邏輯。
產品原型這里就不多說了，可以去收集一些公共的組件，在畫的過程中可以提高很多效率。
畫完原型后，一般的工作流程中就是要寫PRD了，但實際大部分公司基本不太寫PRD文檔，主要原因是PRD問題太龐大不利于修改維護，而且開發基本不會仔細看，所以大部分方式是直接采用再axure+批注的方式。需要注意的是，這種方式有時原型頁面會比較亂，堆砌了太多東西，很多箭頭指來指去，一定要注意排版，讓其簡潔清晰可讀性強。
數據處理方案
如果涉及到數據相關的功能，特別是有歷史數據需要初始或者處理的，需要在產品設計階段就要考慮到數據處理方案，該部分可和開發一同討論確認。如果涉及到大量數據初始，沒有處理好的話，會是非常非常大的坑。
上線后監控方案
這部分很多才開始剛做產品同學很少會想到在產品設計中包含該部分，經過很多次項目復盤后發現該部分在產品設計中若能提前想到的話，對后續項目復盤，監控，迭代很有作用。主要目的為：監控上線后功能運轉正常；可以看業務的使用情況，便于數據統計；也可提前設計數據埋點，避免后續統計數據時沒有對應記錄。
一般監控分為兩部分：第一種為上線后1-2周的跟蹤方案，監控沒問題后就可以停止了；第二種就是一些關鍵的信息或者數據可作為日常定時監控進行。一般監控采用釘釘報警。
這部分其實有很大空間可以聊，這里就簡單提一下，主要給大家一定啟發，思考更為全面。
06 產品評審
產品方案設計完成后就進入到評審階段了，一般我會分為兩種，第一做完方案后先和業務簡單做個評審，確認一下設計的功能及操作流程，能滿足業務需求，還有沒有什么補充。確認之后再進行開發測試評審即可，評審通過后，確認開發和測試排期。
07 項目正式立項
我現在的團隊工作方式會在評審通過后再進行正式的立項，主要通過項目郵件發出，通知到業務方及涉及到的人員。包含內容為：項目背景，目的，需求內容，最重要是開發測試排期時間以及上線時間。
若有風險或者關聯性特別多的項目建議上線時間可以往后推預留1-3天，為未知風險做預留準備。
08 產品驗收
開發和測試完成后，在正式上線前，一般會預留一天左右的時間做產品驗收，這塊我主要是看下整體功能以及一些核心邏輯，是否和產品設計一致，若有問題再上線前提前提出和解決。
09 上線通知和培訓
項目上線后，需要發送上線通知，一般可通過郵件發送，主要包括上線時間（若有延期說明延期原因），上線安排，操作指南等，若功能比較復雜可安排做操作培訓。
10 上線后跟蹤
很多產品經理做項目，覺得上線后就完事了，以前我也是這樣的，但其實并沒有。上線后1-2周是非常關鍵的時間，這段時間主要關注點為：
- 上線后使用跟進：整體功能是否使用正常，bug反饋，業務運轉是否通暢等。之前做需求，上線后就以為完事了，后來發現業務根本就沒怎么用，沒有推起來。假如上線后1-2周業務沒有用起來的話，這個功能其實后面也很難再推起來了，所有上線后一定要推動業務使用，做好項目實施工作。
- 上線后數據及功能監控：這里就是說的對上線后監控方案的跟進，是否完成了預期的目標，把數據拿出來看是最有效的，同時也幫助產品做項目復盤及后期不斷的迭代。
到這里，我的B端產品工作流就結束了，也許看起來很復雜，過程很多，但這些其實都是經過各種坑總結出來了。B端產品工作難點并不是產品功能設計，更多的是業務流程及邏輯的思考和對項目的不斷復盤改進，才能更好地提升。上面這些點，大家可以看自己的實際工作情況做借鑒，希望能幫助大家在做項目時思考的更為全面。當然還有很多改進和補充的地方，歡迎大家評論一起討論。
本文由 @youly 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
感謝分享
收藏了， 感謝分享。