你畫的流程圖，全組人都能看得懂嗎？

自媒體行業有一句不知道是誰說的名言：用戶有圖就不會看文字,有視頻就不會看圖。雖然這裏反應出了現代人的一些浮躁，但也從側面說明在溝通效率方面，視頻優於圖片，圖片優於文字。而平時你們又都在抱怨前人沒有留下文檔，本身又不寫文檔。用視頻來記錄文檔製做成本過高，而用文字記錄文檔有沒人看，因此使用圖表來描述文檔就顯得經濟實惠一些。

畫過的流程圖沒人看，多數是由於閱讀的人看不懂。這就像籃球比賽中的傳球同樣，傳球失誤多半責任是傳球人的動做不規範致使。文檔也是同樣，閱讀的人看不懂，多半是文檔做者描述問題不清晰。因此針對流程圖咱們須要有一套標準化的定義。

先貼一個流程圖，你們看看可否理解需求。

• 圓角矩形表示程序開始或結束

• 矩形表示單據的狀態

• 帶箭頭的線表示數據流向

• 菱形表示數據流向的判斷

程序員報銷審批，金額大於等於1000，提交單據後須要經理審批，金額小於1000直接由財務審批，經理經過後須要財務審批。「經理待審批」和「財務待審批」這兩種單據的狀態必定對應各自的操做頁面，用矩形表示。「經理審批經過」這是一個數據流向，對應「經理待審批」這個頁面的「經過」按鈕的事件，用帶箭頭的線表示。程序員提交的報銷金額是否大於等於1000這個判斷就是數據流向的判斷，用菱形表示。

什麼狀況下須要畫流程圖

若是業務流程中只有一個步驟的審批，那就不用畫流程圖，畢竟流程簡單看代碼也花不了多少時間。大於一步的審批就必定要畫流程圖。

畫流程圖的注意事項

• 帶箭頭的線上必定要註明操做數據的過程，好比「審覈經過」。
• 線與線不要交叉。
• 不要多條線使用一個箭頭。
• 流程圖必定要有開始和結束的圓角矩形框，讓讀者第一眼就能看出數據的總體，這也是作事的規矩，善始善終。

記得個人初中數學老師講座標系的畫法，他說畫座標系必定要寫x，y和0，若是誰只畫了一個十字架，即便題做對了也不給分。

• 流程圖的「開始」要畫在上面，「結束」要畫在下面，正常的數據流向要自上而下，例如「審覈經過」，異常的數據流向能夠自下而上，例如「審覈拒絕」。由於人的潛意識都是自上而下的，都是但願獲得確定回答的。因此請順着人類的潛意識思惟描述需求。
• 流程圖能夠有多個結束，可是隻能有一個開始。
• 流程圖儘量在一屏顯示，或者可以打印在一張A4紙上，若是一張圖中內容過多，建議拆分爲多張流程圖。

流程圖工具

• visio，微軟出品，僅限windows。
• wps，可導出jpg、png等圖片格式，導出svg、pos格式需會員充值。
• www.processon.com 瀏覽器在線編輯，可導出圖片格式和svg、pos格式文件，但免費模式想加最多隻能建立9張流程圖。
• Gliffy Diagrams 谷歌瀏覽器插件，只能導出圖片格式和自研的gliffy文件。

注：svg和pos文件是流程圖通用格式文件

畫流程圖有啥用

• 流程圖是溝通的利器。在釘釘上一張圖能說明白的事就不用浪費太多的口舌來解釋。
• 流程圖是離職交接的利器，有了流程圖能夠避免上家公司接手的同事追殺到大家家。
• 流程圖仍是需求變動的利器。產品經理要改需求，只要看看流程圖上改了哪些矩形，就知道此次變動須要改哪些頁面；流程圖上改了哪些線，就知道此次要改哪些按鈕的代碼邏輯。
• 流程圖就是需求。由於如今的需求你和神都瞭解細節，等過了2個月就只有神能瞭解細節了。我開發的功能，將來新人或者其餘部門的人對此有疑惑他們只能來問我，若是本身開發的功能本身都說不明白，那tm就尷尬了。

寫在最後一

大學的軟件工程老師說過，只要需求文檔肯定，你們的工做就須要低頭寫代碼。工做以後我一直認爲這是理論脫離實踐的笑話。直到我深刻研究流程圖才發現，流程圖就是對應着代碼，菱形有幾個向下指的箭頭，那麼頁面是就有幾個與之對應的按鈕（也多是單選框）。

寫在最後二

若是產品不畫流程圖，我們技術就畫。與產品經理碰撞後必定要敲定一個最終版的流程圖用於開發編碼，由於沒人會看那冗長的文字版需求。最後貼一個酸奶爸爸以前畫的流程圖，臭顯擺一下。