做需求分析,你要弄明白的5件事
856
2019-11-08 09:56    文章来源:晓庄同学产品笔记 原创:啊庄
文章摘要:要做的是一个网络报修管理平台,而本人未参与调研,手头得到的资料,有一个竞品的平台,以及另外一个竞品的整体建设方案,注意,平台和方案分属不同竞品,以及项目经理口述的客户需求,我们来看看通过这些材料,在需求分析阶段,需要弄明白哪几件事。

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

1.png

  一、背景

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

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

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

  二、用户

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

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

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

  三、流程

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

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

  1. 整个流程的起始点是什么?整个流程的终结点是什么?

  2. 在整个流程中,涉及到的角色都是谁?

  3. 在整个流程中,都需要做什么事情?

  4. 做每一件事情的条件是什么?

  5. 分别产出什么结果?


好,按照这个步骤,我们一步一步来梳理一下:

  1. 整个流程的起始点是有人发现东西坏了,申请报修;终结点是东西修好了,然后报修人给出评价;

  2. 整个流程中,涉及的角色就是咱们之前说的那三类了:报修人;维修师傅;后勤管理员;

  3. 在整个流程中,需要做的事情包括:申请报修、审批、派单、接单、维修填写耗材、评价;

  4. 条件这个就很好思考了,我们说两句就明白了:派单的条件是审批通过呀,审批不通过无法派单呀;评价的条件是维修完成呀。嗯,就说两句,其他自己想;

  5. 产出结果也说两句:审批通过的结果就是可以派单了,审批不通过的结果,当然就是退回,并给报修人发送消息通知,告知他报修审核未通过了。


好,接下来就是以流程图的形式,言简意赅地表达了,笔者习惯使用 Visio,我们来 look 一下:

看图之前,再补充一点,需求中有提出,派单的形式包括自动派单和手动派单两种。

2.png

  四、功能结构视图

好了,流程我们定完了以后,接下来就要开始做功能概设的工作了。

1. 目的意义

我们先来看一下功能视图的目的和意义。

目的:主要是辅助设计和技术开发人员了解产品的全局结构。

意义:功能结构视图,在项目前期来说,是我们产品的功能概设,是我们设计原型之前的一种思路梳理方式;在项目后期来说,可以作为产品的功能目录,其作用可以理解为一本书的目录。

2. 方式方法

那么我们该怎么梳理功能结构视图呢?

道:道即思想,笔者在我的另一篇文章《三年产品经理的转正述职报告》中提到过怎样获取需求,即看一下市场上面有什么最新的技术,有什么更好的产品,我们取其精华,去其糟粕,以「拿来主义」的思想进行适用性创新,就可以调制我们自己的鸡尾酒了(这里提的一个概念是「创新」,我们所处的时代,「创造」或许已不复存在,对于这一论点,有兴趣的同学可以看一下凯文·凯利的《必然》)。

术:术即方法,梳理产品结构的层次依次为:产品—>模块—>子模块—>页面—>子页面—>元素—>操作。

器:器即工具,这个时候需要用到思维导图之类的工具了,晓庄同学习惯使用的是 xmind。

3. 梳理思路

(1)产品层面

通过以上分析,我们可以将产品形态分为三类:

  1. 报修人—移动前端;

  2. 维修师傅—移动前端;

  3. 后勤管理员—管理后台。


(2)模块、页面层面

说一下笔者使用的方法:先罗列,再排列。

什么意思呢,就是先将用户通过产品,可以做或者说需要做哪些事给罗列出来,然后再进行排列组合即可。

报修人的移动前端:可以提交报修单、可以查看报修进度、可以给报修师傅留言、修完了可以进行评价、然后报修单不止一个,可以查看报修单的列表、通过列表可以查看详情。

维修师傅的移动前端:有人报修了,需要给维修师傅一个提醒;报修师傅可以对报修单进行处理,选择接收或者拒绝;并不能每次报修都能及时维修,维修师傅可以填写一下修理时间反馈给报修人;报修人有留言了,维修师傅可以回复;修理过程中,维修师傅需要登记耗材;报修人评价完了,维修师傅可以查看。

后勤管理员的管理后台:从系统层面来说,用户管理,角色管理,权限管理,这些是必备的。

从业务层面来说,主线是维修单,首先需要对维修单进行管理,包括审批,派单;然后需要对维修师傅进行管理,这些维修师傅的基础数据,需要录入和维护;为了提升效率,每个维修师傅都是什么工种,这个可以搞一下,不然东西坏了,需要分配师傅,管理员哪知道谁可以去修;

同样的,维修区域和维修物品的基础数据及分类,后台也可以搞一下,不然报修人写个「学校南门从左边查第二栋楼有东西坏了」,这找地方都得找半天,带工具和材料,也不知道带什么,这多麻烦;好了,这些基本的业务都能够满足了,作为管理后台,统计分析是必备的,大概想一下,工作量统计、评价统计、故障物品统计、故障区域统计、耗材统计等这些可以搞一下。

(3)元素、操作层面

好了,我们模块、页面层面的梳理完了,接下来就该梳理元素、操作层面的内容啦。方法呢,跟模块、页面层面的大同小异。

我们就拿提交报修单这个界面举个例子还分析一下,请往下看。

元素:先得告诉别人,什么东西需要修—报修物品;然后我们都讲究有图有真相的—上传照片;再然后得告诉别人到哪修—报修地址;最后别人到了,总得联系你—报修人姓名、电话;

操作:我们之前说了,报修的物品和地点,后台是有分类的,所以我们我们这里需要是选择的操作—下拉列表框;还有什么内容,想要补充一些的,需要有个备注功能—文本输入框;内容填完了,需要提交—提交按钮。

4. 上图

3.png

好了,按照以上的方法进行梳理,我们的功能结构视图就能够出来啦。是不是上面的内容看着有点乱,不过没关系,一切的混乱都是有序的开端,看下面的这张图,是不是就很清楚了。

关于管理后台的内容,大家可以试着自己梳理一下哦~~

  五、信息结构视图

1. 目的意义

主要是辅助服务端技术人员创建或调整数据结构的参考文件。

信息结构图是一种接近数据库结构的图表,但是他并不是真正意义的数据库结构。技术人员会根据这张图表的内容再结合产品原型或需求文档,然后规划和设计出真正意义上的数据库结构。

2. 上图

4.png

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

  六、结语

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


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)管理咨询有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)管理咨询有限公司将追究其相关法律责任。

评论