編輯導(dǎo)語(yǔ)：流程圖有沒(méi)有限定的標(biāo)準(zhǔn)？正確規(guī)則的流程圖有什么規(guī)范？本文將從三個(gè)方面來(lái)作出解答：流程圖的意義、流程圖如何繪制、常見(jiàn)的流程圖問(wèn)題。學(xué)會(huì)并掌握這三個(gè)要點(diǎn)，定會(huì)助你提升流程圖繪制能力，在日后的工作中更快成長(zhǎng)。

作為一個(gè)產(chǎn)品經(jīng)理，畫(huà)流程圖是必備的技能。如制定訂單處理的流程，制定商品審核的流程，制定用戶(hù)開(kāi)銀行賬戶(hù)的流程等。

也有非常多的文章在介紹如何畫(huà)流程圖。我們發(fā)現(xiàn)有各種畫(huà)法，也有各種概念。這里產(chǎn)生一個(gè)問(wèn)題：到底什么樣的流程圖是正確的？有沒(méi)有標(biāo)準(zhǔn)？

無(wú)標(biāo)準(zhǔn)野路子的流程圖必然會(huì)產(chǎn)生歧義，必然是思路混亂的。比如以下兩個(gè)流程圖就都是有問(wèn)題的，并導(dǎo)致表達(dá)混亂。

有問(wèn)題的流程圖

有問(wèn)題的流程圖

其實(shí)流程圖是有標(biāo)準(zhǔn)的，這就是UML（統(tǒng)一建模語(yǔ)言）制定的標(biāo)準(zhǔn)，被其稱(chēng)為活動(dòng)圖。并且這個(gè)標(biāo)準(zhǔn)被微軟和IBM等大廠采用。我們通過(guò)本文就能夠知道，上面兩個(gè)流程圖的問(wèn)題了。

既然了解到很多流程圖是有問(wèn)題的，所以要畫(huà)好也不是那么容易。所以我也會(huì)分三篇文章來(lái)介紹UML的流程圖怎么畫(huà)，分別是：

1. 如何制作正確規(guī)則的流程圖？
2. 如何制作人人喜歡的流程圖？
3. 流程圖的概念解析

其中第一篇會(huì)讓大家理解流程圖的正確姿勢(shì)和語(yǔ)言。第二篇會(huì)手把手教讓大家繪制粗細(xì)得當(dāng)，人人喜歡的流程圖。第三篇是概念解釋?zhuān)瞥龢I(yè)務(wù)流程圖，任務(wù)流程圖和功能流程圖的誤區(qū)。

要先學(xué)流程圖的規(guī)則是什么，這就好比下象棋。我們首先要理解下棋的規(guī)則是什么，然后再學(xué)習(xí)如何去贏得比賽的策略。如果反過(guò)來(lái)，這就好比知道怎么下棋，卻不了解基本規(guī)則一樣。規(guī)則枯燥但還是要先來(lái)學(xué)習(xí)的。

本篇文章包括：流程圖的意義、流程圖如何繪制、常見(jiàn)的流程圖問(wèn)題。

一、流程圖的意義

對(duì)于產(chǎn)品經(jīng)理要重視流程圖的繪制，這背后是邏輯清晰的表達(dá)和思考。

首先，很多產(chǎn)品經(jīng)理往往一上手做交互頁(yè)面原型。但這樣往往因?yàn)榱鞒滔氩磺宄?，?dǎo)致原型圖需要重畫(huà)。所以要先畫(huà)流程圖，再畫(huà)原型圖。

其次，研發(fā)經(jīng)常批評(píng)產(chǎn)品經(jīng)理沒(méi)有邏輯。而畫(huà)流程圖就是建立你的邏輯的一種方法，也最終用在面試表達(dá)，產(chǎn)品評(píng)審發(fā)言中，下面我們就看看如何畫(huà)。

二、流程圖如何畫(huà)？

流程圖是為了完成某一任務(wù)而描述的相關(guān)活動(dòng)的執(zhí)行順序。UML稱(chēng)流程圖為活動(dòng)圖，為了便于討論，后面還稱(chēng)其為流程圖。

