在推進(jìn)工作的過程中，有效的溝通至關(guān)重要。

一、背景

最近負(fù)責(zé)公司流程再造這個項目，這個項目的背景是：為了跟上公司業(yè)務(wù)的發(fā)展，要將公司已有內(nèi)部系統(tǒng)中的業(yè)務(wù)流程功能全部梳理和重構(gòu)，解決大部分歷史遺留的混亂問題并增強擴展性。系統(tǒng)由兩個ERP系統(tǒng)和一個CRM系統(tǒng)及一些獨立工具構(gòu)成，包含銷售、運營、市場、財務(wù)、人事、客戶管理等模塊。

在推進(jìn)工作的過程中，不斷的遭遇了大量問題并努力解決，這次主要聊一個由于系統(tǒng)的復(fù)雜性，影響概念設(shè)計及溝通交流的問題。由于系統(tǒng)本身既龐大又結(jié)構(gòu)復(fù)雜，且設(shè)計時需要協(xié)調(diào)溝通極多的的部門負(fù)責(zé)人與項目干系人配合，而他們對于軟件工程或組織系統(tǒng)的認(rèn)識水平又參差不齊，就導(dǎo)致很難在統(tǒng)一的概念上進(jìn)行溝通，尤其是在業(yè)務(wù)層面到開發(fā)層面的鴻溝，著實給我造成了許多困惑。

二、問題分析

仔細(xì)細(xì)考后，基于易理解性和工作流合理性提出以下幾點假設(shè)原因：

1. 與業(yè)務(wù)部門來說，更多的關(guān)注從自己視點出發(fā)的內(nèi)容，甚至可能完全忽視與自己工作相關(guān)的其他部門工作流程。例如，銷售人員可能根本不在意財務(wù)人員怎么審核資金到賬，而只在乎完成簽約銷售立刻獲取自己的業(yè)績。而于此相反，財務(wù)人員就更關(guān)注，資金到賬的信息一定要自己牢牢匹配確認(rèn)以致犧牲時間的延遲。
2. 抽象的概念圖表達(dá)方式并不容易被所有人理解。這些圖抽象的能力讓我們在設(shè)計上得心應(yīng)手，卻讓一些沒經(jīng)過訓(xùn)練的非專業(yè)人員難以接受。
3. 業(yè)務(wù)概念與系統(tǒng)概念的嚴(yán)重脫節(jié)。例如在現(xiàn)實業(yè)務(wù)流程中需要業(yè)務(wù)管理人員審核的過程，在系統(tǒng)內(nèi)部的概念卻是客服審核。類似的許多功能與概念極度脫節(jié)，以至于業(yè)務(wù)人員也僅熟悉常用的小部分功能。
4. 我自己對于系統(tǒng)復(fù)雜程度的低估，沒能完全窮舉出系統(tǒng)內(nèi)的所有相關(guān)流程。接手這種唯一的文檔就是代碼，又遍布?xì)v史遺留問題的復(fù)雜系統(tǒng)，真的就差把自己埋坑里了。

而其中第一點問題從解決真實問題的角度適合引入系統(tǒng)論思考，第三點問題則正是項目立項之初就明確需要解決的問題，第四點就只剩降低我的自我效能感這一個用處了。

于是這篇文章將主要從第二點問題出發(fā)，同時引入第一點問題的影響因素，記錄我的思考、邏輯及解決方案。也就是，如何規(guī)范設(shè)計流程并描繪讓各部分干系人都更易理解的表達(dá)。

（這里不聊為什么選擇用圖的形式表達(dá)，我認(rèn)為信息可視化是在制作難度和可理解性中最平衡的溝通方式。）

三、問題研究

1、圖的類型

先來熟悉一下慣用的幾種作圖方式，流程圖、泳道圖、時序圖、用例圖、原型圖，不過下文的圖并沒有按照嚴(yán)謹(jǐn)?shù)腢ML方式作圖（現(xiàn)在連開發(fā)都不用嚴(yán)格的UML了吧？），僅作參考使用。好，開始一個個分析優(yōu)缺點，仔細(xì)研究問題。

流程圖

優(yōu)點：邏輯、概念清晰，且很容易做顆粒度把控。

