一份PPT可以認為是一個產品，一個PRD文檔也可以認為是一個產品，乃至于一張流程圖、一封郵件都可以被當做是一個產品。

狀態流轉圖是一種用于描述狀態之間流轉過程的需求文檔，在電商類產品的訂單流、審批流一類的需求中比較常見。

相對而言，狀態流轉圖用得并不像業務流程圖那么多，所有很多產品經理對這個類型的需求文檔不太熟悉。為了更好地給大家分享這個類型的需求文檔，火山YY了一個名為“掃寶網”的C2C海外代購電商平臺，并以它的產品上架流程為例予以說明：

• 業務背景：為了降低平臺的產品上架成本，平臺為供應端開放了一個產品錄入上架的后臺，供海外留學生、空姐等（供應端）人員上架產品;
• 業務需求：為了把控產品質量，產品需要平臺審核通過之后才能上架銷售。

根據以上場景及需求，大致繪制出如下業務流程圖：

經過分析，此流程至少涉及到兩個維度的7種產品狀態，即：

• 審核維度：制作中（正在編輯產品）、待審核、審核通過、審核駁回
• 上架狀態：從未上架、已上架、已下架

那么，這些狀態是怎么流轉的呢？我們先試著用流程圖把狀態梳理一下，大致如下圖：

乍一看還挺清晰的，但仔細一看，就不難發現其中的問題。

一、流轉圖的問題

有什么問題，思考1分鐘……

問題一、狀態缺失

“已下架”狀態缺失，這個問題比較容易發現，但即便你發現了這個狀態缺失估計也愛莫能助，因為這個流程中壓根不涉及，所以這個狀態即便考慮到了也放不進這個流程圖！怎么解決？按照這個思路，可能的方案就是到下架流程中進行補充。

雖然這個方法可以解決狀態標注的問題，但這并非一個最優的方法，因為解決問題的同時也導致了狀態流轉被分割到了不同的流程當中，不能在一個流程圖當中清晰地呈現各狀態之間的流轉關系，開發GG、測試MM無法方便地進行查閱，需求文檔閱讀成本增加。（閱讀成本增加帶來的后果是你與開發gg、測試MM的溝通成本增加，說到底最終麻煩的還是你自己）

問題二、狀態信息不準確

這個問題不仔細推敲不太容易發現。比如“商家錄入產品信息”這個環節的狀態被標記為“制作中”、“從未上架”，那么設想一下，如果一個產品在上架之后，由于種種原因，信息需要發生變更，這個時候可能需要重新審核之后才能生效，在商家變更產品信息的過程中，產品的上架狀態應該是什么狀態呢？顯然，無論如何它的上架狀態都不會是“從未上架”。如果說上一個問題帶來的后果只是溝通成本增加的話，那么這一個問題帶來的后果恐怕就是讓自己成為一名“實力挖坑”的選手了。

問題三、擴展性不強

這個問題前期基本沒有，一般到了中后期產品迭代的時候才會逐步暴露出來。為了說明這個問題，火山又YY一個場景，掃寶網的商家在運營一年以后發現后臺充斥著大量的廢棄商品分散它們的注意力，提高了他們的篩選成本，希望增加一個刪除功能，這個時候需要增加一種刪除狀態，這個狀態該如何流轉？什么狀態下能刪，什么狀態下不能刪？未來還有可能再增加完整狀態、有效狀態、可售狀態呢？還能理得清狀態是如何流轉的嗎？是不是想想都有點頭大……

那么，有沒有更好的辦法可以幫我們更加清晰地描述狀態之間的流轉關系呢？

二、“五步”繪制法

有！火山今天就給大家分享一個狀態流轉圖的“五步”繪制法，希望能對大家有所啟發。

第一步：拆分狀態維度

由于此流程主要涉及審核、上架兩個維度的狀態，因此，我們先繪制兩個維度的空白表格

火山點評：當業務流程比較復雜，涉及多個維度的狀態時，這一步非常非常關鍵。因為無論一個流程多復雜，被拆分到多個維度之后，單看每一個維度都會變得簡單很多。

第二步：繪制第一個維度的狀態圖

流程的起點從上架錄入產品開始，先有錄入、提審，才有了上架，因此，先從審核狀態開始繪制。繪制時可以采用先窮舉這個維度的所有狀態，再通過流線標注兩兩狀態之間的流轉關系的方式來繪制，效果如下圖所示：

