起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何繪畫狀態機來描述業務的變化
對于設計過商品、訂單、優惠券等復雜功能的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個思考，可以一起討論下：
- 京東小程序的首頁，有個領券功能，試問它的狀態機有幾個，分別怎么畫，是否有其他設計問題。
- 電商領域中優惠券功能模塊有幾個業務實體，分別畫出狀態機圖。
#專欄作家#
作者：浪子，人人都是產品經理專欄作家，業務型產品經理，3年社交+4年電商的工作經驗，個人公眾號：langzisay。
本文由 @浪子 原創發布于人人都是產品經理。未經許可，禁止轉載。
為啥sku全退是到了已完成狀態？
贊！看完這么多文章就你的文章最詳細易懂，感謝分享！另外能不能解答一下最后兩個思考呢
贊一個！遇到多、復雜狀態的時候確實應該用狀態機來描述邏輯，比文字強太多！
sku是否全退是啥意思
舉例：買了兩部手機，退了其中一部。
準確來說，應該是買了一部iPhone8一部iPhoneX，退了其中一部。（這2者是不同的SKU商品）
為什么款項沒有全退的情況下，后面還有sku是否全退的判斷，我理解沒有全額退款，必然只退了部分sku，所以狀態必然轉變為待發貨或待收貨。請解答一下～
同問
有兩個子狀態機不太理解，按照流程不是應該先買家申請退貨，然后確定退回sku個數，然后賣家確定后才能收到退款嗎
UML里面不是有個叫狀態圖的嗎？怎么弄出個狀態機的概念了
是一個東西，只是畫法有點區別。
感覺狀態機圖也能畫出狀態和流程的結合體了，那還有流程圖的必要嗎？
狀態機和一般的流程圖區別還是很大的，結合起來會搞得很混亂。根本沒辦法把狀態和流程講得清楚。
好棒！簡單易懂！想請問一下作者，關于狀態機有沒有可以推薦的書籍或專欄？
建議搜狀態機的文章看，書籍里面重點講解狀態機的只有uml書籍，比如火球大戰uml分析，軟件方法上之類的。
axure的flow里沒有開始結束狀態的圓圈 ??
自制，so easy。
狀態機，不錯的機
好吧，當年都用rose畫狀態圖，中間用visio，現在用axure簡單畫
從工具的角度來看，越來越不專業了。
好奇什么原因？
效率一個比一個高。
嗯，算是一個原因。
UML里面有種叫時序圖，可以表達出事件影響狀態的變化
嗯啊，感覺比活動圖更適合表現具體的業務流程。
不過當下敏捷橫行，基本上都不畫比較規范的時序圖了。
好
最近也了解了狀態機的問題，諸位也可以去看看層次狀態機
求個層次狀態機在消費領域APP的實際場景。
狀態泳道加動作節點
狀態機沒有泳道的概念啊，完全是不同的分析角度和對象
小白問個問題，求輕噴。。把你這個狀態機加上各個狀態不是就變成泳道圖了？這個和業務流程圖有什么區別？隨著業務的流動，狀態也有相應的改變，怎么去區分呢？
1、狀態機圖描述的是狀態的變化。泳道圖一般描述的是功能的具體步驟，一個是status，一個是action，本質不一樣。
2、這個是偏功能層面的，和業務流程圖是2個維度的。你可以看下我最新的文章。
泳道圖方框里是“動作”，狀態機連線上是“動作”
挺好