手把手教你畫流程圖

更多內容關注公眾號：SAP Technical

一、流程圖的意義

產品經理畫流程圖有兩個作用, 分別是：

1）用於和非研發部門交流: 決定人員都做什麼工作？描述公司的核心業務。例如使用者下單後，就涉及到物流部門進行發貨，系統進行開發票等工作。

2）用於和開發人員交流：對於系統開發人員來講，更關心的是這個訂單系統的流程是什麼。因此需要更多的細節描述，如下單之後如果出現供貨不足無法發貨，該怎麼處理？

我們下一篇就會展開不同目的如何繪製流程圖，本篇主要目標是繪製表達無錯的流程圖。

對於產品經理則要重視流程圖的繪製。

首先，很多產品經理往往一上手做互動頁面原型。但這樣往往因為流程想不清楚，導致原型圖需要重畫。所以注意要先畫流程圖，再畫原型圖。

其次，研發經常批評產品經理的地方就是產品經理沒有邏輯，而畫流程圖就是建立你的邏輯的一種方法，也最終用在面試表達，產品評審發言中。

下面我們就展開說明流程圖怎麼畫。

二、流程圖如何畫？

流程圖是為了完成某一任務而描述的相關活動以及這些活動的執行順序。UML稱流程處理的圖為活動圖，但為了便於討論後面還稱其為流程圖。

下面我們以訂單流程為例子，帶領大家一步一步畫出大廠標準的流程圖。整個流程涉及到從使用者下單到收貨的流程。下面就是這個訂單流程。

其邏輯是使用者下單後，物流人員就需要送貨到家，使用者收貨後，在點選確認收貨，即完成整個訂單。這裡就涉及到以下概念：

1. 活動的概念

這裡物流人員送貨到家和使用者確認收貨，都體現了一個人做了什麼事情，都會涵蓋“主語+謂語+賓語”。“使用者”是主語，“點選”是謂語，“確認收貨”是賓語。

而人做了什麼事情，就體現了一個“動作或操作”。而UML則稱其為活動，其實和動作是同樣的意思，後續我們都用活動這個概念。

活動的標準畫法是帶圓角的矩形框，裡面寫具體的活動，活動內容寫成“主語+謂語+賓語”，賓語或主語根據說話習慣可以考慮省略。

活動之間用帶箭頭的線連線在一起，稱其為“轉移”。表示做完了一個活動就可以轉移到下一個活動，比如物流人員送貨到家後，使用者才會確認訂單完成，否則就無法進入下一個活動。

2.  起點和終點概念

一個流程圖有一個“起點”，作用是表明一個流程從這裡開始。起點畫法是個實心小圓。

一個流程圖也有“終點”，作用是表明上一步的“活動”就是這個流程的結束，對於上面的訂單流程而言結束的活動就是“使用者確認收貨”。這個活動完成後，整個流程就算完成了。終點畫法則是一個實心圓加一個空心圓。

注意：起點必須有，而終點可以省略不畫或有多個。終點畫上的好處是可讓別人知道你考慮了終點因素。但有的流程涉及到的終點過多，並且結束顯而易見，畫上就顯得累贅。

3. 判斷和並行概念

現在我們已經能夠畫出了流程圖。但我們發現這個流程會有很多細節需要補充，這就是我們接下來要介紹的判斷和並行概念。我們以問題為出發點，來看看如何完善流程圖。

如果訂單針對“網上支付或貨到付款”有不同的處理過程如何表達？——用判斷標誌來解決。

此時物流人員就需要對訂單進行判斷，如果是網上支付（送貨前支付）則直接給貨物到使用者，否則必須先讓使用者支付現金或先刷POS機後，再給貨物，此時流程圖如下：

這個判斷點就用菱形符號來表示，此時是一個進入多個出，並且在出的線條上用方括號表明判斷條件。這裡的：

條件一是“如果使用者是網上支付”（簡稱：網上支付），則相應的動作是“物流給貨物到使用者”；

條件二是“如果使用者是貨到付現金”（簡稱：現金支付），則相應的動作是“物流收取現金”。

