做需求分析，你要弄明白的五件事

首先說明一下筆者此次做需求分析的背景：要做的是一個網絡報修管理平台，而本人未參與調研，手頭得到的資料，有一個競品的平台，以及另外一個競品的整體建設方案，注意，平台和方案分屬不同競品，以及項目經理口述的客戶需求，我們來看看通過這些材料，在需求分析階段，需要弄明白哪幾件事。

一、背景

做一個產品，我們首先需要了解做這個做這個產品的背景，也就是客戶為什麼需要這個產品呢？只有了解這些，我們才能有的放矢地來設計產品。

根據項目經理的口述以及各方資料，我們來整理一下產品背景：

「校園傳統報修的用戶痛點：填寫紙質報修單、固定地點報修、分類報修信息低效易錯、流程複雜、學校後勤服務工作不及時、水平低。針對這些問題，我們要打造一個網絡報修管理平台，在報修用戶和後勤之間建立起一座橋樑，對於簡化報修流程，提高服務效率，起到良好的推動作用！」

二、用戶

了解完背景以後，我們需要知道都有哪幾類用戶來用這個產品。

既然是網絡報修管理平台，我們直觀地想一下，最起碼需要有報修人和維修人，然後除了業務前端之外，對於數據的管理和維護，我們需要搭建一個管理後台，既然有管理後台，最起碼需要一個後台管理員，而這個後台管理員，肯定是由後勤管理部人員來擔任的。

我們將用戶暫且分為三類：報修人、維修師傅、後勤管理員。

三、流程

好了，背景和人說完了，我們該說事了。怎樣把一件事說清楚呢，最直觀的就是流程圖了。

在這裡順便說一下，做流程圖的五個步驟：

1. 整個流程的起始點是什麼？整個流程的終結點是什麼？
2. 在整個流程中，涉及到的角色都是誰？
3. 在整個流程中，都需要做什麼事情？
4. 做每一件事情的條件是什麼？
5. 分別產出什麼結果？

好，按照這個步驟，我們一步一步來梳理一下：

1. 整個流程的起始點是有人發現東西壞了，申請報修；終結點是東西修好了，然後報修人給出評價；
2. 整個流程中，涉及的角色就是咱們之前說的那三類了：報修人；維修師傅；後勤管理員；
3. 在整個流程中，需要做的事情包括：申請報修、審批、派單、接單、維修填寫耗材、評價；
4. 條件這個就很好思考了，我們說兩句就明白了：派單的條件是審批通過呀，審批不通過無法派單呀；評價的條件是維修完成呀。嗯，就說兩句，其他自己想；
5. 產出結果也說兩句：審批通過的結果就是可以派單了，審批不通過的結果，當然就是退回，並給報修人發送消息通知，告知他報修審核未通過了。

好，接下來就是以流程圖的形式，言簡意賅地表達了，筆者習慣使用Visio，我們來look一下：

看圖之前，再補充一點，需求中有提出，派單的形式包括自動派單和手動派單兩種。

四、功能結構視圖

好了，流程我們定完了以後，接下來就要開始做功能概設的工作了。

1. 目的意義

我們先來看一下功能視圖的目的和意義。

目的： 主要是輔助設計和技術開發人員了解產品的全局結構。

意義：功能結構視圖，在項目前期來說，是我們產品的功能概設，是我們設計原型之前的一種思路梳理方式；在項目後期來說，可以作為產品的功能目錄，其作用可以理解為一本書的目錄。

2. 方式方法

那麼我們該怎麼梳理功能結構視圖呢？

• 道：道即思想，筆者在我的另一篇文章《三年產品經理的轉正述職報告》中提到過怎樣獲取需求，即看一下市場上面有什麼最新的技術，有什麼更好的產品，我們取其精華，去其糟粕，以「拿來主義」的思想進行適用性創新，就可以調製我們自己的雞尾酒了（這裡提的一個概念是「創新」，我們所處的時代，「創造」或許已不復存在，對於這一論點，有興趣的同學可以看一下凱文·凱利的《必然》）。
• 術：術即方法，梳理產品結構的層次依次為：產品—>模塊—>子模塊—>頁面—>子頁面—>元素—>操作。
• 器：器即工具，這個時候需要用到思維導圖之類的工具了，曉莊同學習慣使用的是xmind。

