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

一、為什么需要使用狀態(tài)機？

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

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

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

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

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

二、狀態(tài)機的來源？

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

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

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

三、狀態(tài)機是什么？

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

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

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

3.1 狀態(tài)機的描述方法

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

3.2 常見的狀態(tài)機

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

（1）燈泡狀態(tài)機

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

（2）訂單狀態(tài)機

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

3.3 狀態(tài)機的要素

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

• 現(xiàn)態(tài)：是指當前所處的狀態(tài)。
• 條件：系統(tǒng)按照某一規(guī)則或者用戶執(zhí)行某個動作后，，狀態(tài)會進行遷移。
• 次態(tài)：條件滿足后遷移到的新狀態(tài)。

包含1個開始狀態(tài)和N個終止狀態(tài)，以及若干個中間狀態(tài)。當?shù)竭_終態(tài)， 狀態(tài)機停止。

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

四、怎么畫狀態(tài)機？

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

4.1 要素怎么表示

“狀態(tài)”使用圓角矩形表示。

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

線條的方向表示狀態(tài)遷移。

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

4.2 要素如何命名

狀態(tài)建議以”已+動詞”的結構來命名，比如已付款、已發(fā)貨。

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

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

4.3 畫出狀態(tài)機

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

4.4 畫圖注意點

不需要的狀態(tài)盡量去除，讓狀態(tài)機結構最簡單。

明確只有一個初始狀態(tài)，終止狀態(tài)可能有多個。

合理實現(xiàn)各個狀態(tài)之間的切換。

方便擴展，狀態(tài)有可能會增加，有可能會有子狀態(tài)機。

注意不要遺漏狀態(tài)，比如優(yōu)惠券使用的狀態(tài)機可能需要“使用中”

不要搞混動作和狀態(tài)的區(qū)別，命名本身就不一樣。而本質上動作是不穩(wěn)定的，一旦執(zhí)行完畢就結束了；而狀態(tài)是穩(wěn)定的，只要沒有外部條件觸發(fā)。

4.5 延展一下多維狀態(tài)機

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

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

?4.6 狀態(tài)機圖和流程圖的區(qū)別

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

目的不一樣，流程圖表示的是流程，狀態(tài)機圖表示的是業(yè)務實體的狀態(tài)變化。

另外，流程圖中的節(jié)點一般是動作，而狀態(tài)機圖的節(jié)點是狀態(tài)。

準確來說，狀態(tài)機圖是UML語言中的一種。

五、總結

不是所有的業(yè)務實體都有必要產出狀態(tài)機圖，關鍵的建議產出。

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

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

#專欄作家#

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

本文由 @浪子 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。