怎樣將一個之前未接觸過的新業務，轉化為研發可以具體開發的詳細產品方案呢？本篇文章主要從範圍層對應搭產品的框架、結構層對應做細節兩個方面展開分析，一起來看一下吧。

具體怎樣將業務轉化為產品的做法，本篇文章主要講以下兩個部分內容：

範圍層對應搭產品的框架（功能框架、非功能框架）

結構層對應做細節（業務流程、業務操作、資訊結構）

一、搭框架：功能框架、非功能框架

1. 功能框架

搭建功能框架的目的是，釐清產品有什麼大功能，釐清業務寬度，邊界，限制，並且保證功能沒有遺漏。

產品經理在梳理產品的功能框架時，容易遺漏，也容易缺乏層次，特別是面對不熟悉的新業務時。

這用UML的用例（Use Case）方法就可實現，用例圖描述了使用者要做的事，在明確要做的事後，我們就可梳理出要實現的功能。

如果對“用例”陌生，但“使用者故事”你應該聽說過。使用者故事就是用例的實踐，用例可表達使用者故事之間的聯絡，兩者的區別是，用例圖需要畫圖，圖形更有層次和結構。

用例圖的具體畫法可以閱讀《火球：uml大戰需求分析》

最簡化理解用例：誰在用什麼系統做什麼事情，用圖形方式就是如上圖的用例圖，進一步標準化表達就是：人員（角色）+系統+動作+事件/事情，如下圖：

透過用例分析，我們能夠梳理清楚這個業務中有多少角色，分別要做什麼事情，需要哪些系統，我們基本上能夠得到一個產品的概要框架。

2. 非功能框架

功能性需求是產品經理工作的重點，如搜尋，下單等，都是功能性需求。但是，還有非功能性需求，如對易用性、安全性等的需求。

可以把功能性需求和非功能性需求彙總，彙總後的模型為“PURPS+模型”。“PURPS+模型”是指主要需求（Primary）、可用性需求（Usability）、可靠性需求（Reliability）、效能需求（Performance），可支援性需求（Supportability）的集合，其中“+”是其他次要需求，這六大項的子項分別如下：

主要需求（Primary）：包括功能、內容、安全性。

可用性需求（Usability）：包括使用者體驗（web產品的瀏覽器適配，各類手機適配要求）、幫助和培訓文件等。

可靠性需求（Reliability）：包括故障率、維修時間等。

效能需求（Performance）：包括響應時間、併發數、吞吐量等。

可支援性需求（Supportability）：包括可維護性需求、可移植性需求等。

其他次要需求（+）：包括資料分析需求、許可需求、介面需求、包裝需求等（在一些階段前期並不需要立即開發資料分析功能，對外開放等，這個根據階段和需求來看）。

以上除第一項的功能外，其它的都是非功能需求，這些也是需要考慮的。可以規定一些專案和指標，比如效能指標：

頁面響應時間不能超過500ms，響應時間太長，使用者會以為出bug

註冊使用者併發數量在某個階段為300/s

訂單提交，支付等併發為100/s

有些需要研發來處理，比如說防止攻擊的安全性。這個需要對具體情況進行分析。

二、做細節：業務流程、業務操作、資訊結構

業務流程和業務操作在梳理業務的動態部分，資訊結構梳理業務的靜態部分。業務流程用流程圖梳理，業務操作用狀態圖梳理，資訊結構用類圖進行梳理。

1. 業務流程（完成）

流程圖的作用是梳理業務，包括業務的主流程、分支流程和異常流程等。

很多時候我們在梳理流程時候，會因為部門、具體運營人員等原因，將流程拆分成很多塊，流程變成了以人為中心而不是以業務為中心，這是很容易犯的錯誤。

工作，業務才是核心，崗位和人是可以隨著工作和業務而調整的。但實際工作中，會因為崗位也是由人來做，有人就有私心，很容易形成一種因人而設崗，而改變業務的，這就會導致業務流程等變形。

進一步考慮，部門、崗位、人員是基於業務而設定的，這些不能反過來制約業務。

解決這個問題的辦法就是要採用端到端的流程設計，可以理解為圍繞某一業務主題下相關流程的有序銜接，或者說是圍繞某一業務主題下的整體流程解決方案，而非區域性流程，這裡包含了跨專業、跨部門的協同，從需求提出到需求滿足，是某個業務的全程閉環。

