全面解讀流程圖｜附共享單車摩拜ofo案例分析

梗概

對於任何產品設計來講，構建流程都是一個繞不開的環節。其奠基了後續的產品框架，是用戶體驗的基石。本文將從定義和分類出發，結合實際案例，深刻淺出地闡述流程圖的做用以及畫法。

定義

流程——顧名思義：水流的路程；事物進行中的次序或順序的佈置和安排。流程是天然而然就存在的，它能夠不規範，能夠不固定，能夠充滿問題。

由兩個及以上的步驟，完成一個完整的行爲的過程，可稱之爲流程；注意是兩個及以上的步驟。

流程圖的核心就在於如何排布事物進行的次序，不一樣的順序可能形成大相徑庭的結果。

目的

產品經理畫流程圖的目的不外乎幾點：

流程圖爲產品設計基石，能夠保證產品的使用邏輯合理順暢

傳達需求，用流程圖來更好地表達產品邏輯

查漏補缺，檢驗是否有遺漏的分支流程

分類

流程圖以描述對象分類，包括：業務流程圖、頁面流程圖、功能流程圖、數據流程圖等。

業務流程圖（Transaction Flow Diagram, TFD）

先以宋丹丹小品中的一個腦筋急轉彎爲例：把大象裝冰箱，總共分幾步？

三步：

第一步，把冰箱門打開；

第二步，把大象裝進去；

第三步，把冰箱門關上。

這看似是一個笑話，但其實蘊含着很強的邏輯思惟。首先這裏忽略了不少現實中的限制條件。好比，以大多數冰箱的容積都不可能將大象塞進去；好比是否能把大象切成塊放進去？若是把大象塞進去，它會不會又跑出來？但拋開這些限制條件，那把大象塞冰箱的極簡流程就是三步。打開冰箱門，把大象裝進去，最後把門關上。

咱們作業務流程圖，其實不少時候都須要具備把「大象塞進冰箱」的思惟方式，拋開不少現有的認知侷限，將具象的行爲一個個抽象出來。

結合上面的例子，再來細細品味「業務流程圖」的定義：

抽象地描述事物進行的次序和順序，不涉及具體操做與執行細節。在互聯網軟件行業一般指脫離產品設計的用戶行爲流程。業務流程圖是一種系統分析人員都懂的共同語言, 用來描述系統組織結構、業務流程。

無論是否理解上述定義，下面帶着抽象思惟去思考購物行爲的業務流程圖應該是什麼樣的？

以上的三步組成了一個最簡的一個流程，其徹底涵蓋了任何購物行爲的核心。不管是網購仍是在實體超市，都是以這三個行爲爲主體，而後進行擴展的。相對於你們平時看到的複雜的網購流程圖，以上的三步流程簡直簡單的使人髮指，而這偏偏是印證了大道至簡的原理。我始終堅信不管再複雜的事情都能簡化爲極其簡單的事情，若是你沒法將其簡化，說明只是你沒有理解其核心。

依據上面的最小流程單元，咱們下面嘗試能不能將其擴展，嘗試套用在更細節的流程圖上面。

頁面流程圖（Page Flow Diagram）

定義：指電子產品具體所呈現的頁面跳轉流程圖。其承載了業務流程圖所包含的業務流轉信息。

下圖以淘寶爲例，展現出了網購的頁面流程。

由上圖紅框中的三個節點咱們能夠看出，頁面流程圖依然是包含在業務流程圖的。這偏偏符合定義中的要求，同時也印證了頁面流程圖的正確性。相較於一開始的極簡流程圖，如今的流程圖已經漸漸變得複雜了一些。咱們將抽象的業務，映射在了具象的頁面上，用軟件的頁面承載起了業務需求。而以上就是由業務流程圖到頁面流程圖的轉化過程。

功能流程圖（Function Flow Diagram）

定義：指單頁面內或多頁面之間的功能操做流程，其包含在頁面流程中。

任何功能都是被包含在頁面內的，但一個頁面內每每不止一個功能，因此單單頁面流程圖可能沒法完整表達全部流程，而這時就須要用功能流程圖來更加具體表達每一個頁面內所包含的功能。

