需求分析不是僅靠“想”就能完成的，還需要依據(jù)嚴(yán)謹(jǐn)而科學(xué)的分析方法。

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

可是具體怎么分析呢？怎么將用戶需求轉(zhuǎn)化可見的原型？相信大家讀完也是一知半解。在整個過程中，完全靠產(chǎn)品經(jīng)理頭腦風(fēng)暴？

我認(rèn)為這只能算「需求挖掘」。需求分析應(yīng)該是嚴(yán)謹(jǐn)而科學(xué)的，不僅僅是靠「想」。當(dāng)然，可能這是C端產(chǎn)品業(yè)務(wù)較為簡單的原因。不同于C端需求，B端需求都來至于垂直行業(yè)，高度貼合客戶業(yè)務(wù)。所以，B端需求分析，需要有一套結(jié)合業(yè)務(wù)的分析方法。本文主要分享我的B端需求分析方法。

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

從產(chǎn)出上分析，我需求分析個階段的產(chǎn)出依次分為功能列表、需求功能對照表、功能清單/信息架構(gòu)。

開始分析之前，我首先會先整理需求。將需求池中需求的來源、優(yōu)先級標(biāo)注清楚。B端產(chǎn)品的需求通常來源于客戶、老板、競品和對業(yè)務(wù)的深度建模分析。優(yōu)先級，筆者主要劃分為高、中、低。

我的需求分析方法，主要分為三步場景分析、角色分析、業(yè)務(wù)分析。整個分析過程高度依賴UML。下文以餐館點餐系統(tǒng)舉例分析。

一、場景分析

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

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

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

二、角色分析

角色分析的目的是整理出需求中包含的角色，以及明確角色所包含的屬性。角色可能是設(shè)計出的功能的使用者，也可能是系統(tǒng)的示例數(shù)據(jù)。在角色分析時，我通常使用ER圖來描述角色。該ER圖中只表示角色，不用表示其他實例和關(guān)聯(lián)關(guān)系。

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

完成角色的分析后，下一步進行業(yè)務(wù)分析。

三、業(yè)務(wù)分析

業(yè)務(wù)分析的目的是，分析用戶需求背后的業(yè)務(wù)流程，理清楚相關(guān)的數(shù)據(jù)結(jié)構(gòu)和操作，為用戶需求制定合適的解決方案，并把用戶需求轉(zhuǎn)化為實際的建模描述(用UML表示)，為功能清單/信息架構(gòu)制作打下基礎(chǔ)。

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

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

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

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

業(yè)務(wù)分析惋惜完成后，我們就完成了需求分析。我們需要產(chǎn)出直觀的文檔，除了上方分析的文檔外，還需要產(chǎn)出功能清單或者信息架構(gòu)。這里以功能清單舉例：通過功能清單，就將功能需求轉(zhuǎn)化成產(chǎn)品需求。下方為一份簡單的功能清單。實際我們在制作功能清單時，一定要注重細節(jié)的把握，細節(jié)體現(xiàn)專業(yè)。

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

四、總結(jié)

可能很多產(chǎn)品經(jīng)理，不認(rèn)可業(yè)務(wù)分析就是需求分析的一部分。在B端產(chǎn)品的需求分析中，需求和業(yè)務(wù)是高度耦合的，沒有深入業(yè)務(wù)層面的需求分析，都是不夠客觀的。當(dāng)然，可能在大公司有專門的的業(yè)務(wù)分析師做業(yè)務(wù)分析，B端產(chǎn)品經(jīng)理不一定需要深入分析業(yè)務(wù)。但對于B端產(chǎn)品經(jīng)理來說，業(yè)務(wù)分析能力也是需求分析能力的一部分，不是任何時候都有業(yè)務(wù)分析師幫助產(chǎn)品經(jīng)理分析業(yè)務(wù)。

做B端需求分析，我的原則是：盡可能通過UML的方式，將抽象的業(yè)務(wù)邏輯轉(zhuǎn)化為可見的數(shù)據(jù)結(jié)構(gòu)和業(yè)務(wù)模型。

作者：產(chǎn)品小思考，B端產(chǎn)品經(jīng)理

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

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