只需5步,你也可以畫出高質(zhì)量的狀態(tài)流轉(zhuǎn)圖
一份PPT可以認(rèn)為是一個產(chǎn)品,一個PRD文檔也可以認(rèn)為是一個產(chǎn)品,乃至于一張流程圖、一封郵件都可以被當(dāng)做是一個產(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)品錄入上架的后臺,供海外留學(xué)生、空姐等(供應(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)梳理一下,大致如下圖:
乍一看還挺清晰的,但仔細(xì)一看,就不難發(fā)現(xiàn)其中的問題。
一、流轉(zhuǎn)圖的問題
有什么問題,思考1分鐘……
問題一、狀態(tài)缺失
“已下架”狀態(tài)缺失,這個問題比較容易發(fā)現(xiàn),但即便你發(fā)現(xiàn)了這個狀態(tài)缺失估計(jì)也愛莫能助,因?yàn)檫@個流程中壓根不涉及,所以這個狀態(tài)即便考慮到了也放不進(jìn)這個流程圖!怎么解決?按照這個思路,可能的方案就是到下架流程中進(jìn)行補(bǔ)充。
雖然這個方法可以解決狀態(tài)標(biāo)注的問題,但這并非一個最優(yōu)的方法,因?yàn)榻鉀Q問題的同時也導(dǎo)致了狀態(tài)流轉(zhuǎn)被分割到了不同的流程當(dāng)中,不能在一個流程圖當(dāng)中清晰地呈現(xiàn)各狀態(tài)之間的流轉(zhuǎn)關(guān)系,開發(fā)GG、測試MM無法方便地進(jìn)行查閱,需求文檔閱讀成本增加。(閱讀成本增加帶來的后果是你與開發(fā)gg、測試MM的溝通成本增加,說到底最終麻煩的還是你自己)
問題二、狀態(tài)信息不準(zhǔn)確
這個問題不仔細(xì)推敲不太容易發(fā)現(xiàn)。比如“商家錄入產(chǎn)品信息”這個環(huán)節(jié)的狀態(tài)被標(biāo)記為“制作中”、“從未上架”,那么設(shè)想一下,如果一個產(chǎn)品在上架之后,由于種種原因,信息需要發(fā)生變更,這個時候可能需要重新審核之后才能生效,在商家變更產(chǎn)品信息的過程中,產(chǎn)品的上架狀態(tài)應(yīng)該是什么狀態(tài)呢?顯然,無論如何它的上架狀態(tài)都不會是“從未上架”。如果說上一個問題帶來的后果只是溝通成本增加的話,那么這一個問題帶來的后果恐怕就是讓自己成為一名“實(shí)力挖坑”的選手了。
問題三、擴(kuò)展性不強(qiáng)
這個問題前期基本沒有,一般到了中后期產(chǎn)品迭代的時候才會逐步暴露出來。為了說明這個問題,火山又YY一個場景,掃寶網(wǎng)的商家在運(yùn)營一年以后發(fā)現(xiàn)后臺充斥著大量的廢棄商品分散它們的注意力,提高了他們的篩選成本,希望增加一個刪除功能,這個時候需要增加一種刪除狀態(tài),這個狀態(tài)該如何流轉(zhuǎn)?什么狀態(tài)下能刪,什么狀態(tài)下不能刪?未來還有可能再增加完整狀態(tài)、有效狀態(tài)、可售狀態(tài)呢?還能理得清狀態(tài)是如何流轉(zhuǎn)的嗎?是不是想想都有點(diǎn)頭大……
那么,有沒有更好的辦法可以幫我們更加清晰地描述狀態(tài)之間的流轉(zhuǎn)關(guān)系呢?
二、“五步”繪制法
有!火山今天就給大家分享一個狀態(tài)流轉(zhuǎn)圖的“五步”繪制法,希望能對大家有所啟發(fā)。
第一步:拆分狀態(tài)維度
由于此流程主要涉及審核、上架兩個維度的狀態(tài),因此,我們先繪制兩個維度的空白表格
火山點(diǎn)評:當(dāng)業(yè)務(wù)流程比較復(fù)雜,涉及多個維度的狀態(tài)時,這一步非常非常關(guān)鍵。因?yàn)闊o論一個流程多復(fù)雜,被拆分到多個維度之后,單看每一個維度都會變得簡單很多。
第二步:繪制第一個維度的狀態(tài)圖
流程的起點(diǎn)從上架錄入產(chǎn)品開始,先有錄入、提審,才有了上架,因此,先從審核狀態(tài)開始繪制。繪制時可以采用先窮舉這個維度的所有狀態(tài),再通過流線標(biāo)注兩兩狀態(tài)之間的流轉(zhuǎn)關(guān)系的方式來繪制,效果如下圖所示:
火山點(diǎn)評:狀態(tài)流轉(zhuǎn)圖重點(diǎn)關(guān)注的是狀態(tài)之間的關(guān)系,因此主體是狀態(tài)名稱,流線上是操作說明,無需描述詳細(xì)的處理校驗(yàn)邏輯。
第三步:繪制其他維度的產(chǎn)品狀態(tài)圖
按照第一個維度狀態(tài)相同的方法,即先窮舉狀態(tài)、再標(biāo)注狀態(tài)流轉(zhuǎn)關(guān)系,繪制第二個維度的狀態(tài)流轉(zhuǎn)圖,如下圖所示:
第四步:不同維度的狀態(tài)關(guān)聯(lián)
兩個維度的狀態(tài)繪制完畢之后,結(jié)合實(shí)際流程,跨維度標(biāo)記兩個維度之間狀態(tài)相互之間的流轉(zhuǎn)關(guān)系,大致結(jié)果如下圖所示:
火山點(diǎn)評:至此,一個完整的產(chǎn)品上架狀態(tài)流轉(zhuǎn)圖就基本上可以說繪制完畢了。
讓我們再來測試一下它的擴(kuò)展性?;鹕皆賮鞾Y一個場景:
由于業(yè)務(wù)需要,掃寶網(wǎng)需要增加一個刪除功能,制作中、審核駁回的產(chǎn)品允許用戶刪除。與此同時,由于產(chǎn)品信息錄入的頁面比較多,錄入產(chǎn)品過程中可能被打斷,再次進(jìn)入時,需繼續(xù)填寫完整產(chǎn)品信息,因此還需要增加一個完整性狀態(tài),同時沒有錄入完整的產(chǎn)品不允許提交審核;
需求分析:
首先,一般情況下狀態(tài)維度不宜太多,可將刪除產(chǎn)品可以作為審核維度的一個狀態(tài)值“已刪除”,大致流轉(zhuǎn)圖如下:
其次,無論是完整狀態(tài)還是不完整的狀態(tài),實(shí)際上都可以處于制作中的狀態(tài),但由于之前已經(jīng)存在“制作中”的狀態(tài),這個時候如果拆分制作中的狀態(tài),歷史數(shù)據(jù)處理會比較麻煩,因此,我們把完整性作為一個維度來繪制,最終大致如下圖所示:
至此,擴(kuò)展了3個狀態(tài)的狀態(tài)流轉(zhuǎn)圖在增加了一個狀態(tài)值,擴(kuò)展了一個維度之后,也繪制完畢了,我們在一張圖中清晰而又完整地表述了各個狀態(tài)之間的流轉(zhuǎn)關(guān)系,而且擴(kuò)展性也還行,是不是感覺很不錯^_^
然而火山認(rèn)為這還不夠,為什么?因?yàn)樗目勺x性還不夠好!
你有沒有發(fā)現(xiàn),僅僅只有三個維度的狀態(tài)流轉(zhuǎn)圖似乎依然顯得有點(diǎn)凌亂,如果不是跟著火山的思路往下走,直接將最后一張完整的狀態(tài)圖丟給你,你是不是不知道該從何著眼。而如果以后再要擴(kuò)展更多的維度,勢必就更加“混亂”了。雖然這種混亂是由于產(chǎn)品本身的復(fù)雜性導(dǎo)致的,但這對于一名追求完美的產(chǎn)品經(jīng)理來說同樣是不能忍受的,如果恰好你也不能忍受,你或許還可以繼續(xù)進(jìn)行下(jia)一(fen)步(xiang)。
第五步:主線速描,增強(qiáng)狀態(tài)流轉(zhuǎn)圖的可讀性
以主流程“錄入-提交審核-審核通過-上架-下架”為參照,對主流程上的各個節(jié)點(diǎn)狀態(tài)及流線進(jìn)行著色,如下圖所示:
火山點(diǎn)評:完成著色后的狀態(tài)流轉(zhuǎn)圖,主線和支線之間的界限涇渭分明,整個狀態(tài)流轉(zhuǎn)圖立馬清晰了很多,讀者很容易就會順著主線的引導(dǎo)理清整個流程中的狀態(tài)流轉(zhuǎn)過程,可謂是點(diǎn)睛之筆。
三、總結(jié)
在一個互聯(lián)網(wǎng)團(tuán)隊(duì)當(dāng)中,產(chǎn)品經(jīng)理無疑是最應(yīng)該具備“產(chǎn)品思維”的一個角色;而產(chǎn)品思維絕不僅僅只能用在我們所設(shè)計(jì)的一個功能板塊、一個網(wǎng)站系統(tǒng)這些產(chǎn)品經(jīng)理的本職工作上,也應(yīng)該被用在我們?nèi)粘9ぷ鞯姆椒矫婷?。一份PPT可以認(rèn)為是一個產(chǎn)品,一個PRD文檔也可以認(rèn)為是一個產(chǎn)品,乃至于一張流程圖、一封郵件都可以被當(dāng)做是一個產(chǎn)品。
既然是產(chǎn)品,就要講求“用戶至上,體驗(yàn)為王”。如果把一張狀態(tài)流轉(zhuǎn)圖看做是一個產(chǎn)品,開發(fā)GG、測試MM就是它的用戶,從這個角度來說,第五步這微小的一步或許才是提升“狀態(tài)流轉(zhuǎn)圖”這一個“產(chǎn)品”提升“用戶體驗(yàn)“的關(guān)鍵之舉。
作為產(chǎn)品經(jīng)理,如果我們交付的每一份需求文檔都能用以產(chǎn)品思維來要求,或許程序猿與產(chǎn)品汪之間的“愛”與“情”會更多一點(diǎn),“仇” 與 “恨”會更少一點(diǎn),(互聯(lián)網(wǎng))世界將會變成更美好的人間……
特別說明:本案例及案例中所有場景需求純屬虛構(gòu),如有雷同,純屬巧合。
#專欄作家#
PM火山,微信公眾號:PM火山,人人都是產(chǎn)品經(jīng)理專欄作家。后臺型產(chǎn)品從0到1負(fù)責(zé)人??恐鴮W(xué)習(xí)、實(shí)踐、總結(jié),再學(xué)習(xí)、再實(shí)踐、再總結(jié)來讓自己不斷成長的產(chǎn)品人。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash ,基于 CC0 協(xié)議
第一張圖還看的挺明白的,后面的圖看著好復(fù)雜,毫無頭緒,可能不太適合我吧。。。。
用狀態(tài)圖來描述,更清晰
很清晰,支持 ??
1、在上架狀態(tài)中;審核完成上架成功這個狀態(tài)轉(zhuǎn)換條件與審核狀態(tài)的狀態(tài)圖關(guān)聯(lián)在一起;原則上是沒有這條線的,這個是審核狀態(tài)的狀態(tài)改變,只有從審核狀態(tài)-審核成功后系統(tǒng)上架這個條件;
2、還有個疑問是產(chǎn)品創(chuàng)建成功的初始狀態(tài),這里是否有些不明確,此時還沒有進(jìn)行制作;如何直接變成創(chuàng)建成功的狀態(tài);感覺將用戶制作的狀態(tài)與與審核狀態(tài)混淆了一部分~
審核狀態(tài):待審核、審核通過、審核駁回應(yīng)該是此3個
用戶制作狀態(tài):創(chuàng)建商品;編輯商品
感謝你的分享,有很多啟發(fā)~
產(chǎn)品小白,最近在做任務(wù)發(fā)布審批流。感謝分享,學(xué)到了拆分狀態(tài)維度。這個圖把狀態(tài)流轉(zhuǎn)表達(dá)的比較清晰。 ?
疑問:業(yè)務(wù)流程圖怎么和狀態(tài)流轉(zhuǎn)圖完美結(jié)合。
1、完整性是 制作過程的細(xì)分,“不完整”、“完整”應(yīng)該是“制作中”這個主狀態(tài)的 2個子狀態(tài)
2、主狀態(tài)和子狀態(tài)2個層級的起始狀態(tài)可以標(biāo)注出來。 同一層級,應(yīng)該有1個初態(tài)和 1到n個終態(tài)
這個是要把自己搞死啊,干嘛不直接畫個流程圖。。。。
大兄弟,這個圖越搞越復(fù)雜啊,第一張圖一看就懂,吃瓜群眾要看半天。。。教程不錯,這樣的流程怎么搞得可視化一些??!
有幾個問題不是很明白:
1.這樣的圖,怎么看狀態(tài)的起點(diǎn)和結(jié)束點(diǎn)?還是說沒有起始?
2.各個維度的狀態(tài)應(yīng)該在同一時間會同時存在吧?那其實(shí)對程序而言是一個狀態(tài)吧?還是各個維度不會疊加存在呢,是相斥的?
3.根據(jù)我的了解,狀態(tài)區(qū)分越多,代碼復(fù)雜度呈數(shù)量級增長,那么應(yīng)該怎么將狀態(tài)控制在合理的水平,避免不必要的狀態(tài)存在呢?
?? 不知道您怎么看?
非常好的問題!試著談?wù)勎业膫€人觀點(diǎn),僅供參考
1、大部分情況,狀態(tài)流轉(zhuǎn)是有起點(diǎn)和結(jié)束點(diǎn)的,主線的始末可作為狀態(tài)的起點(diǎn)和結(jié)束點(diǎn);
2、各個維度的狀態(tài)是同時存在的,但每一個維度只能同時存在一種狀態(tài)。
3、狀態(tài)的標(biāo)記說道底是為了業(yè)務(wù)場景服務(wù)的,在能夠滿足用戶必要的業(yè)務(wù)場景的情況下,的確應(yīng)該越少越好。具體怎么控制,就沒有標(biāo)準(zhǔn)答案了,我通常的做法是,如果某些業(yè)務(wù)場景如果可以通過不同維度的狀態(tài)組合實(shí)現(xiàn),那么這個狀態(tài)值就可以省略掉。
能提出這些問題,說明你是一個勤于思考的產(chǎn)品人,而且對技術(shù)實(shí)現(xiàn)由比較深的理解,給你點(diǎn)贊
謝謝您的鼓勵 ??
我剛?cè)肼氹娚绦袠I(yè)兩個月,您的文章給我很大啟發(fā),尤其是分維度拆解狀態(tài)。
我還是覺得業(yè)務(wù)流程轉(zhuǎn)換圖,標(biāo)明每一個業(yè)務(wù)轉(zhuǎn)換的狀態(tài)在哪個發(fā)生點(diǎn)就好了,我個人是看這個圖,感覺挺累。 ??
每個人都有可以有一套適合自己的方法,只要能清楚描述你的需求,什么圖都o(jì)k的
個人覺得這個圖做的很棒啊,不知大家說的泳道圖做出來是什么效果?
我也想知道 ??
用泳道圖來表示各系統(tǒng)模塊之間的狀態(tài)流轉(zhuǎn)可能更清晰
個人還是傾向用泳道流程圖來表達(dá)。。。看著太吃力了
有機(jī)會分享分享,愿聞其詳
這個圖看起來好累的感覺,但是節(jié)點(diǎn)邏輯多了還真不知道怎么闡述好,還是要靠圖
看起來累是因?yàn)闃I(yè)務(wù)本身比較復(fù)雜,這還只有3個維度,電商系統(tǒng)里面出現(xiàn)五六個維度的狀態(tài)是非常正常的
我也覺得這個圖片看起來很累啊。