初期的需求分析文档如何写?

3 评论 29097 浏览 87 收藏 17 分钟

本文是一个“小白版”的需求分析文档,主要结合“会务管理系统 – 会议报名模块”的产品案例,对需求文档的框架展开了详细说明,与大家分享。

本文的“初期需求分析文档”不是产品经理工作中输出的产品需求说明书(prd),是为初期用研后的资料整理后进行输出的(更落地的需求分析),文档格式除了通用部分,都有相对的调整,与市面上的文档区别还是很多的;比如场景图、及文档内对业务及流程的落地说明,并非对企业内部协作使用的专业化文档,本文档主要用于初期的资料(数据)留痕。

如果文章中的文档进行深度分析,就会专业化,进而演变成需求分析文档(专业化:对内协作使用)、产品需求说明书(PRD)、概要设计等。

一、前言

本文从“会务管理系统 – 会议报名模块”的产品案例,说明初期的需求分析文档到底如何写,如何更落地;让自己及其他阅读伙伴更清晰的认知产品的场景、业务、流程,一步步形成完整的产品闭环,说用户懂的话,交出一份“小白版”的需求分析文档~

二、为什么写小白版的需求文档?

1. 文言文 PK 白话文

(1)“文言文”

很多产品人在初期产品调研后,做了信息收集及整理,输出需求分析文档,虽然这份文档输出是更好的铺垫接下来的工作,但往往太过于官方,或者过于业务化,对于阅读文档的目标用户没有做到同理心,领导看不懂,协作伙伴看不懂,这样的文档,价值何在呢?

产品人输出任何东西都要尽可能的有价值,而我们是最应该知道什么是价值的人,这对自己也是一种沉淀性的输出。

os:阅读文档的目标用户,这里面客户也算其一(偏B端);在特殊情况下,文档输出的第一版是需要与用户核对,敲定很多业务规范及流程中的细节。

(2)“白话文”

在做内容输出时,谨记说人话,专业性语言少来,尽可能让阅读人员能够“小白化”的读懂,尽可能场景化,通俗易懂。

2. 明确文档的用户

不同角色(面向群体):

  1. 产品人:为产品部门内相关设计人员提供需求信息的展示,同时对自己为自查,对项目做留痕。
  2. 用户/客户:这里的客户(B端)会与产品人进行输出文档的业务准确性做深入碰撞,敲定业务框架。
  3. 团队成员:对接协作伙伴设计、程序;清晰明了,无需精细化宣讲

3. 明白文档价值

文档价值(文档目的)

  1. 输出:把大脑中的构思落地出来,形成文档,给自己做自查,给伙伴清晰的视野反馈。
  2. 留痕:把关键性的信息全部囊括在内,有可追溯性,对内对外皆可做到整个项目的管理。

4. 如何让文档更落地

让文档落地,我们首先要明白,写文档的本质是什么?

首先我们在输出文档时,对于我们目标用户必须要明确,而不是太过自我,很多业务细节延伸出来的伴生性功能需要雕琢一下,这些伴生性功能是否符合业务流、是否优化了业务流;

那么我们需要切换到用户的业务场景视角,去发现这些是否真的是用户需要的,围绕着业务场景及各个角色进行输出内容。

三、文档框架

框架分四部分:通用部分、场景流程、需求集合、其他说明。

os:框架的四个部分是本人泛指,自我定义,大家可以自己调整自己的文档框架

1. 通用部分

文档目的:

  1. 阅读者介绍:简要说明阅读用户是谁即可,这里点明产品的使用用户及角色做一个定义。
  2. 业务名称解释:对于项目中涉及的业务流程中出现的业务名词做相应解释。

项目综述:

  1. 项目背景:围绕整个项目的背景进行说明,着重描述业务场景。
  2. 项目范围:业务场景中所涉及到的主线、支线业务流(模块)全面覆盖;这里包括伴生性(延伸性)需求。
  3. 项目目标:点出产品实现的目的,而不是产品人揣摩设计出来的(这里说的揣摩是指优化性需求,并非实际需求)

