產品流程圖畫法——畫出更清晰準確的流程圖

大家有沒有發現，別人設計的流程圖都很難閱讀。穿插著各種現實中的人工步驟、產品的交互動作、系統的判斷邏輯，沒有考慮到實際閱讀者所關心的信息。產品規劃前期，最重要的就是流程梳理，否則接下來的事情無法順利開展，甚至從一開始就是bug。

針對決策者：描述工作流轉過程；

針對使用者：描述界面和狀態的變化；

針對開發者：描述規則和數據的變化。

並沒有一個流程圖可以同時讓三類人看明白，因此我們需要畫出三個流程圖：業務流程圖、交互流程圖、邏輯流程圖。

常用工具: xmind，visio，proccessOn

XMind是一個非常靈活的工具，大部分情況下用於製作腦圖，其實用它來做流程圖也非常好用和自由，並且對於複雜的網狀流程能夠更流暢的表達。但對於需要嚴格區分泳道的情況，它也無能為力，因此也要根據實際情況選擇合適的工具。

業務流程圖

描述人或部門之間的協作關係、各自職責，以及流轉過程中傳遞的信息是什麼。本質上，業務流程就是企業的SOP（標準作業程序）。只不過在SOP的基礎上，思考如何使用IT系統更有效的完成標準作業。

業務流程圖的主要溝通對象是產品的需求提出者和實際使用者。但是對於設計者和開發者，並不足以讓他們清晰理解如何執行，還需要另外兩個流程圖。

上圖是一個描述S2B產品的訂單和物流業務流程，將門店訂貨和分倉訂貨兩個業務場景合併在一個圖中。其中，總部跟單員、CM、各城市分倉，既要負責門店訂貨，也要負責分倉訂貨。還有一個橢圓形的節點，由於這個動作與「總部複審」不在同一時間觸發，因此獨立成一個節點，否則下面的流程無法正常梳理。這裡用什麼形狀不重要，我們並不是畫UML，只要區別與其他形狀即可，不拘泥於形式規範。

另外，大家會發現綠線和紅線，都是門店訂貨業務場景。但是由於合作的倉儲公司並不使用該系統，兩個環節在系統操作上是斷開的，因此分為兩條線來描述。

綠線，描述門店訂貨到分倉出庫的流程：

1. 門店訂貨，流轉到BD處理；
2. BD初審後，流轉到總部跟單員；
3. 總部跟單員複審，24點匯總數據後，同時執行2個步驟，
1. 匯總數據發送給倉儲公司，並且總費用打款給倉儲公司
2. 將各個城市的取貨信息通知給CM
4. 倉儲公司將匯總數據，分發給各個城市分倉庫

紅線，描述分倉出庫到門店收貨的流程：

1. CM分發配送任務給BD
2. BD到分倉取貨裝車
3. BD配送到店、簽收確認

藍線，描述CM向總部訂貨的流程：

1. CM提交訂貨單
2. 總部跟單員通知工廠發貨
3. 工廠發物流到各城市分倉

其實，業務流程圖對產品經理的要求非常高，需要充分了解實際生產作業過程、具備足夠的想像力，以及對交互和系統邏輯的熟悉。假如沒有充分理解，可以先閱讀下面兩條，再回過頭來再分析一遍。

交互流程圖

描述用戶操作過程的界面切換、狀態變化、內容變更。有一個通用型的資料提交和變更業務的例子，適用於需要審核後才允許公開的資料信息，B端和C用戶基本通用。

看起來是不是簡單很多？我也不必具體描述裡面的含義。這個流程圖，也經常會用泳道的方式來畫（抱歉，Visio我用的不太遛）：

圖上的每個節點都是描述具體的動作或界面元素，用顏色或泳道來區分前後台的操作環節。交互流程圖對於原型設計和界面設計，起到很直接需求描述作用。但是，這種流程圖對於開發者來說，還是需要他們自己去分析如何實現代碼邏輯。不同的開發者，會採用不同邏輯來實現。往往，我們還需要描寫一段PRD來說明，下面的邏輯流程圖，將會大大簡化PRD的冗長文字。

邏輯流程圖

描述代碼執行過程中的邏輯判斷和數據讀寫。當然，要把邏輯流程圖畫對，必須對代碼和資料庫實現的原理有所了解。否則，畫的流程和寫的說明本身就有一堆bug，可以和開發者溝通一起完成邏輯流程的梳理。

流程有點長，因此豎著走。首先要解釋【】裡面指的是數據表，在這張表裡生成或更新數據。【門店信息】和【申請資料】分成了兩張表來存儲數據，為什麼？因為當申請變更的時候，已經公開的資料不能變，並且拒絕後重新提交，後台需要查詢每一次填寫資料的歷史記錄。

下面從上到下分解：

1. 三個動作：提交新資料、變更申請、被拒絕後修改。在連接線上明確說明：
1. 提交新資料時，是一個空表單。當然，我們可以自動填充當前所在地區，這個細節在設計原型的時候再考慮。
2. 提交變更申請時，表單內填充【門店資料】（已經公開）的欄位。
3. 被拒絕後重新提交，表單內填充「被拒絕的【申請資料】」的欄位。
2. 提交審核後，如果是提交新資料，將先生成一條新的【門店資料】。然後，無論是哪個動作，都會生成一條新的【審核資料】。這個環節，是流程中最關鍵也最容易出錯的地方。我們先繼續往下看，再分析為什麼容易出錯。
3. 流轉到後台客服操作。通過以後，【審核資料】狀態變更，【門店資料】根據【審核資料】的欄位更新，狀態也變更。如果是拒絕，只變更【審核資料】的狀態，不處理【門店資料】。
4. 其他節點很容易理解，就不展開描述了。

現在，我們來分析，第2點為什麼容易出錯。我有一個很重要的設計原則：簡化用例。初次提交資料時，如果不生成【門店資料】，必須要在【審核資料】中記錄另一組狀態：「新資料、變更、修改」，到客服處理環節判斷這一組狀態。這樣一來，用例將會更加複雜，switch的case增多。無論是畫產品原型，寫邏輯代碼，還是做功能測試，工作量都將增大，也就意味著出bug的幾率更大。這一個小細節不起眼，但是每個業務都不考慮「簡化用例」原則的話，整體工作量將會大幅增加，系統的穩定性也會大受影響。那麼，在提交審核這一步，來判斷是否生成【門店資料】，只需要在代碼的最開始做一次判斷，後面的分支（case）將會更少。

（註：用例，包擴交互用例和測試用例，是用文字的形式描述一個功能的執行步驟。在敏捷開發中，最多只會撰寫一些關鍵功能的用例。專業測試團隊，可能會寫幾百幾千個測試用例。）

對交互流程圖和邏輯流程圖理解以後，大家可會回頭再去看看業務流程圖。不同級別的產品設計者，可以循序漸進，從交互流程圖開始梳理。三個流程梳理方式，其實和從MRD到BRD到PRD的產品規劃方法是一致的。