比如，排隊業務目的是最終讓使用者結束排隊，可以入座點餐。簡要流程是：

當用戶來到餐廳，服務員詢問顧客是否有預訂，如果有預定，時間也對，那麼直接引導到預定位置

如果沒有預定，有合適的空位，那麼也是直接引匯入座

如果沒有預定，而且沒有空位，那麼服務員輸入就餐人數等，列印排隊小票給到使用者，

當餐廳有空位之後，此資訊傳給服務員，服務員呼叫就餐顧客

如果使用者依然在，則核銷排隊小票，被引導到餐廳

如果使用者中途走了，那麼空位將會指派給後面的順延號顧客

如果不考慮端到端流程，那中間就可能要斷幾次，比如收拾餐桌的人員沒有辦法通知迎賓服務員，那餐桌空了也不知道，這就是沒有跨越不同部門來協作；

流程又有業務類流程，支撐類流程，職能類流程；從顆粒度上分，又可以分為主流程，分支流程，操作流程（也可以分為一二三四級流程，意思就是下層是上層的細化）

在繪製流程圖的時候，需要控制好顆粒度，比如主流程不需要很細，將最主要的部分畫出來就可以，比如ipd流程，就是一個流程框架。

我們再往下，就需要進一步細化，比如釋出的整個過程：

確定釋出產品>準備釋出會>釋出會>跟蹤釋出效果>會後總結覆盤

會後總結覆盤我們可以進一步細化：制定覆盤計劃》準備覆盤資料》覆盤會議》覆盤措施落實》資料歸檔。

這樣，我們透過一層一層的細分、拆解，我們能夠將大的流程拆細，到可以直接指導最終的操作人的地步（在產品中，就是研發人員能夠據此進行研發的地步）。

如下方是一個配送的總流程圖，整個配送過程總的為：使用者下單，配送員接單，接單之後前往使用者處取貨，然後進行配送，最終交接。

使用者下單之後，配送員就直接接單嗎，不是，中間還應該有分配機制，使用者怎麼去取貨，中間要不要給取件碼驗證，去了就一定有貨嗎，中間要不要等商家出餐呢，我們進一步拆分。如果我們將參與的角色和流程進展的階段做區分，那麼我們可以得到一個泳道圖（也是流程圖的一種），如果角色不是很多，流程也不復雜，可以不用畫泳道圖。

比如配送員需要認證之後才能正式配送員進行接單，其認證流程如下：

所有的流程不是一成不變的，而是會隨著業務變化而變化，但產品搭建的好的流程，需要：

詳細的流程搭建方法，可以找相關數看，推薦一本《跟我們學建流程體系》-作者陳立雲，羅均麗

對於有多角色參與，並且互相之間有很多互動，實時性要求較高的，我們可以使用時序圖來進行分析，比如以下是微信app交易過程的時序圖，看完整可以點選下方連結。

https：//pay。weixin。qq。com/wiki/doc/apiv3/open/pay/chapter2_5_2。shtml

最頂部的是角色，垂直線是生命線，也即是時間線，從左側最頂部，依次完成動作，箭頭的指向就是動作的落腳點，箭頭指向自己，則表示是自己做了這個事情。虛線箭頭為反饋的資訊，指向落腳點為反饋的物件。

時序圖的畫法參考《火球：uml大戰需求分析》

2. 業務操作

我們用流程圖梳理了業務流程，還要用狀態圖梳理業務操作。狀態圖表述了在一項事務的不同狀態下，人能做什麼操作，該操作會改變事務的狀態。

要梳理這些操作，就要用到狀態圖（State Diagram），狀態圖描述了事務的狀態，以及觸發狀態變遷的操作。

狀態圖的作用狀態圖和流程圖的樣子很類似，但兩者的作用是不同的。兩者的區別是：流程圖梳理的是一項業務的大致過程，狀態圖梳理的是一項業務的細緻操作。

透過狀態圖，我們就可梳理清楚流程，以及流程中的異常情況。思考過程是先粗後細、先主幹再分支、逐步完善的。

1）繪製主幹的狀態

在梳理主幹的狀態時，先要考慮主幹的狀態，並忽略一些次要的分支狀態。

