流程圖有沒有限定的标準？正确規則的流程圖有什麼規範？本文将從三個方面來作出解答：流程圖的意義、流程圖如何繪制、常見的流程圖問題。
作為一個産品經理，畫流程圖是必備的技能。如制定訂單處理的流程，制定商品審核的流程，制定用戶開銀行賬戶的流程等。
也有非常多的文章在介紹如何畫流程圖。我們發現有各種畫法，也有各種概念。這裡産生一個問題：到底什麼樣的流程圖是正确的？有沒有标準？
無标準野路子的流程圖必然會産生歧義，必然是思路混亂的。比如以下兩個流程圖就都是有問題的，并導緻表達混亂。
有問題的流程圖
有問題的流程圖
其實流程圖是有标準的，這就是UML（統一建模語言）制定的标準，被其稱為活動圖。并且這個标準被微軟和IBM等大廠采用。我們通過本文就能夠知道，上面兩個流程圖的問題了。
既然了解到很多流程圖是有問題的，所以要畫好也不是那麼容易。所以我也會分三篇文章來介紹UML的流程圖怎麼畫，分别是：
第一篇：如何制作正确規則的流程圖？
第二篇：如何制作人人喜歡的流程圖？
第二篇：流程圖的概念解析
其中第一篇會讓大家理解流程圖的正确姿勢和語言。第二篇會手把手教讓大家繪制粗細得當，人人喜歡的流程圖。第三篇是概念解釋，破除業務流程圖，任務流程圖和功能流程圖的誤區。
要先學流程圖的規則是什麼，這就好比下象棋。我們首先要理解下棋的規則是什麼，然後再學習如何去赢得比賽的策略。如果反過來，這就好比知道怎麼下棋，卻不了解基本規則一樣。規則枯燥但還是要先來學習的。
本篇文章包括：流程圖的意義、流程圖如何繪制、常見的流程圖問題。
對于産品經理要重視流程圖的繪制，這背後是邏輯清晰的表達和思考。
首先，很多産品經理往往一上手做交互頁面原型。但這樣往往因為流程想不清楚，導緻原型圖需要重畫。所以要先畫流程圖，再畫原型圖。
其次，研發經常批評産品經理沒有邏輯。而畫流程圖就是建立你的邏輯的一種方法，也最終用在面試表達，産品評審發言中，下面我們就看看如何畫。
流程圖是為了完成某一任務而描述的相關活動的執行順序。UML稱流程圖為活動圖，為了便于讨論，後面還稱其為流程圖。
下面我們以訂單為例子，帶領大家一步一步畫出流程圖。整個流程涉及到從用戶下單到收貨的流程。下面就是這個訂單流程：
其邏輯是用戶下單後，物流人員就需要送貨到家，用戶收貨後，在點擊确認收貨，即完成整個訂單。這裡就涉及到以下概念：
這裡物流人員送貨到家和用戶确認收貨，都體現了一個人做了什麼事情，都會涵蓋“主語 謂語 賓語”。“用戶”是主語，“點擊”是謂語，“确認收貨”是賓語。
而人做了什麼事情，就體現了一個“動作或操作”，而UML則稱其為活動。其實和動作或操作是近似的意思，但活動的概括更為廣泛。
活動的标準畫法是帶圓角的矩形框，裡面寫具體的活動，活動内容寫成“主語 謂語 賓語”，賓語或主語根據說話習慣可以考慮省略。
活動之間用帶箭頭的線連接在一起，稱其為“轉移”。表示做完了一個活動就可以轉移到下一個活動，比如物流人員送貨到家後，用戶才會确認訂單完成，否則就無法進入下一個活動。
一個流程圖有一個“起點”，作用是表明一個流程從這裡開始。起點畫是個實心小圓。
一個流程圖也有“終點”，作用是表明上一步的“活動”就是整個流程的結束。對于上面的訂單流程而言結束的活動就是“用戶确認收貨”。這個活動完成後，整個流程就算完成了。終點畫法則是一個實心圓加一個空心圓。
注意：起點必須有，而終點可以省略不畫或有多個。終點畫上的好處是可讓别人知道你考慮了終點因素。但有的流程涉及到的終點過多，并且結束顯而易見，畫上就顯得累贅。
現在我們已經能夠畫出了流程圖。但我們發現這個流程會有很多細節需要補充，這就是我們接下來要介紹的判斷和并行概念。我們以問題為出發點，看如何完善流程圖。
“網上支付或貨到付款”有不同的處理則怎麼表達？——用判斷标志來解決。
此時物流人員就需要對訂單進行判斷，如果是網上支付（送貨前支付）則直接給貨物到用戶，否則必須先讓用戶支付現金或先刷POS機後，再給貨物，此時流程圖如下：
這個判斷點就用菱形符号來表示，此時是一個進入多個出，并且在出的線條上用方括号表明判斷條件。這裡的：
條件一是“如果用戶是網上支付”（簡稱：網上支付），則相應的動作是“物流給貨物到用戶”；
條件二是“如果用戶是貨到付現金”（簡稱：現金支付），則相應的動作是“物流收取現金”。
條件三是“如果用戶選擇POS支付”，則“物流用POS機收錢”。
注意：和其他流程圖的菱形符号中間寫字不同，這裡不允許在菱形符号中間寫任何字，但表達的意思是一樣的。菱形位置裡面其實是可以寫“物流确認支付情況”，寫文字易于理解但是略顯累贅。
再如電商中如果用戶支付完畢，有的時候會反悔并告知商家。對于商家也會存在兩種選擇，“同意則取消訂單”或“拒絕則堅持發貨”。這兩種表達方式都可以達到同樣的效果，隻是方法不同。
了解了和傳統流程圖的不同表示方法後，對于UML體系，除了上面介紹的用帶菱形的表示方法外，另外一個方式是不加入菱形判斷圖标，如下圖所示：
這兩種表達方法都是可以的，但需要注意要在轉移線上寫出判斷條件。對于本案例加入判斷的菱形圖标會更加清晰，此時明确物流人員在這裡要進行一個判斷。
如果用戶還要同時開發票則怎麼表達？——用并行标志來解決。
現在很多的送貨是貨物和發票放在了一起一并寄送過去，或者支持電子發票的方式。但是還有一些企業開紙質發票，并且貨物和開發票地并不一緻。這個時候就需要貨物和發票分别寄送到用戶手裡。
此時意味着兩撥物流人員一個在送貨和一個在寄送發票。這裡就是一個并行處理，表達方式如圖所示：
畫法是畫一個粗橫線，再加上一個進入和多個出的轉移線條。對于本例子，出的兩個分支流程是配送貨物和發票寄送，此時同步處理但并不在意誰先做誰後做。
網上支付和現金支付任意一個完成就算完成如何表達？——用合并來解決。
此時隻要是網上支付或現金支付任意一個方式就算完成了支付。即條條大路通羅馬，我們隻要一個路徑能到達，就可以進行下一步了，此時有兩種表達方法：
一種方法直接通過三條轉移線連接到下面的活動即可，這個也是我們在前面看到的。第二種方法是畫一個菱形并且多進一出。注意這個菱形符号在這裡不是表示要判斷，隻是借用了菱形符号而已，因此也不必在線條旁邊加入判斷條件。
實際上第二種畫法是UML的标準畫法。但畢竟看流程圖的人有的不是編程人員，畫上會讓人誤解，為了便于溝通可以選擇第一種畫法。但是在看到網上的流程圖加入合并的菱形标志的時候，要意識到這裡不是進行判斷，而是在做合并。
這裡另一個例子就是用戶可點擊确認收貨，而系統也可以自動确認收貨，也是那個先确認收貨都算收貨，訂單即最後完成。
發票和商品用戶都收到才算完成如何表達？——用彙合來解決。
前面我們講了貨物和發票是分别寄出的，對于用戶必須是發票和貨物同時收到了才會點擊“确認收貨”，兩者缺一不可。具體表示見下圖：
達方式是一個粗橫線，再加上多個進入和一個出。進入的分支是送貨物和送發票，此時同步處理但并不在意誰先做誰後做，但彙合的時候必須要都完成才可進入到下一步。
另一個例子就是吃飯上菜的例子。我們到餐廳菜是分别上的，隻有都上完了才算完成了。而在野路子的流程圖中，是沒有辦法表達這個并行彙合處理的。
通常并行和彙合成對出現，此時并行執行兩組活動，但必須兩組活動都完成才能進入下一環節。而上圖也就是一個完整的流程圖了。
流程圖表示方法總結如下：
流程圖的繪制方法看完了之後，我們再來看文章最前面的流程圖的問題是什麼？
上面的流程圖是說産品經理的工作包括需求收集，需求讨論和需求評審等工作，并為此畫了流程圖進行闡述。思考一下，這個流程圖的問題是什麼？
我們按照流程圖的概念來看，流程圖要求每個框起來的都是一個活動，活動的典型即存在“主 謂 賓”。
在這裡面“有效需求、已有功能和需求池”都不是一個活動，這裡都是在說需求的不同類型和功能概念。真正體現活動的是産品經理進行“收集需求，讨論需求和需求評審”。
而這裡大家會說，我要體現“有效需求和需求池”等概念該怎麼做？
那麼可以這樣描述：我們可以将需求劃分為新需求 老需求，其中新需求産品經理需要過濾成有效需求和無效需求。而進入需求評審環節的是新需求的有效需求和老需求并放入需求池中，在這個環節我們決定本期開發的需求是那些。
上面這種描述，如果你理解了UML的面向對象的思考方法，就知道這是另一種形式的描述。另外其實知識是相通的，如果按照金字塔原理進行思考，也能得出上面的描述内容。
通過這個案例，我們發現将需求處理的方案和需求評審流程的描述混在一起，會讓受衆群體迷惑，而如果分開描述則會清晰很多。
這是一個買家下單和付款的流程。這裡仍然按照“主謂賓”來拆分，我們發現待付款不是一個活動，而是一個狀态。而橫線上的“買家下單”才是個活動（即用戶點擊下單）。
因此這個仍然不是流程圖，在UML裡更适合用狀态圖來表達。如果此時按照狀态圖的角度來看，這裡也是有問題的，我們以後會有專題來講狀态圖。
這個流程圖大家看是從用戶下單到供應商供貨的流程，我們假設這個就是京東或天貓的訂單流程。在這裡“生成送貨單，以及用戶選擇支付方式，收款”等環節流程表述錯誤，大家想想問題是什麼？
此時我們回憶一下我們在購物APP上如何下單的？這個流程是：
1）用戶從購物車點擊“去結算”，就會打開“提交訂單頁面”。
2）在“提交訂單頁面”允許用戶選擇網上支付還是貨到付款，以及編輯送貨地址，此時點擊“提交訂單”按鈕。
3）則系統生成訂單，并展示給用戶“支付頁面”。
4）在“支付頁面” 允許用戶可以選擇某銀行卡或支付寶後，再點擊“銀行卡支付”按鈕。
5）此時系統展示“輸入網銀（或支付寶）密碼”的頁面。
6）在“輸入密碼頁面” 用戶“輸入賬戶密碼”後就完成了訂單支付。
回憶完整個流程後，我們會發現如下問題：
問題一：“用戶選擇支付方式，之後收款，中間可以取消訂單”這個概括就不正确。
實際上是“在提交訂單頁面，用戶先點擊提交訂單；之後彈出輸入密碼頁面，用戶輸入密碼完成支付”。此時在點擊提交訂單後不輸入支付密碼時，用戶可以到個人訂單列表裡面選擇“取消訂單”。因此概括起來是：用戶提交訂單，之後用戶支付訂單，在提交訂單後可以取消訂單。
問題二：生成送貨單和其他活動不是并列關系。
系統的實際工作過程是“用戶點擊提交訂單”後，系統就會生成訂單，不生成訂單就沒有支付頁面。這個生成的訂單也可以在個人中心的訂單列表裡看到，針對待付款的訂單用戶可以進行支付或取消訂單。所以生成送貨單和選擇支付方式是不是同時進行的關系。
通過這個案例其實發現流程訓練首先需要仔細思考每個環節。其次這個涉及到對流程對每一步如何進行抽象的問題，如何畫出人人都喜歡都明白的流程圖的問題。這也是第二篇要重點講的地方。
通過本篇文章，大家了解了标準的流程圖的畫法。
這裡首先需要理解活動，判斷、并行、并行彙合和合并等基本概念。其次通過三個例子，說明如何正确表達流程圖，而不要學了假的流程圖。
我們發現流程圖是一種邏輯表達方式，還有很多其他的方式需要進一步解鎖，會在後續文章中講解。
說說你曾經踩過的坑？是否有點啟發和改變？
作者：擎蒼（引爆産品思維），産品狗一枚，10年産品和運營經驗，曾負責上市公司的互聯網團隊組建和運營，曾在多個垂直領域頭部公司做産品狗。
本文由 @引爆産品思維 原創發布于人人都是産品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
