怎樣將一個(gè)之前未接觸過的新業(yè)務(wù)，轉(zhuǎn)化為研發(fā)可以具體開發(fā)的詳細(xì)產(chǎn)品方案呢？本篇文章主要從范圍層對(duì)應(yīng)搭產(chǎn)品的框架、結(jié)構(gòu)層對(duì)應(yīng)做細(xì)節(jié)兩個(gè)方面展開分析，一起來看一下吧。

具體怎樣將業(yè)務(wù)轉(zhuǎn)化為產(chǎn)品的做法，本篇文章主要講以下兩個(gè)部分內(nèi)容：

• 范圍層對(duì)應(yīng)搭產(chǎn)品的框架（功能框架、非功能框架）
• 結(jié)構(gòu)層對(duì)應(yīng)做細(xì)節(jié)（業(yè)務(wù)流程、業(yè)務(wù)操作、信息結(jié)構(gòu)）

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

1. 功能框架

搭建功能框架的目的是，厘清產(chǎn)品有什么大功能，厘清業(yè)務(wù)寬度，邊界，限制，并且保證功能沒有遺漏。

產(chǎn)品經(jīng)理在梳理產(chǎn)品的功能框架時(shí)，容易遺漏，也容易缺乏層次，特別是面對(duì)不熟悉的新業(yè)務(wù)時(shí)。

這用UML的用例（Use Case）方法就可實(shí)現(xiàn)，用例圖描述了用戶要做的事，在明確要做的事后，我們就可梳理出要實(shí)現(xiàn)的功能。

如果對(duì)“用例”陌生，但“用戶故事”你應(yīng)該聽說過。用戶故事就是用例的實(shí)踐，用例可表達(dá)用戶故事之間的聯(lián)系，兩者的區(qū)別是，用例圖需要畫圖，圖形更有層次和結(jié)構(gòu)。

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

最簡(jiǎn)化理解用例：誰在用什么系統(tǒng)做什么事情，用圖形方式就是如上圖的用例圖，進(jìn)一步標(biāo)準(zhǔn)化表達(dá)就是：人員（角色）+系統(tǒng)+動(dòng)作+事件/事情，如下圖：

通過用例分析，我們能夠梳理清楚這個(gè)業(yè)務(wù)中有多少角色，分別要做什么事情，需要哪些系統(tǒng)，我們基本上能夠得到一個(gè)產(chǎn)品的概要框架。

2. 非功能框架

功能性需求是產(chǎn)品經(jīng)理工作的重點(diǎn)，如搜索，下單等，都是功能性需求。但是，還有非功能性需求，如對(duì)易用性、安全性等的需求。

可以把功能性需求和非功能性需求匯總，匯總后的模型為“PURPS+模型”?！癙URPS+模型”是指主要需求（Primary）、可用性需求（Usability）、可靠性需求（Reliability）、性能需求（Performance），可支持性需求（Supportability）的集合，其中“+”是其他次要需求，這六大項(xiàng)的子項(xiàng)分別如下：

• 主要需求（Primary）：包括功能、內(nèi)容、安全性。
• 可用性需求（Usability）：包括用戶體驗(yàn)（web產(chǎn)品的瀏覽器適配，各類手機(jī)適配要求）、幫助和培訓(xùn)文檔等。
• 可靠性需求（Reliability）：包括故障率、維修時(shí)間等。
• 性能需求（Performance）：包括響應(yīng)時(shí)間、并發(fā)數(shù)、吞吐量等。
• 可支持性需求（Supportability）：包括可維護(hù)性需求、可移植性需求等。
• 其他次要需求（+）：包括數(shù)據(jù)分析需求、許可需求、接口需求、包裝需求等(在一些階段前期并不需要立即開發(fā)數(shù)據(jù)分析功能，對(duì)外開放等，這個(gè)根據(jù)階段和需求來看)。

以上除第一項(xiàng)的功能外，其它的都是非功能需求，這些也是需要考慮的。可以規(guī)定一些項(xiàng)目和指標(biāo)，比如性能指標(biāo)：

• 頁面響應(yīng)時(shí)間不能超過500ms，響應(yīng)時(shí)間太長(zhǎng)，用戶會(huì)以為出bug
• 注冊(cè)用戶并發(fā)數(shù)量在某個(gè)階段為300/s
• 訂單提交，支付等并發(fā)為100/s

