中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

• 范圍層對應搭產品的框架（功能框架、非功能框架）
• 結構層對應做細節（業務流程、業務操作、信息結構）

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

1. 功能框架

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

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

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

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

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

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

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

2. 非功能框架

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

可以把功能性需求和非功能性需求匯總，匯總后的模型為“PURPS+模型”?！癙URPS+模型”是指主要需求（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. 步驟一：梳理出所有的類
2. 步驟二：梳理出數量關系
3. 步驟三：明確信息的屬性
4. 步驟四：考慮效率和靈活性

我們以訂單為例：

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

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

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

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

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

訂單如果不需要開發票，那么就沒有發票；如果用戶需要開發票，則對應關系為（1對1）；

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

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

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

下一篇將介紹怎么進行交互設計和原型繪制。