火山點評：狀態流轉圖重點關注的是狀態之間的關系，因此主體是狀態名稱，流線上是操作說明，無需描述詳細的處理校驗邏輯。

第三步：繪制其他維度的產品狀態圖

按照第一個維度狀態相同的方法，即先窮舉狀態、再標注狀態流轉關系，繪制第二個維度的狀態流轉圖，如下圖所示：

第四步：不同維度的狀態關聯

兩個維度的狀態繪制完畢之后，結合實際流程，跨維度標記兩個維度之間狀態相互之間的流轉關系，大致結果如下圖所示：

火山點評：至此，一個完整的產品上架狀態流轉圖就基本上可以說繪制完畢了。

讓我們再來測試一下它的擴展性?；鹕皆賮鞾Y一個場景：

由于業務需要，掃寶網需要增加一個刪除功能，制作中、審核駁回的產品允許用戶刪除。與此同時，由于產品信息錄入的頁面比較多，錄入產品過程中可能被打斷，再次進入時，需繼續填寫完整產品信息，因此還需要增加一個完整性狀態，同時沒有錄入完整的產品不允許提交審核；

需求分析：

首先，一般情況下狀態維度不宜太多，可將刪除產品可以作為審核維度的一個狀態值“已刪除”，大致流轉圖如下：

其次，無論是完整狀態還是不完整的狀態，實際上都可以處于制作中的狀態，但由于之前已經存在“制作中”的狀態，這個時候如果拆分制作中的狀態，歷史數據處理會比較麻煩，因此，我們把完整性作為一個維度來繪制，最終大致如下圖所示：

至此，擴展了3個狀態的狀態流轉圖在增加了一個狀態值，擴展了一個維度之后，也繪制完畢了，我們在一張圖中清晰而又完整地表述了各個狀態之間的流轉關系，而且擴展性也還行，是不是感覺很不錯^_^

然而火山認為這還不夠，為什么？因為它的可讀性還不夠好！

你有沒有發現，僅僅只有三個維度的狀態流轉圖似乎依然顯得有點凌亂，如果不是跟著火山的思路往下走，直接將最后一張完整的狀態圖丟給你，你是不是不知道該從何著眼。而如果以后再要擴展更多的維度，勢必就更加“混亂”了。雖然這種混亂是由于產品本身的復雜性導致的，但這對于一名追求完美的產品經理來說同樣是不能忍受的，如果恰好你也不能忍受，你或許還可以繼續進行下（jia）一（fen）步（xiang）。

第五步：主線速描，增強狀態流轉圖的可讀性

以主流程“錄入-提交審核-審核通過-上架-下架”為參照，對主流程上的各個節點狀態及流線進行著色，如下圖所示：

火山點評：完成著色后的狀態流轉圖，主線和支線之間的界限涇渭分明，整個狀態流轉圖立馬清晰了很多，讀者很容易就會順著主線的引導理清整個流程中的狀態流轉過程，可謂是點睛之筆。

三、總結

在一個互聯網團隊當中，產品經理無疑是最應該具備“產品思維”的一個角色；而產品思維絕不僅僅只能用在我們所設計的一個功能板塊、一個網站系統這些產品經理的本職工作上，也應該被用在我們日常工作的方方面面。一份PPT可以認為是一個產品，一個PRD文檔也可以認為是一個產品，乃至于一張流程圖、一封郵件都可以被當做是一個產品。

既然是產品，就要講求“用戶至上，體驗為王”。如果把一張狀態流轉圖看做是一個產品，開發GG、測試MM就是它的用戶，從這個角度來說，第五步這微小的一步或許才是提升“狀態流轉圖”這一個“產品”提升“用戶體驗“的關鍵之舉。

作為產品經理，如果我們交付的每一份需求文檔都能用以產品思維來要求，或許程序猿與產品汪之間的“愛”與“情”會更多一點，“仇” 與 “恨”會更少一點，（互聯網）世界將會變成更美好的人間……

特別說明：本案例及案例中所有場景需求純屬虛構，如有雷同，純屬巧合。

#專欄作家#

PM火山，微信公眾號：PM火山，人人都是產品經理專欄作家。后臺型產品從0到1負責人?？恐鴮W習、實踐、總結，再學習、再實踐、再總結來讓自己不斷成長的產品人。

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

題圖來自 Unsplash ，基于 CC0 協議