條件三是“如果使用者選擇POS支付”，則“物流用POS機收錢”。

注意和其他流程圖的菱形符號中間要寫字不同，這裡不允許在菱形符號中間寫任何字，但表達的意思是一樣的。菱形位置裡面其實是可以寫“物流確認支付情況”，寫文字易於理解但是略顯累贅。

再如電商遇到的如果使用者支付完畢，有的時候會反悔並告知商家。對於商家也會存在兩種選擇，“同意則取消訂單”或“拒絕則堅持發貨”。這兩種表達方式都可以達到同樣的效果，只是方法不同。

瞭解了和傳統流程圖的不同表示方法後，對於UML體系，除了上面介紹的用帶菱形的表示方法外，另外一個方式是不加入菱形判斷圖示，如下圖所示：

這兩種表達方法都是可以的，但需要注意要在轉移線上寫出判斷條件。對於本案例加入判斷的菱形圖示會更加清晰，此時明確物流人員在這裡要進行一個判斷。

如果使用者還要同時開發票則流程怎麼表達？——用並行標誌來解決。

現在很多的送貨是貨物和發票放在了一起一併寄送過去，或者支援電子發票的方式。但是還有一些企業開紙質發票，並且貨物和開發票地並不一致。這個時候就需要貨物和發票分別寄送到使用者手裡。

此時意味著兩撥物流人員一個在送貨和一個在寄送發票。這裡就是一個並行處理，表達方式如圖所示：

畫法是畫一個粗橫線，再加上一個進入和多個出的轉移線條。對於本例子，出的兩個分支流程是配送貨物和發票寄送，此時同步處理但並不在意誰先做誰後做。

4. 匯合和合並概念

網上支付和現金支付送任意一個完成就算完成如何表達？——用合併來解決。

此時只要是網上支付或現金支付任意一個方式就算完成了支付。即條條大路通羅馬，我們只要一個路徑能到達，就可以進行下一步了，此時有兩種表達方法：

第一種方法直接通過三條轉移線連線到下面的活動即可，這個也是我們在前面看到的。第二種方法是畫一個菱形並且多進一出。注意這個菱形符號在這裡不是表示要判斷，只是借用了菱形符號而已，因此也不必線上條旁邊加入判斷條件。

實際上第二種畫法是UML的標準畫法。但畢竟看流程圖的人有的不是程式設計人員，畫上會讓人誤解，為了便於溝通可以選擇第一種畫法。但是在看到網上的流程圖加入合併的菱形標誌的時候，要意識到這裡不是進行判斷，而是在做合併。

這裡另一個例子就是使用者可點選確認收貨，而系統也可以自動確認收貨，也是那個先確認收貨都算收貨，訂單即最後完成。

發票和商品使用者都收到才算訂單完成如何表達？——用匯合來解決。

前面我們講了貨物和發票是分別寄出的，對於使用者必須是發票和貨物同時收到了才會點選“確認收貨”，兩者缺一不可。具體表示見下圖：

表達方式是一個粗橫線，再加上多個進入和一個出。進入的分支是送貨物和送發票，此時同步處理但並不在意誰先做誰後做，但匯合的時候必須要都完成才可進入到下一步。

另一個例子就是吃飯上菜的例子。我們到餐廳菜是分別上的，只有都上完了才算完成了。而在野路子的流程圖中，是沒有辦法表達這個並行匯合處理的。

通常並行和匯合成對出現，此時並行執行兩組活動，但必須兩組活動都完成才能進入下一環節。而上圖也就是一個完整的流程圖了。

5.  流程圖的總結

流程圖表示方法最後總結如下表：

三.  通過問題學概念

流程圖的繪製方法和邏輯看完了之後，我們再來看一些來自網上的流程圖，逐一明確一下常見的問題是什麼？好讓我們避免同樣的錯誤。

案例一：流程圖中不應有非活動的內容

上面的流程圖是說產品經理的工作包括需求收集，需求討論和需求評審等工作，併為此畫了流程圖進行闡述。思考一下，這個流程圖的問題是什麼？

我們按照流程圖的概念來看，流程圖要求每個框起來的都是一個活動，活動的典型即存在“主+謂+賓”。

