編輯導語：作為産品經理，應該都經曆過這樣的過程，從業務需求推導産品需求。那麼，我們該如何從業務需求推導出産品需求？作者梳理了相關流程，希望對你有所幫助。

注：産品設計屬于産品工作的中間環節，在它的前面還有規劃等工作，我們這裡說的産品設計的工作邊界是指從調研分析完，如何從0到1設計出産品功能，并能指導後續的開發工作。

今天這篇推文按理說應該屬于産品設計的第一篇，先講從業務需求如何推導出産品需求。

我們先放上産品設計過程的基本原則：

下面我們來看看具體的設計過程，你将看到如何運用這些設計原則。

老規矩，我們先從日常的例子說起。

企業辦公時，我們最常用的OA，ERP系統，用戶看到的一個個功能菜單及頁面，是怎麼來的？

淘寶購物時，我們看到的首頁、商品詳情頁、購物車頁又是怎麼來的？

上面我們舉的這2個例子，所用到系統都屬于信息系統這一類（根據徐鋒在《軟件需求最佳實踐》對2B系統的分類，除信息化信息，還有嵌入式系統等）。根據信息工程的定義，信息系統是人、數據、過程和接口的組合，以處理信息流為目的的人機一體化系統。這類系統也是大家最常接觸的系統。

這類系統有個特點，把我們生産、生活的流程、場景搬到系統上。仔細觀察，你會發現上面說的例子都離不開流程。所以，先梳理清楚線下的業務流程，是我們線上化的第一步。

完成需求調研與分析後的第一步就是找出業務主幹。一家企業的内部運轉是由公司戰略目标分解為每年的經營目标，由經營目标又拆解為每個部門的工作目标，而完成這些工作目标在每個部門内由不同的角色的人按既定的流程來實現。而有不少工作還常常是跨部門的協作。

注意：信息系統是服務于目标分解後的具體工作。但沉澱于系統中的數據，又反過來可以輔助目标的制定。

一般來說，大部分中小型企業都有自己的制度、流程。我們可以請需求單位先提供現行的業務流程。

為了便于理解，我放上兩張圖。

圖1 一個從線索到交付的業務流程圖

圖2 ERP系統的各模塊的數據流圖

業務流程描述的對象是某一具體業務，而系統數據描述的對象是業務背後的數據流。

這裡要特别提醒一點：業務流程是用于原本的線下實操，當它要放到線上，往往因為其中的部分活動無法線上化或者線上化時發現需要增加一些管控環節，所以常常需要對其進行一定的裁剪、優化。

從業務流程圖到系統流程圖，是一個從具體到抽象的過程。通過描述的對象的轉化，系統流程圖剝離掉具體業務，抽象出數據的流動、加工和存儲。

以圖1為例，從業務流程來看，分為經銷商/直接用戶、公海客戶，如以圖2的系統流程圖來表示，可以用客戶資料來統一表示。因為從數據的視角來看，經銷商、公海客戶都是客戶。

你可以會疑問，為什麼要這樣做？我們把業務流程圖直接1:1還原到系統上不香嗎？

接着說說這樣做的目的。

要講清楚目的，就需要先說說數據和信息的關系：數據是反映客觀事物屬性的記錄，是信息的具體表現形式。數據經過加工處理之後，才成為信息，如下圖：

信息系統是提取了具體業務背後有效的數據，加工成信息，并去掉了冗餘的數據。這樣的信息系統，數據才有利用的價值，系統效率也更高。

講完抽象，我們接下來再看看抽象之後，我們又要如何一步步還原、滿足原本的業務需求？

我們可以借助用例圖來展示用戶希望系統能幹什麼？

圖3 一個電商系統的用例圖

你如果認真觀察會發現上圖和圖1的業務流程圖有部分相似之處。

相似點：兩者都有參與者和活動。

差異點：業務流程圖主要描述的是一個業務從開始到結束的活動順序，而用例圖主要描述的是參與者要在系統做的某些事。

由此可以推測，管理層更關注業務流程圖，而執行層更關注用例圖。

不論是業務流程圖還是用例圖，它們的活動的粒度都是可以逐步分層的，可以先畫整體，再畫具體部分。

看到這裡，你可能會有疑問：業務流程圖和用例圖有什麼關系？

徐鋒在《有效需求分析》一書中，指出用例圖就是從業務流程圖推導出來。這個推導的過程是這樣的：業務流程圖如上面所說是線下一個個業務的完整活動流，在線上化的過程我們要識别哪些活動是系統可實現？然後再通過用例圖表示各種角色未來要在系統做什麼（系統需具備哪些功能）？

注意：用例圖在業務流程圖的活動的基礎上，增加了不同用例之間的關系，如下圖4：

