如何將業(yè)務(wù)轉(zhuǎn)化為產(chǎn)品設(shè)計(jì)

如何將業(yè)務(wù)轉(zhuǎn)化為產(chǎn)品設(shè)計(jì)具體怎樣將業(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ù)寬度，邊界，限制，并且保證功能沒(méi)有遺漏。產(chǎn)品經(jīng)理在梳理產(chǎn)品的功能框架時(shí)，容易遺漏，也容易缺乏層次，特別是面對(duì)不熟悉的新業(yè)務(wù)時(shí)。這用UML的用例（UseCase）方法就可實(shí)現(xiàn)，用例圖描述了用戶(hù)要做的事，在明確要做的事后，我們就可梳理出要實(shí)現(xiàn)的功能。如果對(duì)“用例”陌生，但“用戶(hù)故事”你應(yīng)該聽(tīng)說(shuō)過(guò)。用戶(hù)故事就是用例的實(shí)踐，用例可表達(dá)用戶(hù)故事之間的聯(lián)系，兩者的區(qū)別是，用例圖需要畫(huà)圖，圖形更有層次和結(jié)構(gòu)。用例圖的具體畫(huà)法可以閱讀《火球：uml大戰(zhàn)需求分析》最簡(jiǎn)化理解用例：誰(shuí)在用什么系統(tǒng)做什么事情，用圖形方式就是如上圖的用例圖，進(jìn)一步標(biāo)準(zhǔn)化表達(dá)就是：人員（角色）+系統(tǒng)+動(dòng)作+事件/事情，如下圖：通過(guò)用例分析，我們能夠梳理清楚這個(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)容、安全性?？捎眯孕枨螅║sability）：包括用戶(hù)體驗(yàn)（web產(chǎn)品的瀏覽器適配，各類(lèi)手機(jī)適配要求）、幫助和培訓(xùn)文檔等。可靠性需求（Reliability）：包括故障率、維修時(shí)間等。性能需求（Performance）：包括響應(yīng)時(shí)間、并發(fā)數(shù)、吞吐量等。可支持性需求（Supportability）：包括可維護(hù)性需求、可移植性需求等。其他次要需求（+）：包括數(shù)據(jù)分析需求、許可需求、接口需求、包裝需求等(在一些階段前期并不需要立即開(kāi)發(fā)數(shù)據(jù)分析功能，對(duì)外開(kāi)放等，這個(gè)根據(jù)階段和需求來(lái)看)。以上除第一項(xiàng)的功能外，其它的都是非功能需求，這些也是需要考慮的?？梢砸?guī)定一些項(xiàng)目和指標(biāo)，比如性能指標(biāo)：頁(yè)面響應(yīng)時(shí)間不能超過(guò)500ms，響應(yīng)時(shí)間太長(zhǎng)，用戶(hù)會(huì)以為出bug注冊(cè)用戶(hù)并發(fā)數(shù)量在某個(gè)階段為300/s訂單提交，支付等并發(fā)為100/s有些需要研發(fā)來(lái)處理，比如說(shuō)防止攻擊的安全性。這個(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)用類(lèi)圖進(jìn)行梳理。1.業(yè)務(wù)流程（完成）流程圖的作用是梳理業(yè)務(wù)，包括業(yè)務(wù)的主流程、分支流程和異常流程等。很多時(shí)候我們?cè)谑崂砹鞒虝r(shí)候，會(huì)因?yàn)椴块T(mén)、具體運(yùn)營(yíng)人員等原因，將流程拆分成很多塊，流程變成了以人為中心而不是以業(yè)務(wù)為中心，這是很容易犯的錯(cuò)誤。工作，業(yè)務(wù)才是核心，崗位和人是可以隨著工作和業(yè)務(wù)而調(diào)整的。但實(shí)際工作中，會(huì)因?yàn)閸徫灰彩怯扇藖?lái)做，有人就有私心，很容易形成一種因人而設(shè)崗，而改變業(yè)務(wù)的，這就會(huì)導(dǎo)致業(yè)務(wù)流程等變形。進(jìn)一步考慮，部門(mén)、崗位、人員是基于業(yè)務(wù)而設(shè)置的，這些不能反過(guò)來(lái)制約業(yè)務(wù)。解決這個(gè)問(wèn)題的辦法就是要采用端到端的流程設(shè)計(jì)，可以理解為圍繞某一業(yè)務(wù)主題下相關(guān)流程的有序銜接，或者說(shuō)是圍繞某一業(yè)務(wù)主題下的整體流程解決方案，而非局部流程，這里包含了跨專(zhuān)業(yè)、跨部門(mén)的協(xié)同，從需求提出到需求滿(mǎn)足，是某個(gè)業(yè)務(wù)的全程閉環(huán)。比如，排隊(duì)業(yè)務(wù)目的是最終讓用戶(hù)結(jié)束排隊(duì)，可以入座點(diǎn)餐。簡(jiǎn)要流程是：當(dāng)用戶(hù)來(lái)到餐廳，服務(wù)員詢(xún)問(wèn)顧客是否有預(yù)訂，如果有預(yù)定，時(shí)間也對(duì)，那么直接引導(dǎo)到預(yù)定位置如果沒(méi)有預(yù)定，有合適的空位，那么也是直接引導(dǎo)入座如果沒(méi)有預(yù)定，而且沒(méi)有空位，那么服務(wù)員輸入就餐人數(shù)等，打印排隊(duì)小票給到用戶(hù)，當(dāng)餐廳有空位之后，此信息傳給服務(wù)員，服務(wù)員呼叫就餐顧客如果用戶(hù)依然在，則核銷(xiāo)排隊(duì)小票，被引導(dǎo)到餐廳如果用戶(hù)中途走了，那么空位將會(huì)指派給后面的順延號(hào)顧客如果不考慮端到端流程，那中間就可能要斷幾次，比如收拾餐桌的人員沒(méi)有辦法通知迎賓服務(wù)員，那餐桌空了也不知道，這就是沒(méi)有跨越不同部門(mén)來(lái)協(xié)作；流程又有業(yè)務(wù)類(lèi)流程，支撐類(lèi)流程，職能類(lèi)流程；從顆粒度上分，又可以分為主流程，分支流程，操作流程（也可以分為一二三四級(jí)流程，意思就是下層是上層的細(xì)化）在繪制流程圖的時(shí)候，需要控制好顆粒度，比如主流程不需要很細(xì)，將最主要的部分畫(huà)出來(lái)就可以，比如ipd流程，就是一個(gè)流程框架。我們?cè)偻?，就需要進(jìn)一步細(xì)化，比如發(fā)布的整個(gè)過(guò)程：確定發(fā)布產(chǎn)品>準(zhǔn)備發(fā)布會(huì)>發(fā)布會(huì)>跟蹤發(fā)布效果>會(huì)后總結(jié)復(fù)盤(pán)會(huì)后總結(jié)復(fù)盤(pán)我們可以進(jìn)一步細(xì)化：制定復(fù)盤(pán)計(jì)劃》準(zhǔn)備復(fù)盤(pán)資料》復(fù)盤(pán)會(huì)議》復(fù)盤(pán)措施落實(shí)》資料歸檔。這樣，我們通過(guò)一層一層的細(xì)分、拆解，我們能夠?qū)⒋蟮牧鞒滩鸺?xì)，到可以直接指導(dǎo)最終的操作人的地步（在產(chǎn)品中，就是研發(fā)人員能夠據(jù)此進(jìn)行研發(fā)的地步）。如下方是一個(gè)配送的總流程圖，整個(gè)配送過(guò)程總的為：用戶(hù)下單，配送員接單，接單之后前往用戶(hù)處取貨，然后進(jìn)行配送，最終交接。用戶(hù)下單之后，配送員就直接接單嗎，不是，中間還應(yīng)該有分配機(jī)制，用戶(hù)怎么去取貨，中間要不要給取件碼驗(yàn)證，去了就一定有貨嗎，中間要不要等商家出餐呢，我們進(jìn)一步拆分。如果我們將參與的角色和流程進(jìn)展的階段做區(qū)分，那么我們可以得到一個(gè)泳道圖（也是流程圖的一種），如果角色不是很多，流程也不復(fù)雜，可以不用畫(huà)泳道圖。比如配送員需要認(rèn)證之后才能正式配送員進(jìn)行接單，其認(rèn)證流程如下：所有的流程不是一成不變的，而是會(huì)隨著業(yè)務(wù)變化而變化，但產(chǎn)品搭建的好的流程，需要：端到端業(yè)務(wù)視角而不是職能視角不重復(fù)，不遺漏邏輯清晰詳細(xì)的流程搭建方法，可以找相關(guān)數(shù)看，推薦一本《跟我們學(xué)建流程體系》-作者陳立云，羅均麗對(duì)于有多角色參與，并且互相之間有很多交互，實(shí)時(shí)性要求較高的，我們可以使用時(shí)序圖來(lái)進(jìn)行分析，比如以下是微信app交易過(guò)程的時(shí)序圖，看完整可以點(diǎn)擊下方鏈接。/wiki/doc/apiv3/open/pay/chapter2_5_2.shtml最頂部的是角色，垂直線(xiàn)是生命線(xiàn)，也即是時(shí)間線(xiàn)，從左側(cè)最頂部，依次完成動(dòng)作，箭頭的指向就是動(dòng)作的落腳點(diǎn)，箭頭指向自己，則表示是自己做了這個(gè)事情。虛線(xiàn)箭頭為反饋的信息，指向落腳點(diǎn)為反饋的對(duì)象。時(shí)序圖的畫(huà)法參考《火球：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)圖（StateDiagram），狀態(tài)圖描述了事務(wù)的狀態(tài)，以及觸發(fā)狀態(tài)變遷的操作。狀態(tài)圖的作用狀態(tài)圖和流程圖的樣子很類(lèi)似，但兩者的作用是不同的。兩者的區(qū)別是：流程圖梳理的是一項(xiàng)業(yè)務(wù)的大致過(guò)程，狀態(tài)圖梳理的是一項(xiàng)業(yè)務(wù)的細(xì)致操作。通過(guò)狀態(tài)圖，我們就可梳理清楚流程，以及流程中的異常情況。思考過(guò)程是先粗后細(xì)、先主干再分支、逐步完善的。1）繪制主干的狀態(tài)在梳理主干的狀態(tài)時(shí)，先要考慮主干的狀態(tài)，并忽略一些次要的分支狀態(tài)。我們還是以配送系統(tǒng)為例子：用戶(hù)提交訂單，訂單進(jìn)入待支付狀態(tài)；用戶(hù)支付后，訂單為已支付狀態(tài)；系統(tǒng)派單之后，訂單為待取貨狀態(tài)；配送員取貨之后，訂單狀態(tài)為配送中；貨物移交給收件人之后，訂單為已完成，如下圖：2）進(jìn)行狀態(tài)的拆合思考每種狀態(tài)是否要拆分或合并，通常應(yīng)多考慮是否要拆分。我們考慮上面的配送，是否有可以進(jìn)行拆分的狀態(tài)呢。比如其中已支付的訂單是否需要立即配送呢，不一定。一般來(lái)說(shuō)，發(fā)貨人可以選擇立即配送，也可以選定某個(gè)時(shí)間進(jìn)行派送。這個(gè)時(shí)候已支付的訂單待派單就會(huì)有：a、未到派單時(shí)間的訂單（待派）；b、已到派單正在指派的（派單中）；或者商品的上架與銷(xiāo)售，一些團(tuán)購(gòu)及整點(diǎn)秒殺的商品只是顯示在前臺(tái)，也就是處于“已上架”狀態(tài)，但未到售賣(mài)時(shí)間，是不能進(jìn)行銷(xiāo)售的，也就是處于“已上架，待銷(xiāo)售”狀態(tài)。只有到了售賣(mài)時(shí)間，該商品才會(huì)變?yōu)椤颁N(xiāo)售中”狀態(tài)。狀態(tài)的拆分和合并，需要根據(jù)具體業(yè)務(wù)，具體場(chǎng)景進(jìn)行區(qū)別對(duì)待。3）完善分支的狀態(tài)考慮分支狀態(tài)，或者異常狀態(tài)。在主流程中，我們基本考慮主狀態(tài)，但是肯定有分支和異常，比如待支付訂單如果超時(shí)沒(méi)有支付，那訂單就會(huì)取消，訂單狀態(tài)就是已取消狀態(tài)。4）完善角色和操作在梳理完所有狀態(tài)后，我們就要思考狀態(tài)之間如何轉(zhuǎn)移。此時(shí)要從角色和操作兩方面思考，簡(jiǎn)單說(shuō)就是梳理清楚誰(shuí)做了什么操作導(dǎo)致了狀態(tài)的變化。比如配送系統(tǒng)中，存在發(fā)貨人、商家、配送員、收貨人、平臺(tái)運(yùn)營(yíng)。在這整個(gè)過(guò)程中，一部分是由發(fā)貨人來(lái)觸發(fā)的，比如提交訂單；一部分是由配送員導(dǎo)致的，比如配送人員出意外，導(dǎo)致訂單需要改派。那就需要將相關(guān)的觸發(fā)人及導(dǎo)致的狀態(tài)進(jìn)行說(shuō)明，這樣使得整個(gè)狀態(tài)機(jī)更加的完善。3.信息結(jié)構(gòu)一個(gè)業(yè)務(wù)越復(fù)雜越需要，業(yè)務(wù)越陌生越需要梳理信息架構(gòu)，梳理信息架構(gòu)可以使用類(lèi)圖。用了類(lèi)圖后，產(chǎn)品經(jīng)理就能厘清信息之間的結(jié)構(gòu)關(guān)系。類(lèi)（Class）是對(duì)一組具有相同屬性、操作和關(guān)系的對(duì)象的描述，簡(jiǎn)單說(shuō)就是分類(lèi)。一個(gè)類(lèi)圖包含類(lèi)名稱(chēng)、屬性項(xiàng)、數(shù)量關(guān)系、關(guān)聯(lián)關(guān)系、聚合關(guān)系和組成關(guān)系。聚合關(guān)系描述了一個(gè)較大的事務(wù)（整體）是由較小的事務(wù)（部分）組成的，組成關(guān)系是聚合關(guān)系的一種特殊形式。我們還是按照從總到分邏輯來(lái)處理：步驟一：梳理出所有的類(lèi)步驟二：梳理出數(shù)量關(guān)系步驟三：明確信息的屬性步驟四：考慮效率和靈活性我們以訂單為例：我們先梳理所有的分類(lèi)，一筆訂單有用戶(hù)、支付、訂單、物流、發(fā)票等。一個(gè)用戶(hù)可能有訂單，也可能沒(méi)有訂單，所以用戶(hù)與訂單的關(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ù)商家，倉(cāng)庫(kù)，商品類(lèi)別等進(jìn)行分單，對(duì)應(yīng)關(guān)系為1對(duì)n；訂單需要進(jìn)行配送，則有物流，實(shí)際上一筆訂單的物流也可能有多個(gè)；訂單如果不需要開(kāi)發(fā)票，那么就沒(méi)有發(fā)票；如果用戶(hù)需要開(kāi)發(fā)票，則對(duì)應(yīng)關(guān)系為（1對(duì)1）；當(dāng)我們進(jìn)一步拆分，在類(lèi)下面加屬性項(xiàng)，屬性項(xiàng)是