由上圖紅框中的四個節點咱們能夠看出，功能流程圖一樣也是由頁面流程圖拓展而來的。功能流程圖是在頁面流程圖的基礎上繼續深化，變得更加複雜。同時也漸漸變得像你們平常看到的流程圖同樣。

產品/運營/測試/程序員必備乾貨【資源下載】

www.jianshu.com/p/875b98aba…

數據流程圖（Data Flow Diagram）

定義：特指軟件產品中，描述數據在不一樣節點被處理的過程所畫的圖表。主要表達計算機程序對於業務的實現原理。用戶在功能流程圖中的每個操做，對應都會反映在數據流程圖中。同時，數據流程圖也能夠叫程序流程圖（Program Flow Diagram）。

它是一種能全面地描述信息系統邏輯模型的主要工具。它能夠利用少數幾種符號綜合的反映出信息在系統中的流動、處理和存儲的狀況。數據流程圖具備抽象性和歸納性。

可能業務流程圖、頁面流程圖和功能流程圖你們都耳熟能詳，但數據流程圖恐怕瞭解的就比較少了。其實，每一個流程圖中都有一個核心伴隨着不一樣操做在整個系統中不斷流轉。好比業務流程圖大多以人爲核心，每一個節點都是在傳遞人的不一樣行爲。而頁面流程圖和功能流程圖也相似，都是以人的操做行爲爲核心，在不一樣頁面和功能間進行流轉。但數據流程圖不一樣，它是以數據爲核心，展現整個系統中，數據是如何被處理的。

其更偏技術思惟，更多的是展示後臺程序的實現原理。因此，經常是開發人員繪製此圖，而產品經理涉及較少。但隨着產品經理地不斷成長，向上提升到戰略層，而向下則會深刻到實現層。理解程序的開發原理和背後的數據流轉，無疑會讓產品經理對產品設計有更加深入的理解。

下面仍以購物流程爲主題來展現數據流程圖。

相較於以前的圖表，數據流程圖增長了新的維度——程序。客戶端在展示用戶操做行爲的同時，也表達了程序在用戶行爲背後的動做。而每每你們說一個產品複雜的時候，可能只注意到了它的前端交互複雜，而忽視了後端邏輯的複雜。對於一個優秀的產品經理來講，不止要關注前端的用戶體驗，更要能看清事物背後的邏輯。畢竟人人均可以對用戶體驗指手畫腳，而說到程序實現，那可就體現出產品經理的專業性來了。

小結

以上幾幅圖片分別展現了一個產品的業務流程、頁面流程、功能流程和數據流程。從中能夠發現，由業務到頁面，再到功能，再到數據處理，是順序拓展的。一個產品的頁面或功能，不是憑空出現的，而是依據業務層的各個節點和流程進行設計的。這就是爲何在作產品設計時必定要先理解業務的緣由。

在初步學習畫流程圖時，儘可能將業務、頁面、功能和數據區分清楚，而且逐層遞進，不要把多種類型的流程圖混雜一塊兒。這樣反而會將思想搞得混亂。

流程圖的顆粒度

所謂流程圖的顆粒度，其實就是指流程圖的細緻程度。

我在畫流程圖時也經常會猶豫糾結，這個功能點用不用描寫得更詳細？這條分支用不用標出來？這個和服務器的交互事件用不用在流程圖體現？等等這些問題，也都是產品經理在平常畫圖時會遇到的。

依然拿購物流程爲例，最簡的業務流程分爲三個步驟，那若是細化一些，是否能夠畫出不一樣的流程圖呢？

顯而易見，即使針對同一個流程，也能畫出不一樣的流程圖。如上圖，將挑選商品拆分爲三個步驟，將結帳拆分爲兩個步驟。但兩個流程圖依然表達的是一套流程。而這就是每一個人對於顆粒度的把握有所不一樣。有不少新人總想一步到位，一次畫出完美的流程圖。但這實際上是一種很是不可取的思惟。任何完善的流程圖，都須要通過由簡單到複雜的過程，而不是一蹴而就。

理論上來講，流程圖的細緻程度越高，產品設計就越準確順暢。但實際狀況中，過分的詳細反而是浪費時間。而對於度的把握能力，則須要經驗積累以及團隊磨合，這裏也是體現產品經理對顆粒度把握能力的地方。咱們畫流程圖的最終目的是讓團隊成員理解咱們的產品設計，而不是須要畫一幅很是詳細的流程圖。理想的狀況應該是以最簡的形式，畫出團隊都能理解的圖表。