下面我們以訂單為例子，帶領(lǐng)大家一步一步畫(huà)出流程圖。整個(gè)流程涉及到從用戶(hù)下單到收貨的流程。下面就是這個(gè)訂單流程：

其邏輯是用戶(hù)下單后，物流人員就需要送貨到家，用戶(hù)收貨后，在點(diǎn)擊確認(rèn)收貨，即完成整個(gè)訂單。這里就涉及到以下概念：

1. 活動(dòng)的概念

這里物流人員送貨到家和用戶(hù)確認(rèn)收貨，都體現(xiàn)了一個(gè)人做了什么事情，都會(huì)涵蓋“主語(yǔ)+謂語(yǔ)+賓語(yǔ)”?！坝脩?hù)”是主語(yǔ)，“點(diǎn)擊”是謂語(yǔ)，“確認(rèn)收貨”是賓語(yǔ)。

而人做了什么事情，就體現(xiàn)了一個(gè)“動(dòng)作或操作”，而UML則稱(chēng)其為活動(dòng)。其實(shí)和動(dòng)作或操作是近似的意思，但活動(dòng)的概括更為廣泛。

活動(dòng)的標(biāo)準(zhǔn)畫(huà)法是帶圓角的矩形框，里面寫(xiě)具體的活動(dòng)，活動(dòng)內(nèi)容寫(xiě)成“主語(yǔ)+謂語(yǔ)+賓語(yǔ)”，賓語(yǔ)或主語(yǔ)根據(jù)說(shuō)話習(xí)慣可以考慮省略。

活動(dòng)之間用帶箭頭的線連接在一起，稱(chēng)其為“轉(zhuǎn)移”。表示做完了一個(gè)活動(dòng)就可以轉(zhuǎn)移到下一個(gè)活動(dòng)，比如物流人員送貨到家后，用戶(hù)才會(huì)確認(rèn)訂單完成，否則就無(wú)法進(jìn)入下一個(gè)活動(dòng)。

2. 起點(diǎn)和終點(diǎn)概念

一個(gè)流程圖有一個(gè)“起點(diǎn)”，作用是表明一個(gè)流程從這里開(kāi)始。起點(diǎn)畫(huà)是個(gè)實(shí)心小圓。

一個(gè)流程圖也有“終點(diǎn)”，作用是表明上一步的“活動(dòng)”就是整個(gè)流程的結(jié)束。對(duì)于上面的訂單流程而言結(jié)束的活動(dòng)就是“用戶(hù)確認(rèn)收貨”。這個(gè)活動(dòng)完成后，整個(gè)流程就算完成了。終點(diǎn)畫(huà)法則是一個(gè)實(shí)心圓加一個(gè)空心圓。

注意：起點(diǎn)必須有，而終點(diǎn)可以省略不畫(huà)或有多個(gè)。終點(diǎn)畫(huà)上的好處是可讓別人知道你考慮了終點(diǎn)因素。但有的流程涉及到的終點(diǎn)過(guò)多，并且結(jié)束顯而易見(jiàn)，畫(huà)上就顯得累贅。

3. 判斷和并行概念

現(xiàn)在我們已經(jīng)能夠畫(huà)出了流程圖。但我們發(fā)現(xiàn)這個(gè)流程會(huì)有很多細(xì)節(jié)需要補(bǔ)充，這就是我們接下來(lái)要介紹的判斷和并行概念。我們以問(wèn)題為出發(fā)點(diǎn)，看如何完善流程圖。

“網(wǎng)上支付或貨到付款”有不同的處理則怎么表達(dá)？——用判斷標(biāo)志來(lái)解決。

此時(shí)物流人員就需要對(duì)訂單進(jìn)行判斷，如果是網(wǎng)上支付（送貨前支付）則直接給貨物到用戶(hù)，否則必須先讓用戶(hù)支付現(xiàn)金或先刷POS機(jī)后，再給貨物，此時(shí)流程圖如下：

這個(gè)判斷點(diǎn)就用菱形符號(hào)來(lái)表示，此時(shí)是一個(gè)進(jìn)入多個(gè)出，并且在出的線條上用方括號(hào)表明判斷條件。這里的：

條件一是“如果用戶(hù)是網(wǎng)上支付”（簡(jiǎn)稱(chēng)：網(wǎng)上支付），則相應(yīng)的動(dòng)作是“物流給貨物到用戶(hù)”；