so:此部分为需求分析模板的通用部分,不做举例说明了;切记一点,尽可能让这部分足够落地的阐述;用户阅读文档的第一部分就如同天书,后面也不会详细去看。

2. 场景流程

业务流程:

(1)总(核心)业务流程

(2)业务流程说明

水务行业协会会务组织人员能在会务系统上编写和发布会议通知、酒店信息、房间信息等。

参会人员能从电脑、手机上查看会议通知和报名,报名后可以在网站上缴费、订房、填写发票信息、网上签到,其中这几个部分的操作没有任何强关联和限制,不分先后。

业务流可以有以下几种情况,例如:

  1. 参会人员报名后可以进行缴费,之后预定房间,网上签到;
  2. 参会人员可以不缴费、直接预订房间,网上签到;
  3. 参会人员可以不缴费、不预定房间,直接网上签到;
  4. 参会人员可以报名后直接去现场签到;
  5. 参会人员可以不提前报名,直接到现场签到,一同办理:报名、缴费、订房、现场签到多项内容。

其中现场签到前进行网上签到是有好处的,签到后可以查看最新的会议动态。不进行网上签到的必须现场签到后才可以查看会议动态;

现场签到后,就可以按照分配的房间,办理入住。并且领取资料和查看最新会议动态。最新会议动态可以在网页上和手机上查看,内容包括:最新议程、酒店信息变更、房间信息更新等。

应用终端:Web、wap、H5;

业务场景:

1)前台:会务管理系统中,前台的用户角色以及对应业务模块的交互关系;

如下图:

2)后台:在会务管理后台中,用户可分为五类

  1. 会务组领导:会务组的领导一般只需要查询信息,看会议的报名、缴费、签到等情况。后续还会增加统计功能。
  2. 会务组信息编辑人员:主要是在会前编辑会议通知,会中发布通知变更,会后查看报名、缴费信息,退款审核等。
  3. 会务组现场服务人员:主要负责现场签到,查看、修改报名及缴费信息,会后负责退款的审核等。
  4. 会议组财物人员:主要查看缴费和发票信息,更改缴费状态,按照退款审核结果完成退款等操作。
  5. 信息录入人员:线下报名过多,会务组人员需要协助录入时就需要本角色的进入,主要负责录入报名和缴费的信息。如需要也可录入签到信息。

如下图:

3. 需求合集

根据业务需求而来的模块,以前台“网上报名”为例,举例说明。

每一模块的结构是这样的:

(1)业务流程图:

(2)需求说明

参会人员可以通过手机、电脑浏览看到会议通知,点击报名入口,进入报名流程;报名通道选择:网站的原始会员可以通过会员通道报名,不是会员的用户可以通过非会员通道报名

1)会员报名:

如果已经是本站的会员,可通过会员登录的通道进入报名页面;登录方式可以支持会员账号和手机号。

会员登录后可以根据情况选择,是要“为自己报名”还是“为他人报名”。

会员登录后可以为自己报名,填写相应的报名信息即可完成报名。

报名信息包括:会员账号、姓名、性别、手机号、单位、职位、省市信息、是否入住、是否接受拼房、是否参观等信息,以上信息都为必填项。

本次需要优化的内容,主要是针对系统在使用过程中,遇到的一些问题;

具体如下:

  1. 有些人报名时填写的手机号码是明显错误的,现在填写的信息有“1”、“11111111”、“ajdiwk”等情况,希望可以提高准确率,比如可以限制位数、数字验证等方法。
  2. 页面中“姓名”的位置有填写单位名称或多人姓名的情况,希望本次优化中可以减少此种情况的发生。由于参会人员中会有少数民族的情况,名字字数比较长,根据以往报名人的名字长度分析,一般都在8个汉字以内。
  3. 很多人的性别和拼房信息是错误的,因为现在的方式是有一个默认选项,部分人就直接略过不去选择了,提交后也可报名成功,很容易被忽略。希望去掉现在的默认选项,必须选择才可以通过。
  4. 为了实现报名情况按照省、市统计的功能,报名信息中还需要增加省市的信息,最好用下拉选择的方式。
  5. 会员报名信息中需要带入本会员已有的相关信息。