流程圖畫法

上面講解了流程圖的定義和分類，下面就進入具體的流程畫法講解

流程圖基本元素

以上爲流程圖中最經常使用的幾種元素。不經常使用的元素就不在此展現了，你們能夠在Microsoft Visio中查看。

泳道圖

泳道圖是流程圖中的一種畫法，是將流程圖中的一些流程節點按操做角色的不一樣而劃分。好比剛纔的數據流程圖其實就採用泳道圖的畫法展現，其中頂部爲兩個不一樣角色——用戶和服務器。同時在豎向的基礎上也能夠添加橫向泳道，以不一樣頁面來給操做分類。

對於涉及到多角色比較複雜的流程圖來講，畫泳道流程圖會看起來更加清晰明瞭。

產品/運營/測試/程序員必備乾貨【資源下載】

www.jianshu.com/p/875b98aba…

流程圖的組成部分

流程圖主要由三部分組成：

主幹流程

分支流程（異常流程屬於分支流程）

子流程

下圖是將以前功能流程圖的例子做爲主幹流程，而後添加了分支流程。咱們在畫流程圖時應該遵循先主幹後分支的順序來描繪流程圖，由於對於大多數用戶來講，主幹流程是最經常使用的路徑。

主幹流程和分支流程你們都好理解，那到底什麼是子流程呢？在畫流程圖的過程當中，有一些流程是會常常遇到的，好比登陸流程、註冊流程、修改密碼流程。對於電商來講，可能有退貨流程、購物券使用流程等等。若是每次畫與之有關的流程圖的時候，都將其再畫一遍，那實在繁瑣。因此，子流程就是將某幾個具備邏輯關係的節點集合而成的，能夠複用在各個地方。

下圖就是將登陸流程變成子流程後的流程圖。

流程圖的結構

流程圖中大體包含四種結構：順序結構、條件結構（又稱選擇結構）、循環結構。基本上大多數流程圖都是由這三種結構組成的。

案例

上面說了那麼多理論知識和概念，那下面就開始真刀實槍地展現一個案例。原本一開始我想以電商產品做爲例子，由於電商產品是須要極強邏輯思惟的產品，而且比較常見。但後來發現淘寶、京東等都極爲龐大和複雜，分析起來過於笨重。轉而想起共享單車是個很是不錯的教材案例。其產品極簡，但背後卻暗藏有趣的邏輯架構。尤爲是市面上摩拜與ofo不一樣的產品解決方案，分析起來更加有對比性。

共享單車的前身

若是要追溯最先的共享單車，恐怕就是政府推出的有樁自行車。其推出目的無非就是緩解交通壓力，以及減小環境污染。而當時受限於成本、技術以及大衆人羣的廣泛素質，有樁自行車的解決方案是極其不方便的。想要租一輛有樁自行車，首先要憑身份證在相關單位辦理IC卡，並繳納押金和預存費用，而後租車和還車只能在定點位置進行。先不談辦理卡片有多麻煩，租車還車有多不方便，超時扣費有多驚人，若是隻單純將其用業務流程圖展現出來，應該是什麼樣的呢？

下面依然以最簡單的業務形態來展現使用有樁單車業務流程圖：

單看有樁單車的流程圖其實沒有任何意義，真正的意義在於有樁單車和目前摩拜與ofo的橫向對比，下面看一下兩家共享單車的業務流程圖：

很明顯能夠看出，不管是有樁單車、摩拜單車仍是ofo單車，在業務流程圖上居然沒有太大區別。那爲何多年以前政府主導的有樁單車平平無奇，而2016年底出現的共享單車紅極一時？那摩拜和ofo兩款大相徑庭的單車，區別點到底在哪裏呢？咱們須要更加深刻地分析每一個業務節點，剖析其功能。

由於單車的使用流程不只是在APP上，還有一部分操做在實體自行車上，這時就不能單使用頁面流程圖，而是要直接使用功能流程圖。而且這裏的功能流程圖不侷限於頁面內的功能，而是要表達用戶對單車和APP的每一步操做。

