編輯導語：産品經理在日常工作中，經常會用到流程圖，流程圖也分很多種類型和作用，但流程圖梳理起來并不簡單，其中最多見的是業務類流程圖；本文詳細介紹了流程圖的分類以及業務流程圖的處理辦法。

我們産品在梳理較為複雜的業務流程的時候可能涉及到多個組織部門，業務場景、系統交互等等，梳理起來十分困難。

光是如何布局都比較頭疼，最後終于把業務的千絲萬縷梳理清晰了，才發現業務流程圖十分龐大複雜。

在和領導彙報同時交流的時候，ppt和word裡面都塞不下；最後用着最小的字體，将整體流程講解完成發現大家也是很難理解。

這裡說明了我們日常流程圖存在三個問題：

針對上述的問題，建議産品能夠明确對應的流程圖的作用與區分。

01

常見的流程圖：

1. 業務交互流程圖
2. 系統交互流程圖
3. 頁面交互流程圖
4. 時序圖
5. 數據交互圖等

其中：

面向業務：業務交互流程圖

用于标識業務流轉規則，需要有事項的明确開始和結束節點，需要明确的職責劃分與對應的輸入輸出标準。整體保證流程或者事項能夠通過業務流轉與解決。

面向産品：系統交互流程圖

當某個功能涉及多個子系統的時候，需要從業務規則中抽象出需要的功能點，并将這些功能點依據産品定位進行區分，确定系統職責。這個時候可以初步設計可能需要的接口或者大緻的交互機制與主鍵（沒有必要定死幾個接口和所有字段，這個接口更像是業務屬性的接口）。

面向交互：頁面交互流程圖

用于表述用戶操作的細節，這個時候需要将用戶場景理解清晰，用戶操作需要用到哪些頁面，這些頁面之間的跳轉返回邏輯是什麼，有哪些校驗條件。這裡更加偏重用戶體驗，可以交給我們的交互同學協助完成。

面向開發：時序圖

梳理時序圖可以幫助開發梳理邏輯，也可以自己驗證設計的邏輯是否閉環，很多異常場景可以在梳理時序圖的時候自我反省出來。

面向開發：數據交互圖

當項目涉及多個産品的時候，需要單獨整理數據詞典、接口清單、與數據交互圖。

數據交互圖在設計的時候有助于全局觀審視系統設計。可以避免後端系統系統需要的字段，前端系統沒有下傳的問題。

這個舉一個例子：

數據流為：A–B–C 如果C系統需要某個字段是A系統産生的，但是B系統不需要，可能B系統在梳理的時候就會忽略，導緻C系統重要字段缺失。如果梳理清晰數據交互圖就可以避免類似的問題。

有了以上的對于流程的圖劃分，我們就可以“看人下菜”，即提高的溝通的效率，也讓對方容易理解。而不是拿一張流程圖和所有人講，結果大家都不清晰。并且上述流程圖的輸出排序也建議按照上述排序進行輸出。

02 如果某個流程圖過于複雜怎麼辦?

這個多見于業務流程圖，因為業務流程可粗可細，如果業務糾結于一些細節，光是一個小的場景，就可能會有多個複雜的邏輯，并且需要展示流程全貌，這個時候你的業務流程圖就是巨型的，及時你僅僅繪制業務層面的内容，其體量也很大，這個時候如何處理？

建議大家可以從幾個層級來細分：

• 部門層級：在了解業務的組織架構于職責之後，通過部門的維護進行業務場景梳理，比如銷售部門，财務部門，行政部門。以這個維度進行業務場景的劃分，重點在于了解業務主線于全貌，和整體流程的職責劃分。
• 崗位層級：在上述基礎上将部門所負責的模塊拆分到崗位。這個時候可以明确流程處理邏輯，已經可以通過崗位流程圖了解到事項處理的條件與要求。并且明确責任到崗位，明确每一個崗位輸入和輸出的标準産物。
• 操作層級：針對某個崗位的具體操作進行梳理，在明确輸入與輸出條件的基礎上，明确每一步執行的動作。雖然不能達到操作手冊的細度，但是要求可以将對應的畫面在腦海中勾勒出來的程度。
• 場景層級：如果這塊業務十分複雜，可以将其分為幾個場景來明确步驟，比如依據地點進行劃分，依據處理事項的具體類型進行劃分。

（小技巧：對于一些特殊場景可以單獨抽出來，不要影響主線流程的理解；對于分支場景也可以僅僅在主線流程裡面一筆帶過，單獨一個頁面進行整理。）

本文由 @離譜 發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部