分享客户需求分析该如何做。

首先说明一下笔者此次做需求分析的背景：要做的是一个网络报修管理平台，而本人未参与调研，手头得到的资料，有一个竞品的平台，以及另外一个竞品的整体建设方案，注意，平台和方案分属不同竞品，以及项目经理口述的客户需求，我们来看看通过这些材料，在需求分析阶段，需要弄明白哪几件事。

一、背景

做一个产品，我们首先需要了解做这个做这个产品的背景，也就是客户为什么需要这个产品呢？只有了解这些，我们才能有的放矢地来设计产品。

根据项目经理的口述以及各方资料，我们来整理一下产品背景：

“校园传统报修的用户痛点：填写纸质报修单、固定地点报修、分类报修信息低效易错、流程复杂、学校后勤服务工作不及时、水平低。针对这些问题，我们要打造一个网络报修管理平台，在报修用户和后勤之间建立起一座桥梁，对于简化报修流程，提高服务效率，起到良好的推动作用！”

二、用户

了解完背景以后，我们需要知道都有哪几类用户来用这个产品。

既然是网络报修管理平台，我们直观地想一下，最起码需要有报修人和维修人，然后除了业务前端之外，对于数据的管理和维护，我们需要搭建一个管理后台，既然有管理后台，最起码需要一个后台管理员，而这个后台管理员，肯定是由后勤管理部人员来担任的。

我们将用户暂且分为三类：报修人、维修师傅、后勤管理员。

三、流程

好了，背景和人说完了，我们该说事了。怎样把一件事说清楚呢，最直观的就是流程图了。

在这里顺便说一下，做流程图的五个步骤：

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. 上图

主要是以面向对象的思想，整理出每个对象包含的属性，我们举一个例子：

结语

好了，我们今天讨论了需求分析阶段，需要弄明白的五件事，并且通过实际案例进行的剖析，想必大家看起来已经很清楚了。我们也可以看到，从前往后，内容都是逐渐丰富的。把这五件事搞定以后，就需要找领导们进行第一轮的评审，而下一阶段，就可以开始原型制作。