首先看ofo單車，在APP中支付押金後，接着便須要尋找自行車。而這時咱們發現，雖然ofo有多種單車樣式，多種車鎖機制。但本案例着重講ofo第一代機械鎖，與第二代僞智能鎖。

這兩種鎖其實表明了兩種不一樣的產品解決方案，咱們先討論第一種機械鎖。（所謂機械鎖，其實相似於生活中常常見到的密碼箱。每一個密碼箱有預設的固定密碼，經過撥弄錶盤輸入正確密碼，便可開鎖。而且機械鎖的密碼是固定的，不會改變）。

咱們從路邊找到機械鎖單車，而後打開APP，輸入車牌號或掃描二維碼，從APP中獲得本車的機械鎖密碼，而後輸入密碼，打開單車車鎖。此時APP中會進行倒計時，倒計時結束則開始正式計費。最後，騎行到目的地後，須要將車鎖關閉，而且必須在APP中點擊結束騎行的按鈕，才能結算這次行程的訂單。

看完了ofo的流程，下面來對比看一下摩拜的流程。

摩拜的產品解決方案爲，掃描單車的二維碼之後，摩拜單車的車鎖會自動打開，不須要像機械鎖同樣手動操做。而且在鎖車後，摩拜單車自動會結束行程，無須在APP中點擊結束。在下一次APP打開時，纔會進行帳單結算。

下圖分別爲ofo機械鎖單車使用流程圖和摩拜單車使用流程圖（APP標識表明用戶在APP上的操做）

咱們能夠清楚地看到摩拜的流程比ofo的少了兩個節點，而這就是摩拜對比ofo第一代機械鎖的優點。固然，ofo第一代也有其餘方面是優於摩拜的，好比騎車的溫馨程度。但本文主要聚焦於產品流程，因此並不在單車體驗上花費太多筆墨。

縱觀ofo機械鎖和摩拜智能鎖的解決方案來看，ofo明顯是遜色不少的。機械鎖帶來的問題，不止是使用流程的複雜，還有不少是產品使用上的漏洞。好比，用戶鎖車後，必須手動將密碼撥亂，否則下我的將能夠免費騎行。好比，用戶在騎行結束後，忘記在APP點擊結束，會形成更額外扣費。等等還有不少問題，就不一一列舉了。

說句題外話，這些問題ofo也都明白。機械鎖的解決方案假若只在封閉的校園內運行，那還差強人意。但一經投放到校外市場，那麼這種解決方案無疑會給公司帶來巨大的損失。那爲何ofo明知問題，還要大量投放呢？緣由很簡單，以摩拜拓展的速度，若是他不在當時迅速走出校園，那麼也許永遠也沒機會走出校園了。

言歸正傳。以前的討論，一直避開了一個很是重要的節點——「找車」。拋開路邊隨機看到單車不談，就拿地圖找車來講，ofo第一代機械鎖確定是沒有GPS定位的，爲何也能在地圖上顯示呢？

下面咱們嘗試畫一下ofo對於解鎖的程序流程圖是什麼樣的。

咱們從「APP掃描二維碼/輸入單車編號」此節點開始推導。我要開車牌號爲XXX的單車，那麼就須要獲得密碼，而全部車的密碼，都應該放在ofo的單車數據庫中。咱們不管是掃描二維碼，仍是輸入單車號，本質都應該是將單車編號傳輸給服務器，告訴它我要哪輛車的密碼。服務器查詢到此單車的密碼之後，就傳輸回APP，咱們就看到了此單車的密碼。

由於節省車鎖電源的緣由，服務器此時並無和單車聯繫，而是靠人工輸入密碼打開車鎖。因此ofo在用戶獲得密碼後，就會開始倒計時。倒計時內能夠取消開鎖狀態；倒計時結束，則表明用戶默認開始騎行，計費也今後時開始。

此時若是是iPhone用戶的話，將ofoAPP最小化時，就會發現手機頂部電池電量條變成了藍色。其實，這就是ofo獲取單車行程的要點所在。既然機械鎖沒法向服務器傳輸數據的話，那不如讓用戶手機代替。以獲取手機的定位來獲取單車的騎行路線。而且在停車後，點擊結束騎行時，上報位置，由此服務器來標記此單車停放的位置。而此時上報的位置其實並無單車。這就是ofo地圖上有不少假標記產生的緣由。