不論是借書還是還書用例都包含了需要先驗證讀者身份這個用例，而超期罰款是還書可能發生的擴展用例。

通過用例之間的關系，進一步厘清了未來系統開發過程中的功能關聯性。這是原來的業務流程圖所沒有的。

前面說了業務流程，接下來我們要在業務流程的基礎上，繼續找出實體。

先解釋下什麼是實體？

實體是在實際問題中客觀存在的，并且可以相互區别的事物或者概念。可以具體到人、對象、概念、事件。我們這裡說的實體是在概念數據模型階段的高層描述（可以理解為在人的頭腦中的一個名詞概念，比如“員工”），可對應未來在物理數據模型階段（指數據庫設計）要存儲到數據庫的信息。

關于找出實體的方法，推薦可通過前面說的業務流程圖來找出實體，實體一般就在流程的每個活動的名詞上。比如“下單”這個活動，這裡的“訂單”就是我們說的實體。

這些實體就是未來系統建設要存儲的有用信息。

而要表達實體及其關系，我們可以通過ER圖，我從【人人都是産品經理】上找了到作者小狼人分享的ER圖：

圖5上是買家下單ER圖，下是其中買家這個實體的屬性。

通過這個ER圖，我們可以看到下單這個業務流程，涉及了買家、商品、交易訂單、子訂單（比如不同商家拆單）、支付信息這5個實體。圖中還表現出了這些實體間的聯系關系，比如一個買家可能有多張訂單。最後還看到了每個實體的屬性信息。

有了ER圖，就為後面的數據庫設計提供了設計依據。

從ER圖到數據庫設計，是一個從高層到低層的設計過程。

一開始我們對信息系統的定義提到信息系統是以處理信息流為目的的人機一體化系。我們接着看看參與者和系統的信息互動。

這裡我們會用到一個叫時序圖的工具。

圖6 學生在系統中查詢成績成績時，與系統發生的信息流

上圖能直觀地反應學生這個角色，在不同實體對象間的信息流轉（發送消息、接受消息、處理消息、返回消息）順序。

一般什麼時候要用到時序圖？

根據我的個人經驗，當兩套系統之間需要做接口對接時，通過時序圖來說明兩者之間的信息傳遞順序，是個不錯的方法。

圖7 用戶通過企業微信登錄第三方系統的時序圖

從上圖我們可以看出信息在各系統間的流轉，各套系統傳遞什麼信息，獲取什麼信息，可以一目了然。

前面的環節，都是為最後的系統原型設計做準備。如果沒有前面的分析環節，直接進入原型設計，我們大概率會做出一個臃腫、缺乏邏輯、沒有體系的系統。

到這裡我們再把上面做的分析工作串起來：

• 通過系統流程圖，我們可以劃分出這套系統應該由哪些大模塊組成？
• 通過用例圖，我們可以分析出系統應該具備哪些功能？這些功能間有什麼内在聯系？
• 通過ER圖，我們可以分析出系統的功能背後的數據實體，可指導未來數據庫要如何設計（功能頁面大概有哪些信息？）
• 通過時序圖，我們可以解決跨系統的接口開發存在的責任不清的問題。信息流在各個系統應如何流轉？

這個時候，我們再拿來做原型設計，就真的是手到擒來。咔咔咔，一頓操作猛如虎。一個個功能頁面就可以落地下來了。

圖8 一個電商網站的首頁原型圖

不知道，你有沒發現，從業務需求到産品需求的整個過程，我們都沒談到類、方法等與開發直接相關的名詞？

這是最後我想和産品經理同行們聊的，UML這套系統建模工具，本身是獨立于任何程序設計語言。

在《軟件工程》一書中，對UML有非常詳細的介紹，它不隻是一套工具，還是一種設計理念。

産品經理們可以使用UML完成概念層設計（理解為概要設計），設計人員可以通過UML完成說明層設計（對應詳細設計），開發人員可以通過UML完成實現層開發。

過程中，我不提倡産品經理們使用UML的類圖、對象圖等與設計、開發相關的工具圖表，一方面是如上面所說，大家做的是不同層面的工作；另一方面是你不懂工具的真正用途，隻懂其形不懂其神，還會誤導了你的下遊夥伴。

上面的這個理念同樣适用于最後的原型圖（圖中隻用了黑、白、灰三種顔色），一個産品經理沒有美工的基礎，卻要輸出所謂高保真原型，殊不知給下遊的美工帶來了諸多困擾（因為你想當然用了各種花花綠綠的配色，搞得人家美工都不知道如何下手去收拾你的殘局）。

祝你在專業的道路上，走到極緻。這已經是超過80%的人。不要亂玩所謂跨界，我們已經夠卷了，别瞎添亂。

作者：追夢人，公衆号：豆芽悟

本文由 @追夢人 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議