3. 梳理思路

（1） 產品層面

通過以上分析，我們可以將產品形態分為三類：

1. 報修人—移動前端；
2. 維修師傅—移動前端；
3. 後勤管理員—管理後台。

（2） 模塊、頁面層面

說一下筆者使用的方法：先羅列，再排列。

什麼意思呢，就是先將用戶通過產品，可以做或者說需要做哪些事給羅列出來，然後再進行排列組合即可。

報修人的移動前端：可以提交報修單、可以查看報修進度、可以給報修師傅留言、修完了可以進行評價、然後報修單不止一個，可以查看報修單的列表、通過列表可以查看詳情。

維修師傅的移動前端：有人報修了，需要給維修師傅一個提醒；報修師傅可以對報修單進行處理，選擇接收或者拒絕；並不能每次報修都能及時維修，維修師傅可以填寫一下修理時間反饋給報修人；報修人有留言了，維修師傅可以回復；修理過程中，維修師傅需要登記耗材；報修人評價完了，維修師傅可以查看。

後勤管理員的管理後台：從系統層面來說，用戶管理，角色管理，權限管理，這些是必備的。

從業務層面來說，主線是維修單，首先需要對維修單進行管理，包括審批，派單；然後需要對維修師傅進行管理，這些維修師傅的基礎數據，需要錄入和維護；為了提升效率，每個維修師傅都是什麼工種，這個可以搞一下，不然東西壞了，需要分配師傅，管理員哪知道誰可以去修；

同樣的，維修區域和維修物品的基礎數據及分類，後台也可以搞一下，不然報修人寫個「學校南門從左邊查第二棟樓有東西壞了」，這找地方都得找半天，帶工具和材料，也不知道帶什麼，這多麻煩；好了，這些基本的業務都能夠滿足了，作為管理後台，統計分析是必備的，大概想一下，工作量統計、評價統計、故障物品統計、故障區域統計、耗材統計等這些可以搞一下。

（3） 元素、操作層面

好了，我們模塊、頁面層面的梳理完了，接下來就該梳理元素、操作層面的內容啦。方法呢，跟模塊、頁面層面的大同小異。

我們就拿提交報修單這個介面舉個例子還分析一下，請往下看。

• 元素：先得告訴別人，什麼東西需要修—報修物品；然後我們都講究有圖有真相的—上傳照片；再然後得告訴別人到哪修—報修地址；最後別人到了，總得聯繫你—報修人姓名、電話；
• 操作：我們之前說了，報修的物品和地點，後台是有分類的，所以我們我們這裡需要是選擇的操作—下拉列表框；還有什麼內容，想要補充一些的，需要有個備註功能—文本輸入框；內容填完了，需要提交—提交按鈕。

4. 上圖

好了，按照以上的方法進行梳理，我們的功能結構視圖就能夠出來啦。是不是上面的內容看著有點亂，不過沒關係，一切的混亂都是有序的開端，看下面的這張圖，是不是就很清楚了。

五、信息結構視圖

1. 目的意義

主要是輔助服務端技術人員創建或調整數據結構的參考文件。

信息結構圖是一種接近資料庫結構的圖表，但是他並不是真正意義的資料庫結構。技術人員會根據這張圖表的內容再結合產品原型或需求文檔，然後規劃和設計出真正意義上的資料庫結構。

2. 上圖

主要是以面向對象的思想，整理出每個對象包含的屬性，我們舉一個例子：

結語

好了，我們今天討論了需求分析階段，需要弄明白的五件事，並且通過實際案例進行的剖析，想必大家看起來已經很清楚了。我們也可以看到，從前往後，內容都是逐漸豐富的。把這五件事搞定以後，就需要找領導們進行第一輪的評審，而下一階段，就可以開始原型製作。概設—>詳設！

曉莊同學花了近兩天的時間來整理這篇文章，如果對您有所幫助的話，也希望您能夠打賞支持一下，曉莊同學不勝感激。學海無涯苦作舟，在前行的道路上，感謝有您一路相伴！

本文由 @曉莊同學

原創發布於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。