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

一、背景

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

根據(jù)項目經(jīng)理的口述以及各方資料，我們來整理一下產(chǎn)品背景：

“校園傳統(tǒng)報修的用戶痛點：填寫紙質(zhì)報修單、固定地點報修、分類報修信息低效易錯、流程復雜、學校后勤服務工作不及時、水平低。針對這些問題，我們要打造一個網(wǎng)絡報修管理平臺，在報修用戶和后勤之間建立起一座橋梁，對于簡化報修流程，提高服務效率，起到良好的推動作用！”

二、用戶

了解完背景以后，我們需要知道都有哪幾類用戶來用這個產(chǎn)品。

既然是網(wǎng)絡報修管理平臺，我們直觀地想一下，最起碼需要有報修人和維修人，然后除了業(yè)務前端之外，對于數(shù)據(jù)的管理和維護，我們需要搭建一個管理后臺，既然有管理后臺，最起碼需要一個后臺管理員，而這個后臺管理員，肯定是由后勤管理部人員來擔任的。

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

三、流程

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

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

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

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

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

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

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

四、功能結構視圖

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

1. 目的意義

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

目的： 主要是輔助設計和技術開發(fā)人員了解產(chǎn)品的全局結構。

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

2. 方式方法

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

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

3. 梳理思路

（1） 產(chǎn)品層面

通過以上分析，我們可以將產(chǎn)品形態(tài)分為三類：

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

（2） 模塊、頁面層面

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

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

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

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

后勤管理員的管理后臺：從系統(tǒng)層面來說，用戶管理，角色管理，權限管理，這些是必備的。

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

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

（3） 元素、操作層面

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

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

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

4. 上圖

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

關于管理后臺的內(nèi)容，大家可以試著自己梳理一下哦~~

五、信息結構視圖

1. 目的意義

主要是輔助服務端技術人員創(chuàng)建或調(diào)整數(shù)據(jù)結構的參考文件。

信息結構圖是一種接近數(shù)據(jù)庫結構的圖表，但是他并不是真正意義的數(shù)據(jù)庫結構。技術人員會根據(jù)這張圖表的內(nèi)容再結合產(chǎn)品原型或需求文檔，然后規(guī)劃和設計出真正意義上的數(shù)據(jù)庫結構。

2. 上圖

主要是以面向?qū)ο蟮乃枷?，整理出每個對象包含的屬性，我們舉一個例子：

六、結語

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

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

本文由 @曉莊同學

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

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