條件二是“如果用戶(hù)是貨到付現(xiàn)金”（簡(jiǎn)稱(chēng)：現(xiàn)金支付），則相應(yīng)的動(dòng)作是“物流收取現(xiàn)金”。

條件三是“如果用戶(hù)選擇POS支付”，則“物流用POS機(jī)收錢(qián)”。

注意：和其他流程圖的菱形符號(hào)中間寫(xiě)字不同，這里不允許在菱形符號(hào)中間寫(xiě)任何字，但表達(dá)的意思是一樣的。菱形位置里面其實(shí)是可以寫(xiě)“物流確認(rèn)支付情況”，寫(xiě)文字易于理解但是略顯累贅。

再如電商中如果用戶(hù)支付完畢，有的時(shí)候會(huì)反悔并告知商家。對(duì)于商家也會(huì)存在兩種選擇，“同意則取消訂單”或“拒絕則堅(jiān)持發(fā)貨”。這兩種表達(dá)方式都可以達(dá)到同樣的效果，只是方法不同。

了解了和傳統(tǒng)流程圖的不同表示方法后，對(duì)于UML體系，除了上面介紹的用帶菱形的表示方法外，另外一個(gè)方式是不加入菱形判斷圖標(biāo)，如下圖所示：

這兩種表達(dá)方法都是可以的，但需要注意要在轉(zhuǎn)移線上寫(xiě)出判斷條件。對(duì)于本案例加入判斷的菱形圖標(biāo)會(huì)更加清晰，此時(shí)明確物流人員在這里要進(jìn)行一個(gè)判斷。

如果用戶(hù)還要同時(shí)開(kāi)發(fā)票則怎么表達(dá)？——用并行標(biāo)志來(lái)解決。

現(xiàn)在很多的送貨是貨物和發(fā)票放在了一起一并寄送過(guò)去，或者支持電子發(fā)票的方式。但是還有一些企業(yè)開(kāi)紙質(zhì)發(fā)票，并且貨物和開(kāi)發(fā)票地并不一致。這個(gè)時(shí)候就需要貨物和發(fā)票分別寄送到用戶(hù)手里。

此時(shí)意味著兩撥物流人員一個(gè)在送貨和一個(gè)在寄送發(fā)票。這里就是一個(gè)并行處理，表達(dá)方式如圖所示：

畫(huà)法是畫(huà)一個(gè)粗橫線，再加上一個(gè)進(jìn)入和多個(gè)出的轉(zhuǎn)移線條。對(duì)于本例子，出的兩個(gè)分支流程是配送貨物和發(fā)票寄送，此時(shí)同步處理但并不在意誰(shuí)先做誰(shuí)后做。

4. 匯合和合并概念

網(wǎng)上支付和現(xiàn)金支付任意一個(gè)完成就算完成如何表達(dá)？——用合并來(lái)解決。

此時(shí)只要是網(wǎng)上支付或現(xiàn)金支付任意一個(gè)方式就算完成了支付。即條條大路通羅馬，我們只要一個(gè)路徑能到達(dá)，就可以進(jìn)行下一步了，此時(shí)有兩種表達(dá)方法：

一種方法直接通過(guò)三條轉(zhuǎn)移線連接到下面的活動(dòng)即可，這個(gè)也是我們?cè)谇懊婵吹降?。第二種方法是畫(huà)一個(gè)菱形并且多進(jìn)一出。注意這個(gè)菱形符號(hào)在這里不是表示要判斷，只是借用了菱形符號(hào)而已，因此也不必在線條旁邊加入判斷條件。

實(shí)際上第二種畫(huà)法是UML的標(biāo)準(zhǔn)畫(huà)法。但畢竟看流程圖的人有的不是編程人員，畫(huà)上會(huì)讓人誤解，為了便于溝通可以選擇第一種畫(huà)法。但是在看到網(wǎng)上的流程圖加入合并的菱形標(biāo)志的時(shí)候，要意識(shí)到這里不是進(jìn)行判斷，而是在做合并。