我們還是以配送系統為例子：使用者提交訂單，訂單進入待支付狀態；使用者支付後，訂單為已支付狀態；系統派單之後，訂單為待取貨狀態；配送員取貨之後，訂單狀態為配送中；貨物移交給收件人之後，訂單為已完成，如下圖：

2）進行狀態的拆合

思考每種狀態是否要拆分或合併，通常應多考慮是否要拆分。

我們考慮上面的配送，是否有可以進行拆分的狀態呢。比如其中已支付的訂單是否需要立即配送呢，不一定。一般來說，發貨人可以選擇立即配送，也可以選定某個時間進行派送。這個時候已支付的訂單待派單就會有：a、未到派單時間的訂單（待派）；b、已到派單正在指派的（派單中）；

或者商品的上架與銷售，一些團購及整點秒殺的商品只是顯示在前臺，也就是處於“已上架”狀態，但未到售賣時間，是不能進行銷售的，也就是處於“已上架，待銷售”狀態。只有到了售賣時間，該商品才會變為“銷售中”狀態。

狀態的拆分和合並，需要根據具體業務，具體場景進行區別對待。

3）完善分支的狀態

考慮分支狀態，或者異常狀態。在主流程中，我們基本考慮主狀態，但是肯定有分支和異常，比如待支付訂單如果超時沒有支付，那訂單就會取消，訂單狀態就是已取消狀態。

4）完善角色和操作

在梳理完所有狀態後，我們就要思考狀態之間如何轉移。此時要從角色和操作兩方面思考，簡單說就是梳理清楚誰做了什麼操作導致了狀態的變化。

比如配送系統中，存在發貨人、商家、配送員、收貨人、平臺運營。在這整個過程中，一部分是由發貨人來觸發的，比如提交訂單；一部分是由配送員導致的，比如配送人員出意外，導致訂單需要改派。那就需要將相關的觸發人及導致的狀態進行說明，這樣使得整個狀態機更加的完善。

3. 資訊結構

一個業務越複雜越需要，業務越陌生越需要梳理資訊架構，梳理資訊架構可以使用類圖。用了類圖後，產品經理就能釐清資訊之間的結構關係。

類（Class）是對一組具有相同屬性、操作和關係的物件的描述，簡單說就是分類。

一個類圖包含類名稱、屬性項、數量關係、關聯關係、聚合關係和組成關係。

聚合關係描述了一個較大的事務（整體）是由較小的事務（部分）組成的，組成關係是聚合關係的一種特殊形式。

我們還是按照從總到分邏輯來處理：

步驟一：梳理出所有的類

步驟二：梳理出數量關係

步驟三：明確資訊的屬性

步驟四：考慮效率和靈活性

我們以訂單為例：

我們先梳理所有的分類，一筆訂單有使用者、支付、訂單、物流、發票等。

一個使用者可能有訂單，也可能沒有訂單，所以使用者與訂單的關係是1對0，或1對n；

一筆訂單對應一個總的支付資訊（1對1），支付其實還可以對應支付的渠道（1對n）；

訂單可以進行拆單，比如電商會根據商家，倉庫，商品類別等進行分單，對應關係為1對n；

訂單需要進行配送，則有物流，實際上一筆訂單的物流也可能有多個；

訂單如果不需要開發票，那麼就沒有發票；如果使用者需要開發票，則對應關係為（1對1）；

當我們進一步拆分，在類下面加屬性項，屬性項是屬性值的集合。

我們將訂單的所有類均把對應的屬性值加上，則可以得到如下的一個類圖。根據這個類圖，我們可以明確訂單的相關資訊及對應關係，則訂單的相關資訊就非常清晰了，之後的原型中將相關資訊進行佈局及互動就簡單很多，並且不容易變更，不會造成反覆的原型修改。

UML中的類圖是E-R圖的超集。傳統的E-R圖只針對資料建模，類圖則進了一步，它還允許對行為建模，類圖和E-R圖之間可以相互轉化。下方是訂單個一個E-R圖：

下一篇將介紹怎麼進行互動設計和原型繪製。

專欄作家

Markzou，8年產品經驗，人人都是產品經理專欄作家。主要專注於本地生活、O2O、到家服務、新零售領域；曾任職於多家本地生活垂直領域頭部公司，具有豐富的本地生活行業經驗。

本文原創釋出於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基於 CC0 協議

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