ofo採用的這種標記方法其實很是的粗糙，畢竟若是用戶強制結束應用，也就獲取不到騎行路線了。而ofo針對獲取不到騎行路線的狀況，也作了處理，那就是用標記起點到終點，而後根據地圖提供的路線來顯示路程。

上圖我親測的案例。紅色箭頭是個人實際騎行的路線，綠色線是ofo自帶地圖上經過起點和終點計算的路線。

下面咱們繼續分析ofo機械鎖的程序流程圖

注意上圖服務內的部分，看起來步驟很是少，也很是簡單，而真實的服務器確定有更多複雜的邏輯判斷。但對於產品經理畫的流程圖來講，不可能完徹底全描繪編程中的技術細節，並且也不須要產品經理去幫技術想代碼的實現邏輯。咱們要作得是，理解程序宏觀的實現邏輯。

好比，在掃描二維碼後，爲何APP會顯示這輛車的密碼，而不是其餘車輛的密碼呢？很簡單，服務器內確定儲存了全部單車的密碼，而掃描二維碼的過程就是將此單車的ID傳送給服務器，服務器在數據庫中找到密碼後，返回給用戶手中。

服務器在此處理過程當中，確定還會有其餘的判斷，好比此用戶帳號是否正常，有沒有被封號？此單車是否已被標記爲故障車？等等。但你們發現，上面的流程圖內並無畫出這些邏輯判斷，是我忘記了嗎？

其實並非。這裏又不得不提到本文的核心概念——顆粒度。

此圖想表達的是宏觀的程序實現邏輯，是爲了讓讀者更聚焦於問題核心，咱們只須要着重表達主幹流程就好。若是添加更多的分支流程、異常流程，那反而會影響讀者的注意力。因此，仍是老生常談的那句話：畫流程圖必定要先主幹，後分支，千萬別在一開始就盲目追求細節。

言歸正傳，ofo的第一代鎖的解決方案雖然漏洞百出，但依然用其巧妙的方式，實現了地圖上單車位置的顯示。ofo推出的第二代鎖，改進了以往機械鎖的不少問題。其中最大的效果就是車鎖的密碼再也不是固定的，而且鎖車以後，不須要再點結束行程。那既然ofo的鎖已經優化了，那爲何前文還稱他爲僞智能鎖，他和真正的智能鎖差在哪裏呢？爲何ofo的車鎖依然須要手動輸入密碼，而不是像摩拜同樣，車鎖直接彈開？爲何經常在地圖上看到有車，而實際地點沒有車呢？

下面引入一個80、90後童年的回憶：將軍令。

「將軍令」（又名網易賬號保護器） 是廣州網易互動娛樂有限公司自主研發的、具備徹底知識產權的高科技身份認證產品。它是專爲保護網易通行證帳號（遊戲帳號）、直銷商賬號的密碼而出的產品，其特有的60秒密碼動態自動更新技術將盜號風險降到最低。

「將軍令」的產生伴隨着當年夢幻西遊的風靡，其創新技術確實解決了大多數盜號問題。那將軍令的實現機制究竟是如何呢？簡單地說明一下：首先，打開「將軍令」，它會生成一串數字，你在登錄遊戲時，輸入這些數字，系統就會容許帳號登錄。同時，「將軍令」的數字是每隔60秒動態變化的，每次登錄時，「將軍令」的驗證碼都會不同。其實現原理，無非是「將軍令」和服務器保持同一種算法，在同一時間，他們的計算結果是一致的。

回來看ofo的僞智能鎖，其實也是同樣的實現原理。每輛車鎖都有一個單獨的算法保存在服務器，車鎖每隔一段時間就會根據算法，變換一個密碼。而當你打開APP，查看此單車密碼時，服務器使用和車鎖相同的算法算一遍當前時間下的密碼，那此密碼必定是和車鎖當前算的是一致的。

開鎖說完了，下面聊聊關鎖。若是你騎太小黃車就會發現，小黃車的智能鎖關閉之後，並不用手動點APP上的結束行程了。那要作到這點，必定是車鎖與服務器進行了通訊，告訴服務器用戶已經結束了行程，能夠結算訂單了。那既然車鎖能夠和服務器通訊，爲何ofo還要採用上面的將軍令方式來解鎖呢，爲何不直接用服務器通訊告訴單車自動開鎖呢？

