對于設計過商品、訂單、優惠券等復雜功能的PM來說，會發現很難描述清楚功能的本質。因為技術會反復的問，有幾種狀態啊，怎么轉移啊，啥時候轉移啊，什么時候截止狀態啊，系統根據什么條件判斷狀態啊……

一、為什么需要使用狀態機？

講個親身的例子，去年我設計電商系統的訂單模塊，就犯過類似的問題。

• 一開始參照淘寶的訂單系統，將訂單設計為待付款、已付款、已發貨、已完成，已關閉等5個狀態。
• 上線后很快就發現有問題。付款之后直接傳給倉庫那邊發貨，導致很多訂單信息明明有誤，但是來不及修改。用戶下單
• 之后想改地址改商品，而發貨信息已經傳給網倉了很難修改。
• 然后我們不得不新增了一個中間狀態“已確認”，讓客服審核無誤后，再傳給網倉走發貨流程。
• 再后來我們發現除了主業務-下單購物之外，還需要兼顧支線業務-退款退貨，此時不得不需要引入“退款中”狀態并且增加退款子狀態機、退貨子狀態機。

以上這些我最開始是用文字描述，然后加上憑感覺畫的流程圖來表示，服務端RD很難理解，并且無法清楚所有狀態以及轉移條件，不得不多次反復確認。

后來去搜索相關的資料，好好研究了一下狀態機這個概念，才發現其實用一張圖就可以表述清楚以上的一切。

接下來，我就來講講我對狀態機的理解和認識，希望對大家有點幫助。

二、狀態機的來源？

最早是電路設計領域里面的概念，具體來說是一種根據電路信號按照預先設定的狀態進行轉移，協調相關信號動作并完成特定操作的控制硬件。

后來軟件編程里面繼承了這種思想，用來表示有限多個狀態以及在這些狀態之間轉移和動作的模型。簡稱為FSM(Finite State Machine)，是常見的軟件設計模式之一。

對于PM來說，借鑒這種思想并融入到自己的產品思維中是很有必要的。據此設計業務實體的功能會更容易闡述本質，并且讓技術更容易理解。

三、狀態機是什么？

從PM的角度可以這樣定義，狀態機用來表示業務實體的全部狀態以及相互間如何轉移。

其中，業務實體是指客觀上可以相互區分的事物，比如訂單、優惠券、商品、活動……

當然扯遠一點，大部分對象都是有狀態的概念，只是沒必要都畫個狀態機圖。

3.1 狀態機的描述方法

文字是最古老的方式，繁瑣并且不容易理解。
另外表格也可以描述，不夠形象，理解較慢。
我認為圖形最佳，僅需一些節點表示狀態然后用有向線條連接。

3.2 常見的狀態機

舉一些例子讓大家對狀態機圖有個基本的認知。

（1）燈泡狀態機

小時候第一堂物理課講解的電燈開關其實就是最簡單的狀態機。

（2）訂單狀態機

這個網購過的朋友應該都接觸過，借鑒自淘寶。

3.3 狀態機的要素

從狀態機的內在因果關系可以抽象出3大要素：

• 現態：是指當前所處的狀態。
• 條件：系統按照某一規則或者用戶執行某個動作后，，狀態會進行遷移。
• 次態：條件滿足后遷移到的新狀態。

包含1個開始狀態和N個終止狀態，以及若干個中間狀態。當到達終態， 狀態機停止。

注意：有些工程師會把條件和動作分成2種要素，感覺不是特別恰當。因為動作本身就是條件的一種。

四、怎么畫狀態機？

我習慣使用Axure，以它來講解怎么表示，其他工具方法類似。

4.1 要素怎么表示

“狀態”使用圓角矩形表示。

“條件”使用有向線條上的文字表示，比如系統怎么樣，或者用戶執行xx動作。

線條的方向表示狀態遷移。

一般情況下從左向右的畫圖順序表示了初始→終止的方向，所以無需單獨表示。復雜情況下可以用實心黑圓點初始狀態，用實心黑圓點外包一個圓圈表示終止狀態。

4.2 要素如何命名

狀態建議以”已+動詞”的結構來命名，比如已付款、已發貨。

條件建議以”動作+結果”的動賓結構或者”表達式”來命名，以明確狀態遷移的具體條件。比如支付失敗、下單時間>72小時。

注意命名一般站在用戶立場，盡量命名標準化。

4.3 畫出狀態機

• 理解業務實體有多少種狀態
• 考慮每一個狀態因為什么條件而變化
• 將狀態和狀態之間用條件有向連接
• 形成狀態機圖
• 和服務端RD討論并確定

4.4 畫圖注意點

不需要的狀態盡量去除，讓狀態機結構最簡單。

明確只有一個初始狀態，終止狀態可能有多個。

合理實現各個狀態之間的切換。

方便擴展，狀態有可能會增加，有可能會有子狀態機。

注意不要遺漏狀態，比如優惠券使用的狀態機可能需要“使用中”

不要搞混動作和狀態的區別，命名本身就不一樣。而本質上動作是不穩定的，一旦執行完畢就結束了；而狀態是穩定的，只要沒有外部條件觸發。

4.5 延展一下多維狀態機

剛剛這2個例子是最簡單的狀態結構。只有一級，只有一維。

比如退款退貨是訂單的逆向流程，形成了多個維度的狀態機。

?4.6 狀態機圖和流程圖的區別

經常有人把狀態機圖給錯認為是流程圖的一種，其實他們本質不一樣。

目的不一樣，流程圖表示的是流程，狀態機圖表示的是業務實體的狀態變化。

另外，流程圖中的節點一般是動作，而狀態機圖的節點是狀態。

準確來說，狀態機圖是UML語言中的一種。

五、總結

不是所有的業務實體都有必要產出狀態機圖，關鍵的建議產出。

最后留2個思考，可以一起討論下：

1. 京東小程序的首頁，有個領券功能，試問它的狀態機有幾個，分別怎么畫，是否有其他設計問題。
2. 電商領域中優惠券功能模塊有幾個業務實體，分別畫出狀態機圖。

#專欄作家#

作者：浪子，人人都是產品經理專欄作家，業務型產品經理，3年社交+4年電商的工作經驗，個人公眾號：langzisay。

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