缺點：更多表達(dá)系統(tǒng)的行為，較為忽視人員角色與系統(tǒng)的互動，實際制圖中更多是偏向開發(fā)側(cè)表達(dá)，對跨部門溝通不夠友好；表達(dá)數(shù)據(jù)、狀態(tài)等信息時略顯力不從心，因為如果引入其他形式表示會導(dǎo)致圖表過于復(fù)雜，都用同一種形式展示又很難區(qū)分。

泳道圖

優(yōu)點：較為完整描述流程，相當(dāng)于在普通流程圖中加入角色，展示所有涉及模塊的交互；能直觀感受特定泳道內(nèi)的所有行為。

缺點：系統(tǒng)高于復(fù)雜的時候，圖極大極復(fù)雜，可讀性很差；且信息展示方式不夠直觀，與常規(guī)認(rèn)知習(xí)慣不匹配。

時序圖

優(yōu)點：可以說是很細(xì)了，甚至能完全表達(dá)系統(tǒng)各細(xì)節(jié)環(huán)節(jié)的最細(xì)小行為，不但能表示各行為順序，還能在數(shù)據(jù)層面表示網(wǎng)絡(luò)請求的方式。能達(dá)到一張圖不用解釋的境地，可以算泳道圖的升級版。

缺點：以我目前的經(jīng)驗來看，這種圖如果開發(fā)同學(xué)不需要就沒什么用，因為它的可讀性也差，且顆粒度很細(xì)的時候也有信息量過載問題，當(dāng)涉及回調(diào)及同步異步問題時需要更專業(yè)的讀圖技巧，增加溝通成本，不如讓開發(fā)同學(xué)自己處理設(shè)計。

用例圖

優(yōu)點：好處是很容易理解，尤其是在遍歷單角色任務(wù)時很實用，且容易按照顆粒度劃分層次。

缺點：在概念設(shè)計上容易忽視整體，流程完整性難以直觀感受。除了對單個角色做MECE分析的時候比較有用，其余用處不大，畢竟測試同學(xué)會自己處理用例。

原型圖

優(yōu)點：這應(yīng)該是所有人都最喜歡看的圖，好處很多，既直觀，又能很好的展示功能，還可以做交互標(biāo)記。按顆粒度可分低保證高保真，低保證便于溝通，高保真方便用戶測試。

缺點：原型圖已經(jīng)很貼近實際開發(fā)的階段了，而不是所有項目（甚至不建議任何項目）都是直接到原型階段的，前期的思考和論證至關(guān)重要，原型只不過是之前所有階段的結(jié)果總結(jié)，反復(fù)修改原型極易導(dǎo)致嚴(yán)重的項目進(jìn)度管理問題，所以直達(dá)原型的設(shè)計流程是很成問題的。

2、表達(dá)元素分析

• 角色，表示場景下涉及的角色
• 行為，表示場景下作出的動作
• 數(shù)據(jù)，表示場景下信息數(shù)據(jù)的流動
• 狀態(tài)，表示場景下引起的狀態(tài)變化
• 界面，表示場景下位于什么界面及其樣式

3、設(shè)計階段

先細(xì)分幾個設(shè)計階段，方便明確在各個階段的目標(biāo)以選擇需要的方案。

• 業(yè)務(wù)概念階段，此階段主要關(guān)注在現(xiàn)實業(yè)務(wù)場景下，需要做什么，和業(yè)務(wù)流程規(guī)范的設(shè)計
• 功能概念階段，此階段主要關(guān)注產(chǎn)品如何滿足業(yè)務(wù)概念的要求，需要設(shè)計哪些功能，以及各個功能模塊之間如何組織協(xié)調(diào)
• 交互原型階段，此階段主要關(guān)注產(chǎn)品具體實現(xiàn)的展示方案，用戶如何操作，界面如何反饋

四、解決方案

在經(jīng)歷了一大波實際環(huán)境嘗試之后，得出了一些目前比較適用的方案。首先明確不存在一張解決所有問題的圖表達(dá)方式，這也是為了在可讀性和完整性中尋求平衡。

1、業(yè)務(wù)用例圖

首先在業(yè)務(wù)概念階段，需要一種能表示系統(tǒng)內(nèi)全部流程的圖，并能展示角色的差別，方便跨部門溝通。重點在于簡單快速易理解，在開始設(shè)計前敲定所有業(yè)務(wù)影響的范圍。