其實，就ofo第一代僞智能鎖「海王星"來講，並無作到實時和服務器通訊。在關鎖的時候，只是車鎖單方面向服務器發送消息。而同時服務器收取到消息後，在地圖上顯示其單車的定位。我想ofo這麼作，緣由必定是由於想減小車鎖的耗電量，要知道實時通訊是很是耗電的。

產品/運營/測試/程序員必備乾貨【資源下載】

www.jianshu.com/p/875b98aba…

下圖是ofo的程序流程圖

摩拜單車的智能鎖

上面分析了ofo的機械鎖和僞智能鎖之後，咱們再來看看摩拜單車的智能鎖，到底智能在哪裏。

首先經過實際體驗咱們知道，摩拜單車是不須要輸入密碼的。拋開藍牙本地驗證密碼的方式，那摩拜車鎖須要和服務器實時通訊，才能實現APP掃描以後自動打開。

可能有些讀者不明白爲何必定要實時通訊呢？難道在開鎖時，服務器給車鎖發送打開的指令不行嘛？舉個例子，手機開飛行模式的時候，是沒法接聽電話和數據上網的。手機想接聽電話和上網，就必定要每時每刻和通訊基站連在一塊兒，這樣才能保證通訊基站想要找你的時候能夠找到。若是你和通訊基站斷開，基站是沒法知道你在哪裏的。但若是你想要鏈接基站，只須要關閉飛行模式，打開信號，就能夠和基站從新鏈接起來。這就是摩拜單車須要實時鏈接服務器的緣由。只有這樣才能實現單車在地圖上的定位以及掃碼開鎖。其實摩拜爲了實現此功能也是大費周章。由於車鎖比較耗電，傳統電池是沒法支撐的，因此摩拜的車採用了機械發電的原理。只要有人騎車，就會將機械能轉化爲電能，給車鎖充電。這也解釋了爲何摩拜的車比較難騎，阻力大，車身重。

下面依據上述原理，畫出摩拜單車的程序流程圖

由上圖對比ofo的流程，能夠看出摩拜採用的解決方案是將自行車與服務器鏈接。讓每個自行車都成爲一個終端，實時同步在整個地圖上面。這樣既得到了良好的用車體驗，也收集到了用戶數據。就解決方案來看摩拜是比ofo完善不少的。

單車車鎖的藍牙解決方案

你們在用摩拜或ofo時，可能常常會看到提示：用藍牙解鎖更加快捷方便。那其實現原理是什麼樣的呢？咱們不妨推測一下。首先，用戶在打開藍牙後要讓單車解鎖，那就必定要和單車鏈接起來，不然不可能實現解鎖。那單車的藍牙就必須是實時打開的狀態，以供任什麼時候候用戶進行解鎖。那這時又有一個問題，若是周圍有不少單車，那個人藍牙到底要和哪輛單車匹配呢？這時就體現出掃碼的做用了。我必定是掃碼的時候，告訴服務器：我要解鎖XX編號的單車。那服務器會返回給你這個單車的藍牙"口令"，你經過「口令"與附近的藍牙匹配，能匹配成功的必定是你想開的那輛自行車。由於你手機的藍牙和單車的藍牙距離很是近，藍牙匹配是很是快速的。因此，一般摩拜或ofo都會推薦你們使用藍牙解鎖，這樣的成功率更高，速度更快。就藍牙解決方案來講，ofo和摩拜其實沒有太大區別的。

至於藍牙解決方案的流程圖，就交給你們看成本文的做業。若是你想檢驗一下本文對你到底有沒有幫助，那麼你能夠嘗試去畫一畫藍牙解決方案的流程圖。相信我，很是簡單的。

以上就是整個ofo與摩拜解決方案的對比，其中我也畫出了不一樣階段的流程圖。基本能夠表明我分析案例的一些思路。最主要的仍是讓你們可以理解並應用流程圖到平常產品設計與分析中。咱們在構建流程圖時，若是能按照本文的方法，由業務到程序，由簡單到複雜，那相信必定會讓你的思路更加清晰順暢。

（做者：臻龍，http://www.jianshu.com/u/d63842fef32b）

更多文章與互聯網乾貨資源下載，請關注微信公衆號【非典型運營】