报名成功后希望可以收到短信提醒,说明报名的基本情况,内容可包含会议名称、会议地点、会议时间等内容。

注:关于会员的登录方式,现在是会员账号登录;现有的会员注册包括两种情况,一部分是用户自己注册的,另一部分是我们的工作人员录入注册的,这部分主要是为了增加会员数量,这种情况下更不容易记住用户名和密码,下次登录就成了问题,所以我们采取后置关联的方式,关联用户基本信息,如:手机号码、姓名及相关信息进行识别关联,覆盖之前用户信息;这样用户便可以使用手机号码登录。

为他人报名

会员登录后还可以选择为他人报名,选择“为他人报名”后,填写参会人的报名信息即可完成报名。报名完成后还可以继续为他人报名,直到将所有需要参会的人员都报完为止。

2)非会员报名

如果还不是本网站的会员,可以选择非会员报名的通道进行报名。

非会员报名要实现不用注册和登录,只要通过验证即可进行报名。

报名人需要填写的信息包括姓名、单位、手机号码,需要验证身份方可通过。比如,可以通过手机号码进行验证,此处需要提示填写正确的手机号码,以便收取验证码等等。

为了让非会员报名成功后,能够查询自己的报名信息并增加网站的会员数量,非会员报名成功后应按照所填写的手机号码生成一个新的会员账号,报名人可以用此账号登录本网站,并收到“新账号”的短信提醒,希望新账号的初始密码是简单的数字。

此时报名人已经成为会员,后续的操作与会员报名基本相同;可以根据情况选择,是要“为自己报名”还是“为他人报名”。

不一一举例了……等

4. 其他说明

此部分为“数据说明”(记录与业务相关的资料及样式)。

例如:报名单(原线下使用)、回执单、会议小条、发票信息、现场签到表。

“会议小条”数据项包括序号、缴费金额、房间类型、数量、资料份数、房间号码;样式如下:

现场签到表;样式如下:

四、总结

一个小白能看的懂的需求分析文档,要搞定三点

  1. 先明白文档读者是谁,对症下药,不盲目揣测、预言;设计经验固然有用,但请慎用,不要自以为,要用户以为。
  2. 文档呈现的内容一定要够落地,让任何一个用户看见之后,能够清晰知道这个产品是做什么的,解决什么问题,存在的价值是什么。
  3. 模板!模板!模板!任何一个文档模板都是可以自行定义的,你的工作方式不同,文档输出内容就一定会存在差异,以上模板只是一个举例,可以自己雕琢一番。

些许经验分享

很多产品人都很清楚,在过往经历中,一定存在这样的场景,需求到手,没有形成内容落地,直接进行设计;这里可能存在各种外在因素(项目紧急、赶进度、对行业深究不足,过于盲目…等)导致这一环节遗失,直接从需求过度到功能框架、原型设计;这可以理解,但不要掉以轻心,毕竟这是对原始需求的一种留痕。

在简单点说,可以把这个“小白版”的需求分析文档,当做一次会议记录,用最简单,最直白的大白话记录下来,未来翻过来看看,非常清晰的知道,当初的需求是什么,而不是资料的一层层翻阅。

每日一语

年少的时日从我身边滑过,而我从来不知道,那已是生活;

珍惜我们每一次的努力,每一次需求的探索,都是对未知的渴望,也是对自己的沉淀。

 

作者:逐流;微信公众号:Unique先森说产品(ID:Unique_Mr_z)

本文由 @逐流 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 很有帮助,谢谢

    来自山东 回复
  2. 这个好像也不是需求分析文档,还是个功能说明的文档…前期的分析工作都没有体现出来

    来自上海 回复
  3. 很好

    回复