善用三個方法,拒絕靠「想」做需求分析

21 評論 16154 瀏覽 154 收藏 9 分鐘

需求分析不是僅靠“想”就能完成的,還需要依據嚴謹而科學的分析方法。

網上有很多需求分析的文章,通常它們的需求分析步驟是使用馬洛斯需求模型,然后分析用戶和場景,最后分析用戶期望。這樣就完成了需求分析,然后開始做原型PRD。

可是具體怎么分析呢?怎么將用戶需求轉化可見的原型?相信大家讀完也是一知半解。在整個過程中,完全靠產品經理頭腦風暴?

我認為這只能算「需求挖掘」。需求分析應該是嚴謹而科學的,不僅僅是靠「想」。當然,可能這是C端產品業務較為簡單的原因。不同于C端需求,B端需求都來至于垂直行業,高度貼合客戶業務。所以,B端需求分析,需要有一套結合業務的分析方法。本文主要分享我的B端需求分析方法。

從宏觀,我將需求按其生命周期分為用戶需求、功能需求和產品需求。用戶需求是原生的需求描述,可能僅僅是一句話。比如:“我需要一個客人點餐的功能”。功能需求是我們所要實現產品的具體功能。產品需求則會落實到具體功能如何實現。

從產出上分析,我需求分析個階段的產出依次分為功能列表、需求功能對照表、功能清單/信息架構。

開始分析之前,我首先會先整理需求。將需求池中需求的來源、優先級標注清楚。B端產品的需求通常來源于客戶、老板、競品和對業務的深度建模分析。優先級,筆者主要劃分為高、中、低。

我的需求分析方法,主要分為三步場景分析、角色分析、業務分析。整個分析過程高度依賴UML。下文以餐館點餐系統舉例分析。

一、場景分析

場景分析目的是為角色分析和業務分析打下基礎。主要通過與客戶溝通,了解清楚用戶的需求背景和業務背景,對需求有個明確的理解。除了通過客戶溝通外,也可以使用其他的調研或分析方法。如果,機會合適的話,最好深度參與一下用戶的業務。我在做商家服務產品時,為了客戶的打單發貨業務,就曾親身參與過用戶的打單發貨。

場景分析過程中,需要整理出場景故事、用戶溝通記錄等。

以簡化版餐館門店點餐系統為例。假定整理出的場景故事:客戶的顧客,到達餐廳后,入座。通過點餐軟件,選擇菜品。后廚,廚師長獲得用戶菜單后,安排廚師制作菜品。菜品制作完成,通過服務員為用戶上菜。用戶用餐完畢后,通過軟件付款,并可以評價。

二、角色分析

角色分析的目的是整理出需求中包含的角色,以及明確角色所包含的屬性。角色可能是設計出的功能的使用者,也可能是系統的示例數據。在角色分析時,我通常使用ER圖來描述角色。該ER圖中只表示角色,不用表示其他實例和關聯關系。

根據場景故事,我們可以整理出角色:顧客、老板、廚師長、廚師、服務員。這里只是舉例說明,只完成核心,所以就只考慮顧客、廚師長(1名)、服務員三種角色。在分析角色的屬性時,可以預先考慮將來的擴展。比如服務員將來可以可能會涉及多種分工的服務員,所以可以設計一個類型屬性。下面我制作的ER圖。

完成角色的分析后,下一步進行業務分析。

三、業務分析

業務分析的目的是,分析用戶需求背后的業務流程,理清楚相關的數據結構和操作,為用戶需求制定合適的解決方案,并把用戶需求轉化為實際的建模描述(用UML表示),為功能清單/信息架構制作打下基礎。

第一步,分析出角色和系統的關聯關系。顧客使用點餐系統完成點餐。廚師長通過點餐系統獲得用戶的菜單,安排制作后,通過上菜系統傳遞給服務員。服務員通過上菜系統,給顧客上菜。顧客用餐完畢后,通過結賬系統結賬,并評價。這里使用用例圖來進行分析。這里只進行簡單總結,就不細化到系統功能。