有些需要研發(fā)來處理，比如說防止攻擊的安全性。這個(gè)需要對(duì)具體情況進(jìn)行分析。

二、做細(xì)節(jié)：業(yè)務(wù)流程、業(yè)務(wù)操作、信息結(jié)構(gòu)

業(yè)務(wù)流程和業(yè)務(wù)操作在梳理業(yè)務(wù)的動(dòng)態(tài)部分，信息結(jié)構(gòu)梳理業(yè)務(wù)的靜態(tài)部分。業(yè)務(wù)流程用流程圖梳理，業(yè)務(wù)操作用狀態(tài)圖梳理，信息結(jié)構(gòu)用類圖進(jìn)行梳理。

1. 業(yè)務(wù)流程（完成）

流程圖的作用是梳理業(yè)務(wù)，包括業(yè)務(wù)的主流程、分支流程和異常流程等。

很多時(shí)候我們?cè)谑崂砹鞒虝r(shí)候，會(huì)因?yàn)椴块T、具體運(yùn)營人員等原因，將流程拆分成很多塊，流程變成了以人為中心而不是以業(yè)務(wù)為中心，這是很容易犯的錯(cuò)誤。

工作，業(yè)務(wù)才是核心，崗位和人是可以隨著工作和業(yè)務(wù)而調(diào)整的。但實(shí)際工作中，會(huì)因?yàn)閸徫灰彩怯扇藖碜觯腥司陀兴叫?，很容易形成一種因人而設(shè)崗，而改變業(yè)務(wù)的，這就會(huì)導(dǎo)致業(yè)務(wù)流程等變形。

進(jìn)一步考慮，部門、崗位、人員是基于業(yè)務(wù)而設(shè)置的，這些不能反過來制約業(yè)務(wù)。

解決這個(gè)問題的辦法就是要采用端到端的流程設(shè)計(jì)，可以理解為圍繞某一業(yè)務(wù)主題下相關(guān)流程的有序銜接，或者說是圍繞某一業(yè)務(wù)主題下的整體流程解決方案，而非局部流程，這里包含了跨專業(yè)、跨部門的協(xié)同，從需求提出到需求滿足，是某個(gè)業(yè)務(wù)的全程閉環(huán)。

比如，排隊(duì)業(yè)務(wù)目的是最終讓用戶結(jié)束排隊(duì)，可以入座點(diǎn)餐。簡(jiǎn)要流程是：

• 當(dāng)用戶來到餐廳，服務(wù)員詢問顧客是否有預(yù)訂，如果有預(yù)定，時(shí)間也對(duì)，那么直接引導(dǎo)到預(yù)定位置
• 如果沒有預(yù)定，有合適的空位，那么也是直接引導(dǎo)入座
• 如果沒有預(yù)定，而且沒有空位，那么服務(wù)員輸入就餐人數(shù)等，打印排隊(duì)小票給到用戶，
• 當(dāng)餐廳有空位之后，此信息傳給服務(wù)員，服務(wù)員呼叫就餐顧客
• 如果用戶依然在，則核銷排隊(duì)小票，被引導(dǎo)到餐廳
• 如果用戶中途走了，那么空位將會(huì)指派給后面的順延號(hào)顧客

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

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

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

我們?cè)偻拢托枰M(jìn)一步細(xì)化，比如發(fā)布的整個(gè)過程：

確定發(fā)布產(chǎn)品>準(zhǔn)備發(fā)布會(huì)>發(fā)布會(huì)>跟蹤發(fā)布效果>會(huì)后總結(jié)復(fù)盤

會(huì)后總結(jié)復(fù)盤我們可以進(jìn)一步細(xì)化：制定復(fù)盤計(jì)劃》準(zhǔn)備復(fù)盤資料》復(fù)盤會(huì)議》復(fù)盤措施落實(shí)》資料歸檔。

這樣，我們通過一層一層的細(xì)分、拆解，我們能夠?qū)⒋蟮牧鞒滩鸺?xì)，到可以直接指導(dǎo)最終的操作人的地步（在產(chǎn)品中，就是研發(fā)人員能夠據(jù)此進(jìn)行研發(fā)的地步）。