所以選用普通流程圖易理解的表達(dá)方式，直接引入角色的概念，若圖表過于復(fù)雜則從顆粒度著手，再引入「包」和「領(lǐng)域」切分的概念就很完美了。

一整張圖的形式

可調(diào)顆粒度行為并引入角色概念，真是和概念思維較弱的同學(xué)溝通的利器，也方便進(jìn)行整個系統(tǒng)架構(gòu)的思考，因為合理切分/加大顆粒度后，對大信息量的支持很友好。

例圖前半部分被我截掉了，實際是一整張業(yè)務(wù)流程圖，表達(dá)了全部主要的業(yè)務(wù)流程。圖中也可以用一些小標(biāo)簽的方式表達(dá)一些額外概念。例如我圖例紫色的小圖標(biāo)表示該操作允許業(yè)務(wù)員協(xié)助客戶完成。

切分引入集合的形式

由于系統(tǒng)大小限制，此處可能需要細(xì)分任務(wù)顆粒度，酌情增加細(xì)分階段。嘗試?yán)妙愃艱DD領(lǐng)域切分的思路分割復(fù)雜系統(tǒng)為獨立系統(tǒng)，概念或流程打包獨立封裝，來簡化自上而下設(shè)計時信息量過大的問題。

將「用戶首次進(jìn)入」流程封裝，在其他流程中直接引用，方便進(jìn)行整體管理。

能把流程簡化到什么程度呢？見下圖

太輕松有沒有？

2、數(shù)據(jù)狀態(tài)圖

其次我們需要在完善功能概念階段，需要一些能更好的表達(dá)抽象對象的圖，來作為產(chǎn)品設(shè)計的工具，補充思考邊界問題并盡量窮盡所有可能性，避免出現(xiàn)設(shè)計BUG。還有梳理狀態(tài)和數(shù)據(jù)的關(guān)鍵變化。

行為數(shù)據(jù)圖

數(shù)據(jù)如何產(chǎn)生？由某種行為，引起某處的變化，產(chǎn)生數(shù)據(jù)。所以圖中要表示「地點」（頁面），「行為」（操作），「數(shù)據(jù)項」（輸入輸出）。

由于怕干擾開發(fā)同學(xué)數(shù)據(jù)庫設(shè)計和選擇數(shù)據(jù)存儲方案的思路，就采用了一個「數(shù)據(jù)存儲/記錄」的概念集合來表示采集的數(shù)據(jù)集合。需要表示數(shù)據(jù)項額外限制的，可以在數(shù)據(jù)項后加括號，例如：版本1-1（最大字符數(shù)25，disable狀態(tài)）。

表層交互即用戶能感受到的交互，底層交互則為用戶感受不到的系統(tǒng)內(nèi)部交互，分開主要因為有些時候底層交互觸發(fā)的節(jié)點與表層交互觸發(fā)節(jié)點不一致（系統(tǒng)總是會在背后默默地多做一些事情）。

狀態(tài)圖

同理狀態(tài)也是由行為產(chǎn)生變化，所以每步狀態(tài)變化必然帶著一個前置動作。

括號「（-）」內(nèi)的狀態(tài)表示前臺展示的狀態(tài)對應(yīng)的狀態(tài)，「 [ – ] 」處內(nèi)容為注釋。

3、交互原型圖

最后在交互原型階段，需要一種表示界面元素的圖來展示功能，并引入交互表達(dá)，這個都很熟悉，不多說了。

五、后記

當(dāng)設(shè)計過于復(fù)雜的系統(tǒng)時，采用自頂向下的設(shè)計方式更容易搭建合理的體系。而穩(wěn)步推進(jìn)項目的好方法就是細(xì)分任務(wù)階段，階段性確認(rèn)與階段性設(shè)計（有點類似CI/CD的概念？）。

多層確認(rèn)與詳細(xì)的溝通一定不會帶來壞處，讓伙伴們明白「業(yè)務(wù)先行」與「集體參與」，會使設(shè)計方案更穩(wěn)定且耐受考驗。

內(nèi)容均來源于個人思考，或有偏頗，或有不足，期待你的交流，這會讓我們一起進(jìn)步。

作者：Jokul，Blog：https://jokul.cc。

本文由 @Jokul 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議