做一款產品前，我們事先要做的就是明確需求與對應場景。對一款企業系統來說，關注點也是如此。
繼上一篇業務流程識別與分析篇後，本文主要分享業務場景識別與分析相關知識點。
一、識別業務場景
首先是要理解用例和用戶故事的本質，它要求我們不是去關注系統提供什麼功能，而是用戶在什麼場景下需要系統提供支持！
1. 用例的關鍵知識認知
- 用例名稱要基於用戶場景去設定，使用業務語言去描述，而不是機械式的使用“增刪改查”
- 在業務場景中的用例粒度是由組織分工決定的，特徵是獨立、可彙報、可暫停的單元（一般不會是太細化的動作）
- 2人/周的工作量分拆成更小的故事，另外大故事要保留的原因是方便組織小故事，不忘初心。
2. 基於流程圖識別參與系統的角色。
- 對這個流程提供支撐需要有哪些角色？
- 非必需的角色納入系統支持中有什麼價值？不納入的話有什麼影響？（在優先級排序時有指導作用）
- 一般執行層的角色會用崗位名稱命名
- 在權限系統中要如何抽象各個角色
3. 基於流程圖識別業務場景
我們要思考在流程過程中，哪些業務活動要系統支持，哪些是部分支持，審批點是否屬於系統內，判斷點是否為獨立環節。
（下圖是一套體檢系統的流程圖，假如工程排期優先內部作業電子化，故體檢者一欄暫時不納入電子系統。紅圈則是現要開發的系統所支持的任務活動）
4. 補充業務場景
常見如由時間、狀態而觸發的業務場景，如信用卡到期還款以及長期逾期狀態導致信用卡凍結的場景。
5. 繪製用例圖
注意常見三個關係_包含、擴展、泛化。
- 包含關係——公共子事件流（不需給用戶看），如檢查座位信息。
- 擴展關係——不一定執行的擴展事件流（需給用戶看），如處理等候隊列。
- 泛化關係——公共事件流，如辦理結賬。
二、六步分析業務場景
1. 概述業務場景（包括業務目的、前後置條件等）
2. 把場景細化成事件流，整理去用戶預期的步驟，並思考擴展和異常事件流。
注意兩點：
- 用例描述重在人機交互和意圖，不需要過多些人機界面和動作
- 結構化語言描述，少用“如果..就”的表達方式了；擴展或備選事件流單獨列出來分支，降低理解成本。
3. 針對每一個步驟，思考並羅列用戶可能遇到的問題
4. 針對問題思考解決方案
5. 考慮環境與業務特點帶來的影響或要求，主要是性能、易用性、部署環境等三方面
6. 開始初步的交互設計
本文由 @PM達雲霄 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
分享到:
閱讀更多 人人都是產品經理 的文章