在這裡面“有效需求、已有功能和需求池”都不是一個活動，這裡都是在說需求的不同型別和功能概念。真正體現活動的是產品經理進行“收集需求，討論需求和需求評審”。

而這裡大家會說，我要體現“有效需求和需求池”等概念該怎麼做？

那麼可以這樣描述：我們可以將需求劃分為新需求+老需求，其中新需求產品經理需要過濾成有效需求和無效需求。而進入需求評審環節的是新需求的有效需求和老需求並放入需求池中，在這個環節我們決定本期開發的需求是那些。

上面這種描述，如果你理解了UML的物件導向的思考方法，就可以有效來描述了。這個以後也會有專題來講。另外其實知識是相通的，如果按照金字塔原理進行邏輯思考，也能得出上面的描述內容。

通過這個案例，我們發現將需求處理的方案和需求評審流程的描述混在一起，會讓受眾群體迷惑，而如果分開描述則會清晰很多。

案例二：流程圖不同於狀態圖

這是一個買家下單和付款的流程。這裡仍然按照“主謂賓”來拆分，我們發現待付款不是一個活動，而是一個狀態。而橫線上的“買家下單”才是個活動（即使用者點選下單）。

因此這個仍然不是流程圖，在UML裡更適合用狀態圖來表達。如果此時按照狀態圖的角度來看，這裡也是有問題的，我們以後會有專題來講狀態圖。

案例三：流程圖的邏輯需要仔細思考

這個流程圖大家看是從使用者下單到供應商供貨的流程，我們假設這個就是京東或天貓的訂單流程。在這裡“生成送貨單，以及使用者選擇支付方式，收款”等環節存在邏輯問題，大家想想邏輯問題是什麼？

此時我們回憶一下我們在購物APP上如何下單的？這個流程是：

1）使用者從購物車點選“去結算”，就會開啟“提交訂單頁面”。

2）在“提交訂單頁面”允許使用者選擇網上支付還是貨到付款，以及編輯送貨地址，此時點選“提交訂單”按鈕。

3）則系統生成訂單，並展示給使用者“支付頁面”。

4）在“支付頁面” 允許使用者可以選擇某銀行卡或支付寶後，再點選“銀行卡支付”按鈕。

5）此時系統展示“輸入網銀（或支付寶）密碼”的頁面。

6）在“輸入密碼頁面”  使用者“輸入賬戶密碼”後就完成了訂單支付。

回憶完整個流程後，我們會發現如下問題：

問題一：“使用者選擇支付方式，之後收款，中間可以取消訂單”這個概括就不正確。

實際上是“在提交訂單頁面，使用者先點選提交訂單；之後彈出輸入密碼頁面，使用者輸入密碼完成支付”。此時在點選提交訂單後不輸入支付密碼時，使用者可以到個人訂單列表裡面選擇“取消訂單”。因此概括起來是：使用者提交訂單，之後使用者支付訂單，在提交訂單後可以取消訂單。

問題二：生成送貨單和其他活動不是並列關係。

系統的實際工作過程是“使用者點選提交訂單”後，系統就會生成訂單，並丟擲一個讓使用者來支付的頁面。這個生成的訂單我們可以在訂單列表裡面看到，針對待付款的訂單使用者可以進行支付或取消訂單。所以生成送貨單和選擇支付方式是不是同時進行的關係。

通過這個案例其實發現流程訓練首先需要仔細思考每個環節。其次這個涉及到對流程對每一步如何進行抽象的問題，如何畫出人人都喜歡都明白的流程圖的問題。這也是第二篇要重點講的地方。

四.  總結

通過本篇文章，大家瞭解了標準的流程圖的畫法。

這裡首先需要理解活動，判斷、並行、並行匯合和合並等基本概念。其次通過三個例子，說明如何正確表達流程圖，而不要學了假的流程圖。

其次發現流程圖只是其中的一種邏輯思考和表達方式，還有很多其他的方式需要進一步解鎖。

最後舉例的三個流程圖指出了問題，但沒有畫出來。大家可以留言說說你的思路、說說認為的流程圖怎麼畫。