怎樣将一個之前未接觸過的新業務，轉化為研發可以具體開發的詳細産品方案呢？本篇文章主要從範圍層對應搭産品的架構、結構層對應做細節兩個方面展開分析，一起來看一下吧。
具體怎樣将業務轉化為産品的做法，本篇文章主要講以下兩個部分内容：
- 範圍層對應搭産品的架構（功能架構、非功能架構）
- 結構層對應做細節（業務流程、業務操作、資訊結構）
一、搭架構：功能架構、非功能架構
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 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。