產品經理的利器:業務流程梳理實用技巧

1 評論 10276 瀏覽 96 收藏 11 分鐘

在中高級產品應該掌握的技能模型里,流程梳理能力必不可少,它可以幫助我們快速理解需求,還能清晰簡潔地傳達產品設計邏輯,為產品設計的產出做有力的支撐。那么,業務流程到底要梳理什么呢?怎么進行流程梳理?一起來看一下吧。

筆者在多年的工作中接觸過很多產品經理,私以為產品經理的進階之路可以簡單的劃分為四個層級:初級(照葫蘆畫瓢實現功能點)、中級(前后端兼顧實現功能模塊)、高級(拆解業務模式搭建產品架構)、頂級(規劃商業模式),在中高級產品應該掌握的技能模型里,流程梳理能力必不可少,它可以幫助我們快速準確地理解需求,還能清晰簡潔地傳達產品設計邏輯,為產品設計的產出做有力的支撐。

今天我們來聊一下:業務流程梳理到底要梳理什么?為什么要進行流程梳理?怎么進行流程梳理?

一、梳理什么

最初開始學習流程梳理的時候,常常會遇到這樣的問題:去網上找現成的流程圖覺得很高級但是不理解為什么這樣,就是所謂的“不明覺厲”;去看流程梳理的書籍又覺得冗長,無法抓住重點快速上手。

其實業務流程的梳理核心就是三個點:發現需求點、拆解實現過程、產出流程圖。

1. 發現需求

但凡產品設計,都是為了給某個群體實現某個目的,這里所說的“某個群體”就是指的需求方、“某個目的”就是指的產品功能,所以我們在產生梳理流程的念頭的時候,就要先把上面這句話當做填空題答出來:為了給____實現_____。

這里要注意,產品人員往往不止負責一個模塊,對接的同一個部門也不會只有一個業務崗位,所以這個填空題不是唯一的,在接收到了業務一套場景以后,我們可能會從一套場景中整理出多個“答案”,記錄下這些答案,這就是我們要實現的需求。

2. 拆解過程

根據第一步找到的答案,逐個梳理實際的業務實現方式,這個過程中要注意以下幾點:

1)找業務規則

如果業務方已經有既定的線下流程,則可以進行人員訪談,獲得的訪談結果再找業務鏈條上的每個角色去核對矯正,就能快速的得到一套業務邏輯;

如果業務方還沒有線下流程,就需要我們自己去找一找有沒有業務的管理規章規則,從中去尋找核心的點,包括核心數據是什么、有沒有審核環節、有沒有異常處理機制等;

如果連內部的文檔也沒有,就只能到外部去收集調研,實際的用一用競品,看看業內的處理流程,再梳理成自己的理解給到需求方進行矯正。

2)梳理流程的公式

在實際進行流程梳理的時候是有一套公式可以遵循的,因為流程是客觀事物(人)受到一定條件而產出一定結果,所以每一個流程的環節的組成應該包含如下要素:人(或事物)+規則(或條件)+行為(或動作)。舉個例子:

用戶申請售后=注冊用戶(人)+名下有有效訂單(規則)+提交售后(行為);

客服處理售后=客服(人)+判斷售后單據合理性+處理售后。

當然,在這個過程中條件還會區分不同判斷結果,動作也需要根據條件區分情況,這就需要根據實際的業務情況一層一層逐步深入細化。

3. 產出流程圖

這一步單獨拎出來是因為人在工作中往往想得多做的少,或者完美主義思想覺得想不清楚就不能動筆,這樣會嚴重影響工作效率。

這里建議大家覺得理解了80%的時候就可以開始試著畫一畫流程圖,拿著畫出來的流程圖再去找業務溝通,畢竟圖形化的東西更容易讓人理解,而且已有產出的基礎上去修改,不但能讓需求方更方便反饋,還能讓我們后續的工作更明確,好推進。

二、實現中要注意的點

1. 必要性

流程梳理會幫助我們提高工作效率,但不是每個需求都必須要進行流程梳理,實際工作中要根據產品的階段、需求的大小、涉及到的業務范圍等去綜合考慮。一般來講:

1)產品處于早期階段,必要性比較高,一方面盡早為產品模塊劃分范圍有利于后續需求的分類,另一方面早期文檔作為組織過程資產有利于后加入人員對產品的快速熟悉;

2)需求越大越有必要,需求涉及到的產品模塊越多,越需要通過流程整理核心邏輯,方便開發和測試人員理解和實現;

3)業務范圍越大越必要,有些涉及到多個業務方的需求,即便需求不大也需要梳理流程,便于厘清各個部門之間的職責,這也是出于對產品實現后的業務實際使用考慮。

2. 層次和范圍

我們看地圖的時候,如果看全球級別的則能看到宏觀的關聯,但是看不到細節;如果看省市級別的則能看到細節,但是缺少了宏觀的理解。畫圖也是一樣如果我們將顆粒度控制的比較粗糙,比如只表示部門之間的協同,就會忽略掉每個部門內部的流程,但是如果全部詳細到每個部門內部的流程,就容易讓人看暈了頭。

為了能兼顧宏觀和細節,我們有必要準備多套流程圖:通過大的模塊之間的流程展示宏觀的需求范圍(比如結構圖)、再拆解每個模塊內的流程分別的梳理和展現(業務流程圖),甚至可以針對一些流程中重要的要素再整理一套對應的狀態變更的流程(狀態圖),全方位地展示業務邏輯。

3. 人和角色

在實際的流程圖制作過程中,常出現的一個問題就是角色的維度不一致,比如將某個環節的角色直接寫成了某個人,因為在實際的業務調研中,有些角色確實只有一個人負責,而講述流程的業務人員基于自己的經驗也會反復強調“到了那個環節就讓XX處理”這樣的業務場景,容易迷惑調研的人。

4. 逆向場景

流程中的逆向場景是很容易被忽略的,在流程繪制的過程中,只要涉及到判斷或審批的情況,就應該考慮被駁回的流程如何處理。逆向的流程中可能還存在循環的情況,如果遇到循環則需要考慮脫離循環的條件,避免讓流程陷入“死循環”。

三、常用的圖

當我們搜索“流程圖”的時候,網上可供參考和學習的類型有很多,這里簡單列舉三種筆者在實際工作中最常用到的圖形,實際上掌握了這三種圖形,就已經可以處理產品工作中大部分需要圖形化示意的場景了。

1. 業務流程圖

產品最常用的流程圖,用于描述角色之間的業務關系或者系統之間的信息流向,根據圖形中維度的不同,可以用于業務需求收集階段整理業務流程,也可以在產品設計過程中整理系統模塊流程。

2. 結構圖

常規的結構圖一般用于組織結構的表達,筆者在撰寫中后臺系統中結構層次比較復雜的需求時,會借用此概念,用以自上而下的解釋各層概念的調用關系。當然,這個也可以用來整理頁面或者模塊的結構。

3. 狀態圖

用于表示一個要素的屬性(網上經常稱作“實體”)變化的情況,能夠表達出變化的條件和每種條件下變化后的結構,梳理出狀態圖方便我們在產品設計時全面的考慮每種狀態下的場景,也方便開發對要素進行理解和實現。

四、結語

市面上的流程圖還有很多種類型,特別是UML模型中,包含了很多現成的流程圖規范,感興趣的朋友可以查閱資料深入學習,但是要注意的是“學以致用”,在實際的工作中使用和學習效率會更高。

本文由 @夢溪 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 人(或事物)+規則(或條件)+行為(或動作)
    換句話理解:誰+什么時間+做了什么

    來自北京 回復