這里另一個(gè)例子就是用戶(hù)可點(diǎn)擊確認(rèn)收貨，而系統(tǒng)也可以自動(dòng)確認(rèn)收貨，也是那個(gè)先確認(rèn)收貨都算收貨，訂單即最后完成。

發(fā)票和商品用戶(hù)都收到才算完成如何表達(dá)？——用匯合來(lái)解決。

前面我們講了貨物和發(fā)票是分別寄出的，對(duì)于用戶(hù)必須是發(fā)票和貨物同時(shí)收到了才會(huì)點(diǎn)擊“確認(rèn)收貨”，兩者缺一不可。具體表示見(jiàn)下圖：

達(dá)方式是一個(gè)粗橫線，再加上多個(gè)進(jìn)入和一個(gè)出。進(jìn)入的分支是送貨物和送發(fā)票，此時(shí)同步處理但并不在意誰(shuí)先做誰(shuí)后做，但匯合的時(shí)候必須要都完成才可進(jìn)入到下一步。

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

通常并行和匯合成對(duì)出現(xiàn)，此時(shí)并行執(zhí)行兩組活動(dòng)，但必須兩組活動(dòng)都完成才能進(jìn)入下一環(huán)節(jié)。而上圖也就是一個(gè)完整的流程圖了。

5. 流程圖的總結(jié)

流程圖表示方法總結(jié)如下：

三、通過(guò)問(wèn)題學(xué)概念

流程圖的繪制方法看完了之后，我們?cè)賮?lái)看文章最前面的流程圖的問(wèn)題是什么？

案例一：流程圖中不應(yīng)有非活動(dòng)的內(nèi)容

上面的流程圖是說(shuō)產(chǎn)品經(jīng)理的工作包括需求收集，需求討論和需求評(píng)審等工作，并為此畫(huà)了流程圖進(jìn)行闡述。思考一下，這個(gè)流程圖的問(wèn)題是什么？

我們按照流程圖的概念來(lái)看，流程圖要求每個(gè)框起來(lái)的都是一個(gè)活動(dòng)，活動(dòng)的典型即存在“主+謂+賓”。

在這里面“有效需求、已有功能和需求池”都不是一個(gè)活動(dòng)，這里都是在說(shuō)需求的不同類(lèi)型和功能概念。真正體現(xiàn)活動(dòng)的是產(chǎn)品經(jīng)理進(jìn)行“收集需求，討論需求和需求評(píng)審”。

而這里大家會(huì)說(shuō)，我要體現(xiàn)“有效需求和需求池”等概念該怎么做？

那么可以這樣描述：我們可以將需求劃分為新需求+老需求，其中新需求產(chǎn)品經(jīng)理需要過(guò)濾成有效需求和無(wú)效需求。而進(jìn)入需求評(píng)審環(huán)節(jié)的是新需求的有效需求和老需求并放入需求池中，在這個(gè)環(huán)節(jié)我們決定本期開(kāi)發(fā)的需求是那些。

上面這種描述，如果你理解了UML的面向?qū)ο蟮乃伎挤椒?，就知道這是另一種形式的描述。另外其實(shí)知識(shí)是相通的，如果按照金字塔原理進(jìn)行思考，也能得出上面的描述內(nèi)容。

通過(guò)這個(gè)案例，我們發(fā)現(xiàn)將需求處理的方案和需求評(píng)審流程的描述混在一起，會(huì)讓受眾群體迷惑，而如果分開(kāi)描述則會(huì)清晰很多。

案例二：流程圖不同于狀態(tài)圖

這是一個(gè)買(mǎi)家下單和付款的流程。這里仍然按照“主謂賓”來(lái)拆分，我們發(fā)現(xiàn)待付款不是一個(gè)活動(dòng)，而是一個(gè)狀態(tài)。而橫線上的“買(mǎi)家下單”才是個(gè)活動(dòng)（即用戶(hù)點(diǎn)擊下單）。

因此這個(gè)仍然不是流程圖，在UML里更適合用狀態(tài)圖來(lái)表達(dá)。如果此時(shí)按照狀態(tài)圖的角度來(lái)看，這里也是有問(wèn)題的，我們以后會(huì)有專(zhuān)題來(lái)講狀態(tài)圖。

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

