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

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

相對而言，狀態(tài)流轉(zhuǎn)圖用得并不像業(yè)務(wù)流程圖那么多，所有很多產(chǎn)品經(jīng)理對這個類型的需求文檔不太熟悉。為了更好地給大家分享這個類型的需求文檔，火山Y(jié)Y了一個名為“掃寶網(wǎng)”的C2C海外代購電商平臺，并以它的產(chǎn)品上架流程為例予以說明：

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

根據(jù)以上場景及需求，大致繪制出如下業(yè)務(wù)流程圖：

經(jīng)過分析，此流程至少涉及到兩個維度的7種產(chǎn)品狀態(tài)，即：

• 審核維度：制作中（正在編輯產(chǎn)品）、待審核、審核通過、審核駁回
• 上架狀態(tài)：從未上架、已上架、已下架

那么，這些狀態(tài)是怎么流轉(zhuǎn)的呢？我們先試著用流程圖把狀態(tài)梳理一下，大致如下圖：

乍一看還挺清晰的，但仔細一看，就不難發(fā)現(xiàn)其中的問題。

一、流轉(zhuǎn)圖的問題

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

問題一、狀態(tài)缺失

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

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

問題二、狀態(tài)信息不準確

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

問題三、擴展性不強

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

那么，有沒有更好的辦法可以幫我們更加清晰地描述狀態(tài)之間的流轉(zhuǎn)關(guān)系呢？

二、“五步”繪制法

有！火山今天就給大家分享一個狀態(tài)流轉(zhuǎn)圖的“五步”繪制法，希望能對大家有所啟發(fā)。

第一步：拆分狀態(tài)維度

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

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

第二步：繪制第一個維度的狀態(tài)圖

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

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

第三步：繪制其他維度的產(chǎn)品狀態(tài)圖

按照第一個維度狀態(tài)相同的方法，即先窮舉狀態(tài)、再標注狀態(tài)流轉(zhuǎn)關(guān)系，繪制第二個維度的狀態(tài)流轉(zhuǎn)圖，如下圖所示：

第四步：不同維度的狀態(tài)關(guān)聯(lián)

兩個維度的狀態(tài)繪制完畢之后，結(jié)合實際流程，跨維度標記兩個維度之間狀態(tài)相互之間的流轉(zhuǎn)關(guān)系，大致結(jié)果如下圖所示：

火山點評：至此，一個完整的產(chǎn)品上架狀態(tài)流轉(zhuǎn)圖就基本上可以說繪制完畢了。

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

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

需求分析：

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

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

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

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

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

第五步：主線速描，增強狀態(tài)流轉(zhuǎn)圖的可讀性

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

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

三、總結(jié)

在一個互聯(lián)網(wǎng)團隊當中，產(chǎn)品經(jīng)理無疑是最應(yīng)該具備“產(chǎn)品思維”的一個角色；而產(chǎn)品思維絕不僅僅只能用在我們所設(shè)計的一個功能板塊、一個網(wǎng)站系統(tǒng)這些產(chǎn)品經(jīng)理的本職工作上，也應(yīng)該被用在我們?nèi)粘９ぷ鞯姆椒矫婷妗Ｒ环軵PT可以認為是一個產(chǎn)品，一個PRD文檔也可以認為是一個產(chǎn)品，乃至于一張流程圖、一封郵件都可以被當做是一個產(chǎn)品。

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

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

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

#專欄作家#

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

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議