完成系統的分析后,用戶需求就被轉化為了功能需求。我們分析出了需要哪些系統,系統包含哪些功能。下一步是完成系統間的交互分析,明確每個角色行為,在業務內進行的運作。這里采用序列圖來進行分析,以點餐到菜品上桌為例。

明確系統的執行順序后,就可以通過流程圖完成描繪出整個業務了。如果是一個流程有多個角色參與,可以使用跨職能的流程圖。這里就以普通流程圖為例,分析點餐的業務流程。

完成流程圖后,就接近分析完成整個需求和業務。但是針對某些一些特殊內容,我們還需要更為深入的分析。比如某些實例的狀態。以本文例子中,服務員的狀態進行分析。針對狀態分析,使用UML的狀態圖。

業務分析惋惜完成后,我們就完成了需求分析。我們需要產出直觀的文檔,除了上方分析的文檔外,還需要產出功能清單或者信息架構。這里以功能清單舉例:通過功能清單,就將功能需求轉化成產品需求。下方為一份簡單的功能清單。實際我們在制作功能清單時,一定要注重細節的把握,細節體現專業。

完成功能清單后,就完成了需求分析,就可以開始制作原型。原型制作這里就略過了。

四、總結

可能很多產品經理,不認可業務分析就是需求分析的一部分。在B端產品的需求分析中,需求和業務是高度耦合的,沒有深入業務層面的需求分析,都是不夠客觀的。當然,可能在大公司有專門的的業務分析師做業務分析,B端產品經理不一定需要深入分析業務。但對于B端產品經理來說,業務分析能力也是需求分析能力的一部分,不是任何時候都有業務分析師幫助產品經理分析業務。

做B端需求分析,我的原則是:盡可能通過UML的方式,將抽象的業務邏輯轉化為可見的數據結構和業務模型。

 

作者:產品小思考,B端產品經理

本文由 @產品小思考 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 挺好~

    回復
  2. 什么場景下、什么人,產生了需求(問題)

    來自上海 回復
  3. 我的文章寫了10篇,可以一起努力呀。我是曉莊同學,微信號:znc0520,公眾號:小曉莊同學產品筆記 ??

    來自河南 回復
  4. 作為一個b端產品,終于看到了一個實操過的人寫的東西,雖然很粗但是看得出來是從實踐中總結出來的東西,很贊,訂閱了!

    來自上海 回復
    1. 他這個完全可以做一個案例來出來套教程,比那些只會分析理論需求的強太多

      來自北京 回復
  5. 竟然才35訂閱,我感覺寫得很棒啊。

    回復
    1. ??

      回復
    2. ??

      來自四川 回復
  6. 來自北京 回復
  7. 核心三點:解決什么問題,給誰使用,如何實現是最棒的。

    來自上海 回復
    1. 解決什么問題,更深入的說:創造了什么價值

      來自四川 回復
  8. 我也是b 多交流

    回復
    1. 可以 可以

      來自四川 回復
  9. 很實用的方法論。贊!

    來自廣東 回復
  10. 不判斷一下有沒有菜???

    來自北京 回復
    1. 簡單舉了例子,理一下我的方法。要深入下去,業務就很復雜了,不是一篇小文章能寫完的了。

      來自四川 回復
  11. 所以有些人在做功能,有些人在做解決方案

    來自浙江 回復
    1. 贊同 ??

      來自四川 回復
    2. 不了解業務考想的做出來的就是功能,這樣做出來的功能的復用性也不是特別高,更多的是一次性用品
      了解業務+想做出來功能復用性會很高,承前啟后嘛,多個功能匯聚就成了解決方案 哈哈

      來自浙江 回復
    3. 并不僅僅于此,B端需求,如果不做業務分析,極大可能做出的功能,也是廢的,不能滿足客戶需求。

      來自四川 回復
    4. 對啊 沒有說這個僅僅針對B端 哈哈

      來自浙江 回復