如下方是一個(gè)配送的總流程圖，整個(gè)配送過程總的為：用戶下單，配送員接單，接單之后前往用戶處取貨，然后進(jìn)行配送，最終交接。

用戶下單之后，配送員就直接接單嗎，不是，中間還應(yīng)該有分配機(jī)制，用戶怎么去取貨，中間要不要給取件碼驗(yàn)證，去了就一定有貨嗎，中間要不要等商家出餐呢，我們進(jìn)一步拆分。如果我們將參與的角色和流程進(jìn)展的階段做區(qū)分，那么我們可以得到一個(gè)泳道圖（也是流程圖的一種），如果角色不是很多，流程也不復(fù)雜，可以不用畫泳道圖。

比如配送員需要認(rèn)證之后才能正式配送員進(jìn)行接單，其認(rèn)證流程如下：

所有的流程不是一成不變的，而是會(huì)隨著業(yè)務(wù)變化而變化，但產(chǎn)品搭建的好的流程，需要：

• 端到端
• 業(yè)務(wù)視角而不是職能視角
• 不重復(fù)，不遺漏
• 邏輯清晰

詳細(xì)的流程搭建方法，可以找相關(guān)數(shù)看，推薦一本《跟我們學(xué)建流程體系》-作者陳立云，羅均麗

對(duì)于有多角色參與，并且互相之間有很多交互，實(shí)時(shí)性要求較高的，我們可以使用時(shí)序圖來進(jìn)行分析，比如以下是微信app交易過程的時(shí)序圖，看完整可以點(diǎn)擊下方鏈接。

https://pay.weixin.qq.com/wiki/doc/apiv3/open/pay/chapter2_5_2.shtml

最頂部的是角色，垂直線是生命線，也即是時(shí)間線，從左側(cè)最頂部，依次完成動(dòng)作，箭頭的指向就是動(dòng)作的落腳點(diǎn)，箭頭指向自己，則表示是自己做了這個(gè)事情。虛線箭頭為反饋的信息，指向落腳點(diǎn)為反饋的對(duì)象。

時(shí)序圖的畫法參考《火球：uml大戰(zhàn)需求分析》

2. 業(yè)務(wù)操作

我們用流程圖梳理了業(yè)務(wù)流程，還要用狀態(tài)圖梳理業(yè)務(wù)操作。狀態(tài)圖表述了在一項(xiàng)事務(wù)的不同狀態(tài)下，人能做什么操作，該操作會(huì)改變事務(wù)的狀態(tài)。

要梳理這些操作，就要用到狀態(tài)圖（State Diagram），狀態(tài)圖描述了事務(wù)的狀態(tài)，以及觸發(fā)狀態(tài)變遷的操作。

狀態(tài)圖的作用狀態(tài)圖和流程圖的樣子很類似，但兩者的作用是不同的。兩者的區(qū)別是：流程圖梳理的是一項(xiàng)業(yè)務(wù)的大致過程，狀態(tài)圖梳理的是一項(xiàng)業(yè)務(wù)的細(xì)致操作。

通過狀態(tài)圖，我們就可梳理清楚流程，以及流程中的異常情況。思考過程是先粗后細(xì)、先主干再分支、逐步完善的。

1）繪制主干的狀態(tài)

在梳理主干的狀態(tài)時(shí)，先要考慮主干的狀態(tài)，并忽略一些次要的分支狀態(tài)。

我們還是以配送系統(tǒng)為例子：用戶提交訂單，訂單進(jìn)入待支付狀態(tài)；用戶支付后，訂單為已支付狀態(tài)；系統(tǒng)派單之后，訂單為待取貨狀態(tài)；配送員取貨之后，訂單狀態(tài)為配送中；貨物移交給收件人之后，訂單為已完成，如下圖：

2）進(jìn)行狀態(tài)的拆合

思考每種狀態(tài)是否要拆分或合并，通常應(yīng)多考慮是否要拆分。

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

或者商品的上架與銷售，一些團(tuán)購及整點(diǎn)秒殺的商品只是顯示在前臺(tái)，也就是處于“已上架”狀態(tài)，但未到售賣時(shí)間，是不能進(jìn)行銷售的，也就是處于“已上架，待銷售”狀態(tài)。只有到了售賣時(shí)間，該商品才會(huì)變?yōu)椤颁N售中”狀態(tài)。

