起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識任務和業務流程圖分清用好，三步教會你繪制大廠流程圖(第三篇)
業務流程圖、功能流程圖、任務流程圖……我們經常聽到這些名詞伴隨著定義/概念出場，然而，這些概念真的是正確并且準確的嗎？
繼上兩篇，講述了流程圖的規范，以及講述了如何畫出不被研發怒懟，能讓運營看懂的流程圖后，我們繼續來明確幾個網上的概念。
前面兩篇文章請移步查看：《制作規范不錯的路程圖》、《制作人人喜歡的流程圖》。
本文明確的是以下問題，也是經常容易被理解錯的概念。
- 業務流程圖只是一個說法而不是一種畫法；
- 任務和業務流程圖多此一舉的概念；
- 功能流程圖不要用不要提。
下面我們一步一步說明。
一、業務流程圖只是一個說法而不是一種畫法
先看下面兩張圖，在一些表述中，分別被描述成是業務流程圖和任務流程圖，而兩者的區別是：
1）業務流程圖就是帶泳道的流程圖，是表述業務流程的。
2）任務流程圖是無泳道的流程圖，是表述任務的。
而實際上這兩個表述都欠妥。
業務流程圖（泳道圖）
任務流程圖
業務流程圖的描述為什么欠妥？先看下面對業務流程圖的描述：
業務流程圖就是描述那些個體在什么條件下做了什么事情，他們之間有何關聯。
主要分兩個方面：
1）涉及到哪些主體（角色）？
2）每個主體（角色）都有哪些工作？
而這里如果理解成“帶泳道的就是業務流程圖”，那么請看下面的兩張圖，描述的內容是相同的，但無論加不加泳道，是不是都在表述業務呢？
不帶泳道的描述業務
帶泳道描述業務
因此業務流程圖只是一個說法，而不是一個具體的畫法，可以加泳道或不加泳道。
二、任務和業務流程圖多此一舉的概念
另一方面，”業務流程圖和任務流程圖”概念則不建議提，實際上是多此一舉的概念，僅僅是個修飾詞而已。看下面的表述：
任務流程圖就是在你的產品操作上，用戶通過什么樣的操作來完成它的目標，比如你去銀行ATM機器上取錢，你是如何一步步操作把錢取出來的。
其實就是用戶操作的過程，而如果概括為任務則成了“你的任務是去取錢或去注冊”，這個就不準確了；而如果對于快遞員如果說“你的任務是送快遞”，則表述正確。實際上：
1. 對用戶就是具體操作，顯然用“用戶操作流程”來解釋就可以，比如：用戶取錢流程圖，用戶登錄流程圖，用戶下單流程圖等。
2. 對快遞人員而言則是一個任務， 比如：快遞員送快遞任務流程圖。
因此建議工作中不要提任務流程圖概念。對用戶而言這不是一個任務，對快遞人員而言是一個任務。直接說你要干什么就可以。參考下面兩個說法那個適合？
- 說法一：老板和各位研發，我們過一下我畫的用戶登錄任務流程圖和快遞送貨任務流程圖。
- 說法二：老板和各位研發，我們來過一下用戶登錄的流程和快遞員送貨的流程圖。
顯然第二種說法更為直接有效。
再舉個列子，看下面的流程圖，這個到底算是業務流程圖，還是任務流程圖呢？
實際上你發現，用“系統流程圖”表述更準確。因此你會發現把流程圖歸類為任務流程圖和業務流程圖，其實沒有必要。就是流程圖，只不過有不同的修飾詞。
因此可以在日常工作中，可以表述成：操作流程圖（表達用戶的注冊的操作），業務流程圖（表達公司內部處理訂單的流程），系統流程圖（如上圖，表達系統內部的邏輯處理），任務流程圖（表達快遞員送快遞所要完成的任務）等等各種說法。
至于用那個修飾詞或想自己造一個修飾詞，您隨意寫吧。實際上以上流程圖，都沒有畫法的區別，都是一樣的，為什么要分出不同的概念呢？
三、功能流程圖不要用不要提
下面的表達稱其為功能流程圖：
而實際上：
1. 要么表達操作流程，用流程圖。
2. 要么表達每個頁面有什么主要功能，用頁面流程圖。
3. 要么表達功能之間的關系，用UML的用例圖。
就這個案例看，就是要表達每個頁面的主要功能。用頁面流程圖畫3個簡化的原型頁面即可，又清晰又簡單。不要用流程圖表達功能，這不是流程圖的目標。流程圖是表達一系列的動作，而不是表達一系列的功能。
四、總結和后記
業務流程圖，任務流程圖和功能流程圖是很多人聽到的概念。
而實際上在經典的UML中就沒有這些概念。沒有這些概念是正確的，因為這種歸類不嚴謹，也沒有什么用。本人也試圖去找到底是誰提出的這個概念，但是沒有找到。如果有人知道源頭和解釋，歡迎指正。
相關閱讀
作者：擎蒼，資深產品經理，資深老師，公眾號：圖解產品設計
本文由 @擎蒼 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
跪求作者寫一篇關于頁面流程圖的文章！?。?/p>
第一版沒有了，如書能再版應可加入
閱讀了作者的三篇文章，收益頗多，看到上文有闡述頁面流程圖，能否出一篇講述頁面流程圖的呢？讓廣大童鞋學習下~
那個不算重點的，頁面流程圖現在沒有標準畫法，不過畫起來很容易，并且也可以用流程圖中的符號。做起來就是：把頁面畫的簡單點，然后再用線串起多個頁面，連的線仍然可以用流程圖的圖標（常見的是菱形判斷，條件判斷）。更為重要的是單一頁面的交互備注，這應是重點。
閱讀之前先收藏點贊
簡歷
.
.
功能流程圖的源頭，是在一篇全網超高閱讀量的文章中看到的。對方詳細解釋了任務，業務和功能等流程圖。按照其定義是各不相同。而實際上我們實戰中從來沒見過。之后我再分析，其實更適合用頁面流程圖表達。而按照奧姆剃須刀原理，也不應增加這些不必要概念，很多余。
直播例子，自身邏輯清晰直接寫邏輯也可，也可畫流程圖。可以理解直接寫邏輯相當于編程語言寫if等的漢化版。具體選哪個，在于那個研發更容易理解。
功能流程圖的源頭，是在一篇全網超高閱讀量的文章中看到的。對方詳細解釋了任務，業務和功能等流程圖。按照其定義是各不相同。而實際上我們實戰中從來沒見過。之后我再分析，其實更適合用頁面流程圖表達。而按照奧姆剃須刀原理，也不應增加這些不必要概念，很多余。
直播例子，自身邏輯清晰直接寫邏輯也可，也可畫流程圖?？梢岳斫庵苯訉戇壿嬒喈斢诰幊陶Z言寫if等的漢化版。具體選哪個，在于那個研發更容易理解。
那篇文章我也看過，說實話，確實沒有什么實戰意義，而且給自己增加了很多不必要的概念。我覺得流程圖就應該是作者提出的這樣，不用刻意分業務、任務或功能，只要能讓相關人看懂就好。
我的個人拙見，交流交流。因為功能流程圖這個說法還是很普遍在用，它就是**功能流程圖，比如注冊功能流程圖、訂單功能流程圖等等，也會省略功能二字。但是這些都是一款產品的功能，它不是任務也不是業務，為了統稱它們所以管叫功能流程圖吧。
像這些流程圖存在也是很有意義，它就是針對一個功能來詳細告知開發它的邏輯。類似注冊登錄這種普遍人都已經接觸的功能當然不用細化，而一個全新的功能點就需要細化邏輯。比如：做一個直播功能，它需要很多判斷邏輯。進入直播間前可能需要判斷直播是否開播，直播是否會員制，是否擁有試看5分鐘功能等，因為涉及到判斷先后，不同的處理方式會有不同的結果。當然這個可以用原型去描述，但是相比之下流程圖是否更加清晰呢？
這是我個人的拙見，希望拋磚引玉，有大牛前來指點一下。
功能流程圖應該表現的是功能之間的操作流程關系；上邊提到的注冊功能流程圖，是要表達用戶使用注冊功能時這一單一功能的實現過程，該叫做用戶注冊邏輯圖，功能邏輯圖的叫法來表達功能的內部實現更好些
流程圖就是流程圖，邏輯圖和流程圖不是同一個東西哇。百度一下概念都不一樣。
登錄的流程圖，是要表達各種異常處理，比如未注冊怎么辦，連續密碼輸錯怎么辦等。這些都是在說，用戶和系統之間的交互，即用戶做什么系統反饋什么等，稱其為頁面交互流程圖，簡稱交互流程圖，似是更貼切的描述。而交互流程圖就是對應上一篇的人機交互模式，也有更為明確的繪制特點和原則。
有幾張圖片看不了。
圖掛了，重新編輯一下？
感謝大神精彩分享，收獲頗豐，第三篇前兩張圖看不到呢
正常流程都會思考，但異常情況的處理則是考驗產品邏輯的關鍵，期待你出個異常處理的文章
已經在4-5月即將出版的新書（暫定名）中寫了，可以關注公眾號號，獲得書的節選。
書名是什么~要好好拜讀下
思維挺拔高的，不同階段理解不盡相同，但不管如何，流程圖是產品思維剖析的利器
期待您的下一份作品
邏輯清晰強大，不愧是產品大佬~
三篇文章都看了，非常感謝您的分享。
謝謝了，要多多運用才好
三篇文章都看了，感謝作者您的分享！
您的三篇文章都看了，謝謝您
??
您的三篇文章都看了，謝謝您
謝謝閱讀，不過更高的獲得要練
樓主會說說頁面流程圖和UML用例圖嗎？ ??
短期難，其實除了流程圖，下一步最需要掌握的思考利器是狀態圖，有這個才能做好后臺的審核等邏輯，不至于丟三落四。
而下一步會有新的方向，簡歷面試或者解決方案的思考。
狀態圖也是很期待了