起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端PM的標準工作流程：從業務調研到產品落地
本文講述了業務調研、系統整體方案設計、系統細節方案設計一整套B端PM的標準工作流程。
B端產品本質是：解決組織痛點，實現商業價值。
B端產品經理，既要有對宏觀的把控能力，又要有對細節的專注力。
沒有細節的高度，會變成一個華而不實的空架子。B端產品的方案需要遵循以業務為中心，自頂向下的設計思路，從抽象到具體，逐漸勾勒出B端產品的輪廓。
一、緣起：業務調研
1. 概述
無論是一個項目還是一個真正的產品，都要明確的說出這個項目的目標或愿景是什么，這是產品的靈魂。
深入一線，深刻理解業務，是B端PM診斷業務問題，做出正確決策的前提；B端產品面向企業用戶，產品目標是更好的支撐業務運轉，調研目標是分析業務現狀和業務問題為方案設計提供支撐，最終解決企業的業務問題，提升運轉效率。
B端用戶是一個組織或者是機構，所以調研對象有涵蓋組織中的不同人員，從高級管理人員到一線執行人員，關鍵角色都要覆蓋.
2. 執行步驟
1.2.1 步驟一：找到&引導目標客戶
客戶需求=預期-現狀
a預期高于現狀時：客戶有明確的改進預期，通常會比較積極的配合需求調研。
在問題場景中，我們要識別外因還是內因，外因可能包括包括參觀考察、競爭對手動向、熱點及新趨勢；內因可能是自身業務的新需求或者遇到的問題；
B預期等于或低于現狀：客戶對變化表現不積極，對需求的調研表現出消極的態度，直接的調研方法無法獲取需求。
在機會場景中，需要對客戶的現狀進行深入了解，提出客戶可能為之心動的新預期，從而讓他們進入預期高于現狀的狀態。比如我們可以從以下幾方面引導：
- 新業務&新機會：與該領域領先企業的差距，從差距中尋找機會場景；跑在前面的同行的所作所為；他山之石可以攻玉，借鑒其他行業的商業邏輯；
- 新技術：了解新技術發展，從實際場景出發，技術可以解決什么問題&帶來什么機會？
- 新人群：每一代人有不同的特點，你服務的對象有什么習慣、什么價值觀？
1.2.2 步驟二：選擇客戶組織中的調研對象
- 對客戶的組織架構要有所了解，著重關注三類人，包括項目發起人、出資人和項目實施部門負責人；
- 選擇干系人代表，如果有多個干系人則從中選擇一位或多位典型的代表人以便聚焦；每個具體干系人，他的專業背景、職業背景、價值觀、組織地位、工作經驗等方面都有一定的特殊性，選擇一位或多位代表就能覆蓋各種有差異性的人；然后，了解干系人的基本信息，比如說他的職業角色是什么樣的？他的個人特點是什么樣的？他的聯絡方式是什么？
- 除了要關注干系人的影響度以外，還要關注他與項目的相關度；
- 關注具有一票否決的關鍵干系人，我們必須分析它的關鍵需求，提出針對性的雙贏的解決方案。
1.2.3 步驟三：確認調研方法
- 第一點，基于KPI分解，KPI指標體系通常直接體現了管理者的核心關注點，因此可以實現數據歸類，然后逐一切入，以發現潛在的關注點和阻力點；
- 第二點，基于工作主題分析，管理者通常會涉及多個不同的工作主題，比如說負責物資供應的經理會涉及采購倉儲等不同主題，先梳理被訪談對象的工作主題，以便訪談分而治之；
- 第三點，根據工作階段分解，有些管理者的工作可能會比較單一，如銷售主管，那么可以針對工作階段進行分析，比如說售前、售中和售后；
- 第四點，干系人關注點整理，橫向評估不同干系人之間的訴求，分析各個干系人的關注點之間是否存在沖突，制定相應的策略。
1.2.4 步驟四：給客戶講個好故事
1.2.4.1 給誰講故事
我們要向客戶證明系統的價值，而且向影響力越大的用戶證明，項目成功的概率就越高。
在大大小小各行各業的項目里都很難實現，每個干系人都滿意的完美結局，所以需要折中和平衡，項目其實就是一個博弈的游戲，重要的是要獲得足夠多的籌碼，也就是需要找到關鍵的籌碼持有者，贏得足夠多的籌碼就可以贏得項目，并且你不可能獲得所有的籌碼。
1.2.4.2 故事怎么講
1.2.4.2.1 問題和機會
客觀的從業務的角度來描述問題。
- 業務態：從業務的角度而不是系統角度來描述，問題-機會-成本-效益；
- 客觀性：描述問題想要有說服力，就保持客觀，不加主觀判斷；
1.2.4.2.2?影響了誰
要清晰到具體的人。描述的問題，給誰帶來了什么樣的影響；注意推理合理，層次清晰，具有說服力；
1.2.4.2.3?產生的后果
要匹配讀者的視角，與你講述對象的視角匹配。比如關注目標愿景的一般是高層，高層會關注的問題企業經營、管理模式、業務模式；
1.2.4.2.4?解決方案
說明主要的策略以及推薦這個方案。一切知道為什么的人，都會知道應該怎么辦，用一句話來提煉你方案的價值；
3. 注意事項
1）識別背后的問題
客戶容易說出方案，而不是問題，我們應該識別背后的問題。
因為，就算我們完美的滿足了客戶提的方案，最終未必會得到完美的反饋，因為客戶是問題專家，而非解決方案專家，他提出的方案未必能夠完美的解決他遇到的問題；
2）產品經理得學會功能排序
能用的功能用戶希望都有，人性本就是貪婪的，如果能多實現功能，那用戶一定會讓你實現，這時候產品經理讓用戶對想要的功能路線進行排序，確定他們最看重的東西，或者明確一下用戶可能會失去的東西，比如說加載速度變慢，操作流程變長，再來讓其判斷最想要的功能是什么；
3）站在用戶的立場
我們在建議解決方案時，應該站在用戶的立場，說明這種方案的優點，我們要作為問題的解決者，而不是需求的傳遞者；
4）始于故事，終于數據和邏輯
B端的產品無外是問題，機會，成本，效益四個關鍵點；在引導客戶時，我們應清晰描述整個軟件系統解決什么問題？創造什么機會？帶來什么價值？對于一些放之四海皆準的定性描述，其實沒有什么卵用，因為它失去了指向性，我們最好采用上文提到的故事方式，始于故事，終于數據和邏輯。
4. 階段性產物
輸出業務調研報告，包括：
- 業務現狀梳理：戰略定位和戰略目標、經營策略、管控模式、組織架構、業務流程
- 業務問題總結：關鍵業務問題梳理、問題解決思路(標明優先級)。
二、藍圖：系統整體方案設計
1. 概述
遵循自頂向下的設計思路，依次是設計核心業務流程，業務場景分析，應用架構，功能模塊演進藍圖；隨著設計的深入以及業務的開展變化，功能模塊可能需要修正和調整，但只要業務的本質模式沒有變化，功能模塊就不應該出現結構性的變化。
2. 核心業務流程梳理
2.2.1 執行步驟
流程分析的過程中，我們可以遵循以下流程：明確系統角色分工 — 明確角色執行的活動 — 確定各活動的順序執行/并行執行/異步執行的協作關系 — 識別流程的分支 — 識別流程的流轉物，比如表單、單據等；
業務系統是對線下已有業務流程的固化、優化和重構，應與客戶一起進行關鍵業務流程的梳理：
- 聽：客戶敘述時不打斷，不陷入任何細節，以最簡的方式勾勒出主體脈絡，把分支、產物關系、異常、審批、規則都放一邊。
- 問：沿著流程向客戶提問，看是否存在分支情況，然后邊問邊修正，得到一個中間稿。除了分支之外，還要問協作之間的產物，然后進行流程圖的補充；
- 讀：通讀流程，與客戶達成共識；
2.2.2 注意事項
業務流程的源頭是外部/內部服務請求，所以業務流程圖只允許有一個起點，但可以有多個終點；在定義流程的起點和終點時，首先理清端到端的概念，實際就是服務請求從提出到滿足的全過程；判斷一個流程是否完整，應該站在服務請求的立場，判斷服務請求是否滿足或者被拒絕。
劃分為主、變、支三種流程，主業務流是我們對系統的主訴求，變體業務流也是主流程的一種，但是不容易整合到一個流程中，支撐業務流是一些邊緣性的支持業務。
我們應該在做需求分析時應找出與系統邊界直接接觸的部分，進行邊界識別；業務流程有兩種邊界，一個是職能邊界，也就是跨越我們未涉及的業務域，二是系統邊界，就不屬于系統的那一部分。
將業務流程作為一個最小的交付單元，制定迭代計劃，做完全部業務流程劃分后，根據是否為主營業務，對優先級進行劃分。
如果流程中涉及審批流程，不要用崗位名稱加審批的樣式，而應該識別審批意圖，比如資金使用額度審批，因為不同組織可能審批的人不同。
2.2.3 階段性產物
我們可以用業務流程表來呈現我們的分析結果，包括流程名稱、簡要描述以及優先級（高、中、低）。
用泳道圖來描述完整的業務過程（包括線上和線下）。根據分析階段和讀者對象的不同，流程圖可以分為四級
- 組織級流程，即部門間協作，以部門為泳道；
- 部門級流程，展現崗位間的協作，以具體崗位為泳道；
- 個人級流程，定位崗位的操作規程，沒有這種泳道；
- 是子流程，如果個人級流程過于復雜，還可以再分層。
我們可以用跨職能流程圖/活動圖/時序圖來展示我們的分析結果；如果強調每個角色執行的活動，就選擇跨職能流程圖/活動圖，如果強調各角色間的協作和交互關系，就選擇時序圖。
繪制跨職能流程圖/活動圖時應該注意：業務流程繪制暫時不要考慮系統邊界，要畫出業務的全過程；活動的命名應該采用動賓結構，且主次活動根據讀者的不同只留一個；活動圖只有一個起點，但是可以有多個終點。
3. 場景分析&用戶故事
2.3.1 執行步驟
這一階段的關鍵點：就是說清楚產品針對誰提供什么樣的支持。
上一部分，業務流程的繪制，沒有考慮系統邊界；這一部分，我們需要站在用戶視角，梳理用戶在哪些場景下需要系統提供支持，哪些不需要系統支持，哪些是需要系統進行半支持的。
用戶故事的本質，就是希望用戶或者是用戶代表以作為某某某角色，希望通過系統解決方案或是功能要求，以便達成什么什么樣的業務目的，它的本質上是用戶視角。我們可以按照場景—挑戰一方案的邏輯進行場景&用例梳理：
- 場景細化，將場景細化為事件流，整理出用戶預期的正常步驟，然后寫出變化的情況；
- 問題或挑戰識別，針對每一個步驟，站在用戶的角度來思考他們會遇到什么問題，面對什么樣的挑戰；
- 針對這些問題思考系統應該提供什么功能。
2.3.2 注意事項
崗位和系統角色有時不是匹配的，可能存在一個崗位對應系統的多個角色。
2.3.3 階段性產物
我們可以用用例圖來簡略描述業務場景，繪制用例圖時應該注意的幾點：用例應該是一個獨立的，可匯報可暫停的單元；角色和角色僅存在一種關系，也就是繼承，用泛化表示；用例和用例之間存在三種關系，包含關系表示的一定會執行的公共子事件流，擴展關系表示不一定會執行的擴展事件流，泛化關系表示公共的事件。
我們可以用業務場景分析方案詳細描述業務場景，包括：
- 場景概述，說明該場景任務的名稱，該場景任務執行的目的，執行該場景的前置條件，任務出現的頻率；
- 場景分析，以場景/任務、問題/挑戰、方案/所需功能的形式整理分析結果，描述該場景最預期的步驟及每個步驟的問題；該流程的擴展事件流和相應的問題；最后描述這部分問題、挑戰所需要的功能。
- ?主流程外，對特殊場景的支持，它不是一種正常執行過程中的分支，而是一種例外情況（非必填）。
我們可以用例任務書來展示我們的分析結果，包括場景、任務名稱、任務描述、解決方案幾部分。
4. 應用架構設計
2.4.1 執行步驟
識別出用戶場景之后，就應該細化業務場景的事件，實現以用戶視角發現系統應提供的功能。但是對于對于復雜的業務系統，我們首先要進行子系統的劃分，來降低需求分析復雜度。
PM視角的子系統劃分和程序猿視角的子系統劃分是兩回事，程序猿站在技術實現的視角，而PM要站在用戶/業務視角來劃分子系統，這樣客戶容易理解，可以參與梳理過程，避免遺漏；
對于支撐管理業務的系統，最典型的就是先按照部門職能進行劃分。
理想情況下，獨立的業務部門應該有獨立的系統來支持工作；可以先畫出企業組織架構圖，比如中型教育培訓機構的四個典型部門：分別是教學部、教務部、市場部、財務部。
對應的子系統分別是：教學管理子系統、教務管理子系統、營銷管理子系統、財務管理子系統。
在此基礎上，再根據產品/服務進行分解，以教學管理子系統為例，可以繼續劃分為教研支持、課堂工具、助學工具等；
此外，確認子系統之間的關系，即“我”要“別人”提供什么？&“我”為“別人”提供什么？這一部分應該由產品負責人和架構師共同討論決定。
2.4.2 注意事項
對于已有的業務系統，我們先開發來支撐新的業務；就需要去了解哪部分是需要重新開發的，哪部分是需要改造原有的，哪部分是需要復用原有的。
2.4.3 階段性產物
我們可以用UML構件圖來展示此部分的分析結果。
三、筑夢：系統細節方案設計
1. 概述
在應用架構的基礎上要為每個系統設計功能模塊，要問自己兩個問題，這個系統應用于哪些業務場景？用戶可能在系統中做的操作有哪些？
2. 組織機構模型設計
對于組織機構模型這一部分來講，我們要考慮它當前的業務，以及未來可能存在的業務擴展——也就是各組織&角色是1對1、1對多還是多對多的關系，我們可以用E-R圖進行分析結果的呈現。
3. 角色權限設計
需要明確不同角色能訪問哪些頁面，能看到哪些數據，以及能做什么操作。
3.3.1 功能權限
每個系統角色都對應一個明確的權限集合，包括對菜單頁面元素等資源的訪問和操作權限。
如果用戶較多，我們可以對用戶進行分組，將角色和用戶組進行關聯。當有新用戶只需要設置其所在的用戶組，就會將用戶組關聯的權限賦予新用戶。
如果用戶角色需要批量調整，只需要調整用戶組和角色的關聯關系；而不用重新變到每一個用戶和角色沒有關系。
本質上講，一套軟件系統就是對不同數據對象的增刪改查的合集。
3.3.2 數據權限設計
角色在頁面能查到的數據范圍就該角色的數據權限，能查到的數據范圍不是指能看到的數據字段，而是能查出來的數據集合。比如針對訂單列表頁，數據范圍可能是某個城市的訂單也可能是某個賬戶下的訂單。
4. 頁面流轉圖設計
頁面流轉圖是向軟件產品的頁面設計更進一步的方式，是一種很好的銜接方式。
可以基于頁面流轉圖進行討論、修正，比原型畫出來再討論、修正，更高效。
頁面流轉圖描述的是：用戶完成某項工作需要訪問的頁面以及頁面的跳轉順序。
我們繪制頁面流轉圖時，都是針對某個單一角色在某個特定場景下的頁面訪問，和跳轉邏輯，從用戶的視角梳理一遍所有的相關頁面。每到一個新頁面時都要思考：需要先做一個頁面，還是可以復用原有頁面，最終整理出系統涉及的所有的頁面的初稿。
有一點需要注意的是：不是所有的頁面，都來自頁面流轉圖，有些頁面是獨立于總體流程之外的。
5. 原型界面設計
當一套業務系統上線之后，后期迭代就基本不需要UIUE了。
前端工程師參考相關圖，就可以直接進行前端頁面的開發，業務系統的產品經理一般還是要自己做交互。
很多產品現在喜歡在界面設計啊，交互設計上有創新，其實沒必要。因為B輪產品的用戶需要的是——解決業務問題，提高效率。
交互體驗并不是他們最在意的，而復雜的界面和交互會增加研發的工作量。PS：axure還是最經典的原型設計工具，然后用藍湖進行一個實效性的溝通效果比較好。移動端的話可以用墨刀，比較高效，頁面流轉圖用墨刀也比較好制作。
保證B端交互效果的尼爾森原則（雖然網上已經隨處可見了，但是為了大家看著方便，還是搬過來了）：
3.5.1 反饋原則
系統應該在合理的時間，用正確的方式向用戶提示或反饋，目前系統在做什么？發生了什么？
人機交互的基本原則就是讓系統和用戶之間保持良好的溝通和信息傳遞。比如安裝程序時顯示進度條，比如說上傳文件時顯示進度條，比如說提交表單時，如果失敗，提示錯誤原因。
3.5.2 隱喻原則
系統要采用用戶熟悉的語句短語符號來表達意思，遵循真實世界的認知習慣，讓信息的呈現更自然與辨識和接受，
在人機交互設計中程序的溝通和表達功能的呈現都要用最自然的用戶易于理解的方式，而避免采用計算機程序語言的表達方式。
3.5.3 回退原則
用戶經常會不小心操作錯誤，需要有一個簡單的功能讓程序迅速恢復到錯誤發生之前的狀態。
軟件系統應該有撤銷，重做這些功能。比如說word，美圖秀秀的撤銷，比如說點擊刪除關閉按鈕后，讓用戶的二次確認，比如說電商平臺允許在一定的規則下取消訂單。
3.5.4 一致原則
同樣的情景環境下，用戶進行相同的操作，結果應該一致，系統或平臺的風格體驗也應該保持一致。
我們應該遵循慣例，不要盲目的標新立異。比如說office軟件，各個產品就設計風格和界面布局就保持了高度的一致。
3.5.5 防錯原則
系統要避免錯誤發生，要好過出錯后再給提示。
進行設計師首先要考慮如何避免錯誤發生，其次再考慮如何檢查校驗異常。有時候為了防止用戶重復提交，然后第1次點擊之后就只會，比如說，調整二次確認對話框中的是否兩個按鈕。所以很多情況就把否放在前面。
3.5.6 記憶原則
讓系統的相關信息在需要的時候顯示出來，減輕用戶的記憶負擔。
比如說很通用的APP或PC的搜索引擎會記錄用戶的搜索歷史。
3.5.7 靈活運用原則
現在用戶中中級用戶往往最多出高級相對較少，系統應該為大多數人設計，同時兼顧少數人的需求，做到靈活易用
系統就要做簡單易用，讓所有的中級用戶用起來得心應手，也應該提供必要的幫助，讓入門級的初級用戶順利上手，還需要支持靈活的個性化設置，讓高級用戶以進階的方式使用系統。比如說word的，強大的配置功能。
3.5.8 簡約設計原則
對話中不應包含無關的或沒必要的信息增強或強化一些信息，就意味著弱化另外一些信息。
重點太多就相當于沒有重點，所以要把握好突出標記的尺度。
3.5.9 容錯原則
錯誤信息應該用通俗易懂的語言來表明，而不是向用戶提示錯誤，代碼提示錯誤，信息是要給出解決建議。
就比如說在填寫表單的時候，不要等到提交的時候再提示用戶錯誤，而是在填寫的時候就，嗯，說明，填寫要求，對不符合格式要求的，直接給提示。
3.5.10 幫助原則
對一個設計良好的系統用戶往往不需要經過培訓就能輕松的上手使用，但是提供幫助文檔依然是很必要的幫助信息應該與檢索，通過明確的步驟引導用戶解決問題，并且不能太復雜。
B端產品的復雜性要比c端高很多，所以對于B的人品來講，幫助文檔依然是有必要存在的。
6. 業務報表設計
業務報表的核心價值是掌握事實，然后發現問題，分析原因，產生對策。
產品經理要和業務人員一起關注完整的體系化指標建設，設計有實用價值的報表。
觀察分析問題的視角和思路是報表設計核心，絢麗的交互只是次要的外表。
產品經理要參與業務分析工作，建立業務分析監控體系，并負責實現線上化。
前三個環節是產品經理要直接負責的環節，包括構建分析體系，定義觀察指標設計呈現形式；后三個環節是報表用戶使用報表的過程，包括跟蹤指標變化，分析變動原因，根據處理問題。
產品經理需要理解用戶使用報表的方式，然后和用戶持續的溝通；不斷的優化報表的設計，只有從用戶使用報表和分析問題的角度考慮才能設計出優秀的報表產品。
3.6.1 構建分析體系
之所以設計報表，就是因為要對某個業務訴求進行監控和分析。
在構建分析體系之前，要明確分析的目的是什么——即我們需要通過分析發現哪些方面的問題。
然后再思考我們應該采用什么方法來識別診斷這些問題，可能的困難是什么。
構建分析體系必須建立在對業務的深刻準確的理解之上，要和一線管理團隊多溝通；可能很多問題的分析框架和思路已經被一項工作中發現并有效實踐了，一定要善于發掘，并參考借鑒。
3.6.2 定義觀察指標
理清了分析框架和思路，下一步要確定觀察指標，設計具備明確業務含義的指標來考量業務。一般會從幾個大方面拆分出幾方面的觀察指標，然后考慮是否將指標進一步的拆解為二級升級三級指標，從而在更精細的維度觀察分析業務，更準確的反映業務特征。
3.6.3 設計呈現形式
確定了觀察指標以后，我們就要思考以什么樣的方式來呈現這些指標，以便用戶能夠準確快速的理解掌握指標及變化特征。比如說是采用數據表呢，還是柱狀圖呢，這個環節要核實用戶都討論尋找最佳的呈現方式。
可能，作為一名業務管理人員，各種核心數據都是了然于心的?？匆姰斍皵底侄季椭烙惺裁串惓?，管理人員需要的只是干凈的界面和能夠實時更新的，準確數字，其他炫酷的交互效果不需要。
3.6.4 跟蹤指標變化
管理要用數據說話，報表數據就是診斷和決策的依據。管理人員要認真對待分析報表中各種數字的變化波動，如果只是走馬觀花的瀏覽報表，看不出任何問題，報表就失去了意義。
作為一名管理人員必須要對數字非常敏感，能夠快速感知并解讀數字背后的變化和問題，這是出色管理人員必須具備的素質。
3.6.5 分析變動原因
如果指標發生了明顯的波動，需要跟進分析波動的原因，分析工作可以由數據分析師完成，團隊最好每周分析上周的數據走勢變化背后的原因，以便及時準確的掌握業務變化情況。
3.6.6 跟進處理問題
分析出問題后，下一步就是給相關部門或人員安排工作解決問題也就是報表設計的初衷，報表設計的第3個環節設計呈現方式。除非有很特殊的充電需求，其他都強烈地采用成熟的報表引擎，比如說之前我們用了e-chart；
需要注意：管控點、指標、報表是三個概念。
不同領導、不同企業可能用同一管控點、不同的指標和不同的報表，來實現同一管控目的。
所以，最重要的是把握用戶想要什么信息，它的管理意圖是什么？
管控點和報表之間是存在斷層的，實際管控點和指標之間可能是多對多的關系，部分指標是可以復用的。
作者：黎小明；微信公眾號：PM黎小明
本文由 @黎小明 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Pexles，基于CC0協議
- 目前還沒評論，等你發揮！