這個(gè)流程圖大家看是從用戶(hù)下單到供應(yīng)商供貨的流程，我們假設(shè)這個(gè)就是京東或天貓的訂單流程。在這里“生成送貨單，以及用戶(hù)選擇支付方式，收款”等環(huán)節(jié)流程表述錯(cuò)誤，大家想想問(wèn)題是什么？

此時(shí)我們回憶一下我們?cè)谫?gòu)物APP上如何下單的？這個(gè)流程是：

1. 用戶(hù)從購(gòu)物車(chē)點(diǎn)擊“去結(jié)算”，就會(huì)打開(kāi)“提交訂單頁(yè)面”。
2. 在“提交訂單頁(yè)面”允許用戶(hù)選擇網(wǎng)上支付還是貨到付款，以及編輯送貨地址，此時(shí)點(diǎn)擊“提交訂單”按鈕。
3. 則系統(tǒng)生成訂單，并展示給用戶(hù)“支付頁(yè)面”。
4. 在“支付頁(yè)面” 允許用戶(hù)可以選擇某銀行卡或支付寶后，再點(diǎn)擊“銀行卡支付”按鈕。
5. 此時(shí)系統(tǒng)展示“輸入網(wǎng)銀（或支付寶）密碼”的頁(yè)面。
6. 在“輸入密碼頁(yè)面” 用戶(hù)“輸入賬戶(hù)密碼”后就完成了訂單支付。

回憶完整個(gè)流程后，我們會(huì)發(fā)現(xiàn)如下問(wèn)題：

問(wèn)題一：“用戶(hù)選擇支付方式，之后收款，中間可以取消訂單”這個(gè)概括就不正確。

實(shí)際上是“在提交訂單頁(yè)面，用戶(hù)先點(diǎn)擊提交訂單；之后彈出輸入密碼頁(yè)面，用戶(hù)輸入密碼完成支付”。此時(shí)在點(diǎn)擊提交訂單后不輸入支付密碼時(shí)，用戶(hù)可以到個(gè)人訂單列表里面選擇“取消訂單”。因此概括起來(lái)是：用戶(hù)提交訂單，之后用戶(hù)支付訂單，在提交訂單后可以取消訂單。

問(wèn)題二：生成送貨單和其他活動(dòng)不是并列關(guān)系。

系統(tǒng)的實(shí)際工作過(guò)程是“用戶(hù)點(diǎn)擊提交訂單”后，系統(tǒng)就會(huì)生成訂單，不生成訂單就沒(méi)有支付頁(yè)面。這個(gè)生成的訂單也可以在個(gè)人中心的訂單列表里看到，針對(duì)待付款的訂單用戶(hù)可以進(jìn)行支付或取消訂單。所以生成送貨單和選擇支付方式是不是同時(shí)進(jìn)行的關(guān)系。

通過(guò)這個(gè)案例其實(shí)發(fā)現(xiàn)流程訓(xùn)練首先需要仔細(xì)思考每個(gè)環(huán)節(jié)。其次這個(gè)涉及到對(duì)流程對(duì)每一步如何進(jìn)行抽象的問(wèn)題，如何畫(huà)出人人都喜歡都明白的流程圖的問(wèn)題。這也是第二篇要重點(diǎn)講的地方。

四、總結(jié)

通過(guò)本篇文章，大家了解了標(biāo)準(zhǔn)的流程圖的畫(huà)法。

這里首先需要理解活動(dòng)，判斷、并行、并行匯合和合并等基本概念。其次通過(guò)三個(gè)例子，說(shuō)明如何正確表達(dá)流程圖，而不要學(xué)了假的流程圖。

我們發(fā)現(xiàn)流程圖是一種邏輯表達(dá)方式，還有很多其他的方式需要進(jìn)一步解鎖，會(huì)在后續(xù)文章中講解。

這個(gè)文章還是有點(diǎn)小問(wèn)題，不知道你能否發(fā)現(xiàn)，發(fā)現(xiàn)了可以留言。

作者：擎蒼，《“圖解”產(chǎn)品：產(chǎn)品經(jīng)理業(yè)務(wù)設(shè)計(jì)與UML建?！纷髡?，公眾號(hào)：圖解產(chǎn)品設(shè)計(jì)

本文由 @擎蒼 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議