編輯導語：初級產品經理在接到需求時，當我們無法把比較抽象的概念用文字表達出來時，可以轉化為圖表描述出來。借此，作者講解了產品經理常用的幾大圖表類型以及圖表的使用場景，分享給你。

背景：

初級產品經理在接到需求時，不能夠將抽象的概念，用文字表達出來，而是需要用一些計算機的行話（大家都理解的術語或者圖表），將抽象的概念，通過圖形、圖表描述出來。下面，將會講解產品經理常用的圖表類型，以及圖表的使用場景。

一、ER 圖

ER（Entity Relationship）圖是一種描述實體對象（Entity） 之間關聯關系（relationship）的經典圖表，由科學家Peter chen 于1976年發明，最早被用于關系型數據庫。

ER 圖是產品經理在工作中，經常會打交道的一種圖表，ER 圖的呈現方式有很多種，比較常用的是使用UML 中的類圖（class diagram）所規定的符號標記規范來進行描述和呈現。

下面的所有例子，都是通過Process On 這個工具來進行操作的。

一個ER 圖中，每一個大方框代表一個對象，方框中的第一行描述的是對象的名稱，第二行描述的是對象中的數據字段，大方框和大方框之間的連線，表示實體之間的關系，如果新手產品經理，不了解什么是“關系”，可以看看之前這篇文檔 http://www.woshipm.com/origin/pmd/5176906.html

多對一關系ER 圖示例：

兩個ER圖使用實線鏈接，實線標注N ：1，表示著多對1 對關系，即 多個學生對應著一個教室。

如下圖所示，則為一對一關系ER圖，表示著一個公民，必定對應著一張身份證，一張身份證，也對應著一個公民。

一對一關系ER 圖

1. 使用場景

我們在產品設計初期，我們就要想好這些實體類型之間的關系，如果你現在做的產品，經常出現邏輯混亂，功能重復的問題，以后分解需求以后，可以先從分析ER 圖開始。除此之外，產品經理在輸出PRD文檔時，如果使用文字，以及圖表，不能夠很好的體現需求中的實體關系，這時候，我們就可以考慮使用ER 圖來進行表示。

通常產品經理，只要掌握一對一關系，一對多關系，多對多關系，那么就可以解決我們在工作中遇到的絕大多數實體問題了。

2. 流程圖

國際標準組織ISO（International Standard Organization）在1970年定義了流程圖的基本符號規則，方便不同背景的讀者閱讀理解，建議盡量采用簡單的繪圖規則，例如，只使用開始，結束，執行，判斷這四種符號來繪制流程圖。

（1）流程圖的符號要求

流程圖看起來很容易畫，但是想要畫好、畫標準一張流程圖，還是需要一些練習的，下面這張圖介紹了畫流程圖的一些特定符號，我們一定要記清楚每個符號的含義，在畫流程圖的時候可不要弄錯了。

下面是幾個重要且最常用的符號，需要牢記！

（2）流程圖的三大結構

流程圖由三大結構構成，這三大結構分別為順序結構、選擇結構和循環結構，這三個結構構成了流程執行的全過程。

① 順序結構

在順序結構中，各個步驟是按先后順序執行的，這是一種最簡單的基本結構。如圖，A、B、C是三個連續的步驟，它們是按順序執行的，即完成上一個框中指定的操作才能再執行下一個動作。

② 選擇結構

選擇結構又稱分支結構，選擇結構用于判斷給定的條件，根據判斷的結果判斷某些條件，根據判斷的結果來控制程序的流程，判斷的流程可以有

③ 循環結構

循環結構又稱為重復結構，就是流程在一定的條件下，反復執行某一操作的流程結構。循環結構下又可以分為當型結構（when）和直到型結構（while）。

當型結構：該結構可以理解為，判斷所給條件p是否成立，當P成立，則執行A（步驟）；再判斷條件p是否成立；當P成立，則又執行A，若此反復，當條件p不成立時，則跳出循環。

