善用三個方法,拒絕靠「想」做需求分析
需求分析不是僅靠“想”就能完成的,還需要依據嚴謹而科學的分析方法。
網上有很多需求分析的文章,通常它們的需求分析步驟是使用馬洛斯需求模型,然后分析用戶和場景,最后分析用戶期望。這樣就完成了需求分析,然后開始做原型PRD。
可是具體怎么分析呢?怎么將用戶需求轉化可見的原型?相信大家讀完也是一知半解。在整個過程中,完全靠產品經理頭腦風暴?
我認為這只能算「需求挖掘」。需求分析應該是嚴謹而科學的,不僅僅是靠「想」。當然,可能這是C端產品業務較為簡單的原因。不同于C端需求,B端需求都來至于垂直行業,高度貼合客戶業務。所以,B端需求分析,需要有一套結合業務的分析方法。本文主要分享我的B端需求分析方法。
從宏觀,我將需求按其生命周期分為用戶需求、功能需求和產品需求。用戶需求是原生的需求描述,可能僅僅是一句話。比如:“我需要一個客人點餐的功能”。功能需求是我們所要實現產品的具體功能。產品需求則會落實到具體功能如何實現。
從產出上分析,我需求分析個階段的產出依次分為功能列表、需求功能對照表、功能清單/信息架構。
開始分析之前,我首先會先整理需求。將需求池中需求的來源、優先級標注清楚。B端產品的需求通常來源于客戶、老板、競品和對業務的深度建模分析。優先級,筆者主要劃分為高、中、低。
我的需求分析方法,主要分為三步場景分析、角色分析、業務分析。整個分析過程高度依賴UML。下文以餐館點餐系統舉例分析。
一、場景分析
場景分析目的是為角色分析和業務分析打下基礎。主要通過與客戶溝通,了解清楚用戶的需求背景和業務背景,對需求有個明確的理解。除了通過客戶溝通外,也可以使用其他的調研或分析方法。如果,機會合適的話,最好深度參與一下用戶的業務。我在做商家服務產品時,為了客戶的打單發貨業務,就曾親身參與過用戶的打單發貨。
場景分析過程中,需要整理出場景故事、用戶溝通記錄等。
以簡化版餐館門店點餐系統為例。假定整理出的場景故事:客戶的顧客,到達餐廳后,入座。通過點餐軟件,選擇菜品。后廚,廚師長獲得用戶菜單后,安排廚師制作菜品。菜品制作完成,通過服務員為用戶上菜。用戶用餐完畢后,通過軟件付款,并可以評價。
二、角色分析
角色分析的目的是整理出需求中包含的角色,以及明確角色所包含的屬性。角色可能是設計出的功能的使用者,也可能是系統的示例數據。在角色分析時,我通常使用ER圖來描述角色。該ER圖中只表示角色,不用表示其他實例和關聯關系。
根據場景故事,我們可以整理出角色:顧客、老板、廚師長、廚師、服務員。這里只是舉例說明,只完成核心,所以就只考慮顧客、廚師長(1名)、服務員三種角色。在分析角色的屬性時,可以預先考慮將來的擴展。比如服務員將來可以可能會涉及多種分工的服務員,所以可以設計一個類型屬性。下面我制作的ER圖。
完成角色的分析后,下一步進行業務分析。
三、業務分析
業務分析的目的是,分析用戶需求背后的業務流程,理清楚相關的數據結構和操作,為用戶需求制定合適的解決方案,并把用戶需求轉化為實際的建模描述(用UML表示),為功能清單/信息架構制作打下基礎。
第一步,分析出角色和系統的關聯關系。顧客使用點餐系統完成點餐。廚師長通過點餐系統獲得用戶的菜單,安排制作后,通過上菜系統傳遞給服務員。服務員通過上菜系統,給顧客上菜。顧客用餐完畢后,通過結賬系統結賬,并評價。這里使用用例圖來進行分析。這里只進行簡單總結,就不細化到系統功能。
完成系統的分析后,用戶需求就被轉化為了功能需求。我們分析出了需要哪些系統,系統包含哪些功能。下一步是完成系統間的交互分析,明確每個角色行為,在業務內進行的運作。這里采用序列圖來進行分析,以點餐到菜品上桌為例。
明確系統的執行順序后,就可以通過流程圖完成描繪出整個業務了。如果是一個流程有多個角色參與,可以使用跨職能的流程圖。這里就以普通流程圖為例,分析點餐的業務流程。
完成流程圖后,就接近分析完成整個需求和業務。但是針對某些一些特殊內容,我們還需要更為深入的分析。比如某些實例的狀態。以本文例子中,服務員的狀態進行分析。針對狀態分析,使用UML的狀態圖。
業務分析惋惜完成后,我們就完成了需求分析。我們需要產出直觀的文檔,除了上方分析的文檔外,還需要產出功能清單或者信息架構。這里以功能清單舉例:通過功能清單,就將功能需求轉化成產品需求。下方為一份簡單的功能清單。實際我們在制作功能清單時,一定要注重細節的把握,細節體現專業。
完成功能清單后,就完成了需求分析,就可以開始制作原型。原型制作這里就略過了。
四、總結
可能很多產品經理,不認可業務分析就是需求分析的一部分。在B端產品的需求分析中,需求和業務是高度耦合的,沒有深入業務層面的需求分析,都是不夠客觀的。當然,可能在大公司有專門的的業務分析師做業務分析,B端產品經理不一定需要深入分析業務。但對于B端產品經理來說,業務分析能力也是需求分析能力的一部分,不是任何時候都有業務分析師幫助產品經理分析業務。
做B端需求分析,我的原則是:盡可能通過UML的方式,將抽象的業務邏輯轉化為可見的數據結構和業務模型。
作者:產品小思考,B端產品經理
本文由 @產品小思考 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
挺好~
什么場景下、什么人,產生了需求(問題)
我的文章寫了10篇,可以一起努力呀。我是曉莊同學,微信號:znc0520,公眾號:小曉莊同學產品筆記 ??
作為一個b端產品,終于看到了一個實操過的人寫的東西,雖然很粗但是看得出來是從實踐中總結出來的東西,很贊,訂閱了!
他這個完全可以做一個案例來出來套教程,比那些只會分析理論需求的強太多
竟然才35訂閱,我感覺寫得很棒啊。
??
??
嗯
核心三點:解決什么問題,給誰使用,如何實現是最棒的。
解決什么問題,更深入的說:創造了什么價值
我也是b 多交流
可以 可以
很實用的方法論。贊!
不判斷一下有沒有菜???
簡單舉了例子,理一下我的方法。要深入下去,業務就很復雜了,不是一篇小文章能寫完的了。
所以有些人在做功能,有些人在做解決方案
贊同 ??
不了解業務考想的做出來的就是功能,這樣做出來的功能的復用性也不是特別高,更多的是一次性用品
了解業務+想做出來功能復用性會很高,承前啟后嘛,多個功能匯聚就成了解決方案 哈哈
并不僅僅于此,B端需求,如果不做業務分析,極大可能做出的功能,也是廢的,不能滿足客戶需求。
對啊 沒有說這個僅僅針對B端 哈哈