狀態(tài)的拆分和合并，需要根據(jù)具體業(yè)務(wù)，具體場(chǎng)景進(jìn)行區(qū)別對(duì)待。

3）完善分支的狀態(tài)

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

4）完善角色和操作

在梳理完所有狀態(tài)后，我們就要思考狀態(tài)之間如何轉(zhuǎn)移。此時(shí)要從角色和操作兩方面思考，簡(jiǎn)單說就是梳理清楚誰做了什么操作導(dǎo)致了狀態(tài)的變化。

比如配送系統(tǒng)中，存在發(fā)貨人、商家、配送員、收貨人、平臺(tái)運(yùn)營。在這整個(gè)過程中，一部分是由發(fā)貨人來觸發(fā)的，比如提交訂單；一部分是由配送員導(dǎo)致的，比如配送人員出意外，導(dǎo)致訂單需要改派。那就需要將相關(guān)的觸發(fā)人及導(dǎo)致的狀態(tài)進(jìn)行說明，這樣使得整個(gè)狀態(tài)機(jī)更加的完善。

3. 信息結(jié)構(gòu)

一個(gè)業(yè)務(wù)越復(fù)雜越需要，業(yè)務(wù)越陌生越需要梳理信息架構(gòu)，梳理信息架構(gòu)可以使用類圖。用了類圖后，產(chǎn)品經(jīng)理就能厘清信息之間的結(jié)構(gòu)關(guān)系。

類（Class）是對(duì)一組具有相同屬性、操作和關(guān)系的對(duì)象的描述，簡(jiǎn)單說就是分類。

一個(gè)類圖包含類名稱、屬性項(xiàng)、數(shù)量關(guān)系、關(guān)聯(lián)關(guān)系、聚合關(guān)系和組成關(guān)系。

聚合關(guān)系描述了一個(gè)較大的事務(wù)（整體）是由較小的事務(wù)（部分）組成的，組成關(guān)系是聚合關(guān)系的一種特殊形式。

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

1. 步驟一：梳理出所有的類
2. 步驟二：梳理出數(shù)量關(guān)系
3. 步驟三：明確信息的屬性
4. 步驟四：考慮效率和靈活性

我們以訂單為例：

我們先梳理所有的分類，一筆訂單有用戶、支付、訂單、物流、發(fā)票等。

一個(gè)用戶可能有訂單，也可能沒有訂單，所以用戶與訂單的關(guān)系是1對(duì)0，或1對(duì)n；

一筆訂單對(duì)應(yīng)一個(gè)總的支付信息（1對(duì)1），支付其實(shí)還可以對(duì)應(yīng)支付的渠道（1對(duì)n）；

訂單可以進(jìn)行拆單，比如電商會(huì)根據(jù)商家，倉庫，商品類別等進(jìn)行分單，對(duì)應(yīng)關(guān)系為1對(duì)n；

訂單需要進(jìn)行配送，則有物流，實(shí)際上一筆訂單的物流也可能有多個(gè)；

訂單如果不需要開發(fā)票，那么就沒有發(fā)票；如果用戶需要開發(fā)票，則對(duì)應(yīng)關(guān)系為（1對(duì)1）；

當(dāng)我們進(jìn)一步拆分，在類下面加屬性項(xiàng)，屬性項(xiàng)是屬性值的集合。

我們將訂單的所有類均把對(duì)應(yīng)的屬性值加上，則可以得到如下的一個(gè)類圖。根據(jù)這個(gè)類圖，我們可以明確訂單的相關(guān)信息及對(duì)應(yīng)關(guān)系，則訂單的相關(guān)信息就非常清晰了，之后的原型中將相關(guān)信息進(jìn)行布局及交互就簡(jiǎn)單很多，并且不容易變更，不會(huì)造成反復(fù)的原型修改。

UML中的類圖是E-R圖的超集。傳統(tǒng)的E-R圖只針對(duì)數(shù)據(jù)建模，類圖則進(jìn)了一步，它還允許對(duì)行為建模，類圖和E-R圖之間可以相互轉(zhuǎn)化。下方是訂單個(gè)一個(gè)E-R圖：

下一篇將介紹怎么進(jìn)行交互設(shè)計(jì)和原型繪制。