直到型結構：先執行流程A，再判斷所給條件P是否成立，若p不成立，則再執行A，如此反復，直到P成立，該循環過程結束。

流程圖是產品經理必須掌握的一種圖表，當產品經理拿到一個涉及跨模塊，跨部門，跨角色協作的需求時，使用流程圖來描述業務的過程，以及用戶的操作過程，比做高保真的原型要簡單清晰。如下圖所示，就可以很清晰的描述每個角色，在流程中，應該要做什么事。

3. 狀態機圖（State Machine Diagram）

在面對業務流程時，初級的產品會使用文字去描述狀態之間的流轉，如我一個訂單的開始狀態，到訂單的確定狀態，再到訂單的結束狀態，這種描述是非常難明白的，我們需要通過狀態機圖，給你的小伙伴們介紹各種狀態。狀態機圖也叫有限狀態機圖（Finite State Machine Diagram），是一種描述所有狀態以及狀態之間流轉規則的圖形。

源狀態 (Source State)：受轉換影響的狀態;如果對象處于源狀態，則當對象接收到轉換的觸發事件并且滿足保護條件（如果有）時，可以觸發傳出轉換。

目標狀態 (Target State)：過渡完成后處于活動狀態。

在軟件設計領域，“狀態”在業務系統中，無處不在：訂單要有狀態，賬號要有狀態，門店要有狀態，可以說任何對象都有狀態。狀態機要注意以下幾點：

1. 狀態值是有限的集合，狀態的所有枚舉值，必須涵蓋所有實際可能的情況
2. 狀態值之間要互斥，不能出現二義性
3. 為了更準確的描寫狀態，狀態還能有子狀態，如訂單的“已取消”，可以對應為的子狀態為“客戶取消”，“商家取消”，“系統取消”
4. 狀態應該是能持續一定時長的，而不是很快就會結束的瞬時態，如訂單的狀態可以是“待發貨”，“待評價”，但不能是“發貨中” – 可以是等待xxx 發貨，“評價中” — 可以是等待xxxx 評價。

二、使用場景

當產品經理接收到的需求中，一個實例，可以承載多種操作，以及存在多個狀態時，那么這個prd 文檔，就必須包括狀態機圖，否則這個prd 文檔是很難描述清楚實體之間的狀態關系的。

下圖的狀態機圖，則是描述了一個訂單的復核，待執行，中間態，以及完結態時的狀態流轉。使用狀態機圖比用文字，要簡單明了。

三、用例圖

是用戶與系統交互的最簡單表示形式，展現了用戶和與他之間相關的用例之間的關系，通過用例圖，人們可以獲取系統不同種類的用戶和用例，簡單說就是某個角色或者用戶在不同場景下，可以做什么，實際工作中，我們會用到簡單的用例圖，復雜的用例圖，比較少接觸到。

盡管用例本身會涉及大量細節和各種可能性，用例圖卻能提綱挈領地讓人了解系統概況。它為“系統做什么”提供了簡化了的圖形表示，因此被譽為“搭建系統的藍圖”。

由于其簡單純粹的本質，用例圖是項目參與者間交流的好工具。用例圖的畫法是對現實世界的一種刻畫，可以讓項目參與者明白系統要做成什么樣。

1. 用例（Use Case）——用例就是外部可見的系統功能，對系統提供的服務進行描述。用橢圓表示。

2. 子系統（Subsystem）——用來展示系統的一部分功能，這部分功能聯系緊密。

用例圖涉及的關系，如關聯，泛化，包含，拓展等，在這里就不一一展開，有需要的小伙伴，可以去百度對應的資料。

使用場景：

產品經理使用用例圖的場景一般是有兩種。

第一種是描述用戶的行為，通常，我們會使用用例圖，描述這個用戶在模塊上可以做的操作。

第二種是搭配ER 圖，描述實體的操作時，我們也會用用例圖，去描述實體可以支持的操作。

用戶操作用例圖

學生實體用例圖

本文由 @danny要做好產品 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自pexels，基于CC0協議