【干货】产品需求到底要写多细??

产品需求文档怎么写,干货!

先来说一下观点:无论是需求原型还是文档,本质上是把我们产品经理的设计思路、方案传递给开发、测试团队。是起到一个信息传递的作用!只要能完成这个任务,就算是成功的产品需求文档。

产品经理需求文档需要包含什么内容?需要写到多细?画原型就行还是必须写出来详细的文档?很多产品经理会有这样的疑惑。因为无论我们写什么,怎么写,都会有人来怼我!今天就跟大家介绍一下在产品需求方面我的经验,供大家参考。

---一、产品经理需求文档的痛---

先来列举下产品经理写需求过程中,会存在哪些比较痛苦的事情!

问题1:多人维护一套原型,越改越乱

工作中比较大的系统可能是多个产品经理协作进行,原型也会是多个产品经理共同修改和维护。

可能会出现以下问题:

1.同时进行功能修改时,没有及时的进行同步;

2.大家画原型的习惯不一样,表述、格式不一致,增加别人的阅读成本;

建议的解决方案,就是进行协作约定:

1.寻找一套最全的原型作为”主版本“,作为最全、最新的一套原型持续更新。

具体操作示例:

(1)每次需要增、删、减、改原型,需要与主版本管理员沟通,确认以哪个主版本为基础修改;

(2)主版本每次变更,版本号加一,历史版本不要覆盖(用SVN的话就不用这个,软件可自行完成);

2.设置“主版本管理员”,负责整个套原型的维护。

具体示例:

(1)维护一个主版本RP文件,主版本包含全部的最新功能模块。指定一名主版本管理员。每期需求各个产品经理,可以自行维护自己的子版本,需求定稿后,需要合并到主版本;

(2)子版本需求经过评审确认后,通知主版本管理员。由子版本产品经理,将子版本涉及到的功能列表,合并到主版本;

3.为了描述一致,可以为页面进行统一的编号。

具体示例:

(1)每个页面添加编号,如果移动端多个屏在同一个页面,则为每屏添加子编号。如下图:

(2)编号规则示例:编号规则,APP以字母A开头;WAP以字母W开头;后台以字母H开头;PC端以字母P开头;后边字母和数字,按照上图示例编号;

4.每期修改,标注出本次,本人所作需求涉及到的页面。

如下图:

其中”页面位置“是本次修改修改了哪些页面,点击文字可以直接链接到相应页面。后边的"(UI)"标注,是说产品经理建议需要UI进行设计的页面。具体哪些页面需要UI进行设计,由UI同事确定。

列举”本期新增需求“不仅在多个产品经理协作时分清版本,也可以让开发、测试同事更加清楚的知道本次修改的需求内容。

问题2:变更多了记不住,最终状态没记录

变更会发生在产品设计和实施的各个阶段。会增加资源消耗,也会大幅度的提高信息传递成本。有些产品迭代多个版本之后,产品需求文档与系统不一致,很多时候都是因为中间发生了零散的变更,而需求文档没有同步更新。

或者变更发生时,干系人都知道情况,但是时间长了大家都会记不清楚。如果后期对产品设计依据进行追溯或者对外交付产品涉及到的商务问题,变更就会很关键。什么时候发生的变更?为什么变更?谁提出的变更?具体变更内容是什么?就需要清晰的记录。所以建议在需求文档中,增加变更记录的表格,每次发生变更个时进行记录。变更记录表示例如下:

要记录清楚时间、变更内容、变更发起人,便于以后追溯。

问题3:开会大家永远说不到一起

为了能让大家有良好的沟通基础,需要进行3个方面的准备:

1.产品背景介绍

很多产品经理介绍需求,一开始就讲自己功能模块怎么进行的设计。其实从听众的角度,开发和测试同事是很难理解你的设计用意的。所以建议在介绍具体设计前,把产品的设计背景和设计思路先介绍下。建议包括:为什么做这个产品?产品目标是什么?本期目标是什么?关键干系人意见是什么?设计的时候是从什么角度考虑的?本期是为了可用,还是为了增加用户体验。

背景介绍的作用:

●大家不了解背景,思路跟不上;

●设计思路不同,设计方案不同,要统一大家思路;否则很难达成共识;

●设计思路是基础,想把基础依据同步给大家,大家拍砖有依据;

●设计思路不认可,先统一设计思路,否则具体设计依据没有意义;

●争取大家的支持,推进统一意见达成;

●调动积极性。为后期实施过程中提高质量做铺垫;大家的脑子里想的是一致的,可以帮助优化产品方案。

●后期出现问题,背景将成为寻找解决方案的依据;

如果这些信息不进行同步,那么开发和测试同事只能变成一群“不带着脑子干活”的手。你说啥,他们干啥。因为他们根本就不知道产品目标,即使有好的建议,也不知道是否符合预期,不敢说。

2.状态、事务定义约定

不知道大家有没有遇到过这种情况,就是大家开会的时候,同一个系统、功能或状态,各自有不同的“叫法”。这样大家越聊越混乱,尤其是讨论细节处理的时候,根本说不到一块。

所以为了避免这种情况,建议在最开始的时候,产品经理给出状态或定义的约定,提高沟通效率,防止误解的发生。

下面给出一个示例。是进行“电子签章”产品设计时,列举的用户状态、合同状态(同一份合同需要多人签署)的定义:

用户状态定义示例

合同状态定义示例

3.整体方案功能架构图、流程图等

这个比较好理解,根据产品模块的大小和阶段。在具体功能设计之前,进行从宏观到微观的信息介绍。

例如:增加系统整体功能结构图,标注本次需求在系统中的位置和作用。增加流程图,将整个业务流程展示给团队,帮助大家形成整体概念,更加容易的理解产品设计。

问题4:需求规则写的粗、写的细都有人“骂街”

这个问题应该是产品经理最头疼的,“需求规则写的粗、写的细都有人“骂街”!

其实客观的说,产品需求写的太粗或太细都有问题。下面列举一下:

写的太粗存在的问题:

●团队成员会存在理解偏差;

●惰性员工,可能故意理解错误,想着节省工作量的方向曲解;

●多团队协作,理解不一致,系统联调造成障碍;

写的太细存在的问题:

●时间不够。项目进度永远都是在赶、赶、赶,,,,

●很多是重复工作,浪费时间,对技术团队可能也没有意义;

●细节可能覆盖到,但是也不可能100%覆盖。可能有细节未覆盖到或有优化空间;

●产品、技术工作边界不清。有些团队可能会要求一些技术方案层面的内容,也写到产品需求里面;

下面给出解决方案建议:

1.写粗、写细分场景,给出几个建议:

●团队是否熟练(包括UI、开发、测试)。团队成员技能越成熟,经验越丰富,可以写的“粗”一点;

●默契的可以写粗糙点。团队合作时间越长,越默契。可以写的“粗”一点;

●新功能写的详细点。新增功能,建议写的“细”一点;

●部门协作存在,,冲突、不和谐因素,,的,防止背锅,撕逼。建议细的“细”一点;

●团队间、不同公司间协作,大家工作习惯不一样,信息传递成本高,默契度低。建议写的“细”一点;

2.积累“模块库”

对一些复用概率高的规则、模块,进行模块库建设(或者叫规则)。例如:手机号输入框校验规则、身份证号输入框校验规则、绑卡模块等。进行尽量详细的设计,并全面记录。但是要形成模块库(共同规则库)。同一个功能或规则再次发生时,直接使用模块库中的内容。

模块库的一些注意事项:

●前期比较痛苦,但是积累一段时间发现,很多功能、规则复用度都很高,会提高效率;

●最好从产品开始,产品、UI、前端、后端都形成对应的模版库。同一个功能,前后都是一套。

●具体场景有不同的,每次在标准模板基础上修改,产品也只写与标准的有哪些不同;

共有规则示例:

规则分类列表示例

具体规则示例

问题5:画原型还是写文档

这个问题产品经理也很头疼,一般都不愿意写WROD的需求文档。

主要有以下原因:

●费时费力;

●大多数情况下技术团队懒得看;(你们的开发、测试是不是基本不看你写的文档?同意的可以举个手)

●变更发生时,修改成本高尤其是和产品原型同时修改,可能改漏了;

其实就像最初说的,产品需求文档是产品传递需求的载体。能完成传递需求的任务就可以了。可以是工软件例如axure、手绘线框、文档等。传说产品大神在卫生纸上画画也能开发出好产品,不过这个我个人没有实践过。。。

针对原型和文档的争论,我给出的建议是:

实施过程中通过原型传递需求,产品上线后两周内,补充需求文档!

解读一下建议:

●传递需求原型足以,实施过程中进度紧张,就只用原型;

●变更发生只修改原型,这样操作成本低;

●文档是有必要的,主要有两个方面:

(1)公司留档积累组织过程资产,防止人员变动影响;

(2)商务交付类,需要给甲方作为交付。所以文档还是需要的;

●约定“上线后两周”补充文档:

(1)上线后一版都会紧急处理一波问题,所以给两周时间写文档;

(2)时间不长,脑子里还记得,太久了就忘记了。。。。

●原型工具哪种都可以,满足目的就行。建议团队内部统一使用一种;

再列下产品原型的一些软件工具:

Axure;

墨刀;

Mockplus;

justinmind;

Sketch;

xiaopiu;

Pop (Prototyping on Paper);

Proto.io;

Balsamiq Mockups;

Fluid UI;

---二、需求原型内容建议---


上一节列举了产品经理写需求过程中可能会存在的问题设置规则不是为了设置障碍,而是解决工作中的问题。那么,为了解决上面的问题,下面给出需求文档包含的内容建议,列表截屏如下:

需求原型包含内容示例

每项列表描述:

1.多人操作原则:(针对多人操作设置的内容)

●本期新增需求:设置版本的概念,标注这个版本包含的内容,以及本次新增内容;

●变更记录:记录本期发生的变更,在期末将原型跟新当最新状态,留档变更记录表。下一期的时候,从新记录变更。

2.公共规则(背景、沟通约定类内容介绍)

●本期背景:包括事项原因、重大决策信息、各种设计思路,设计思路选择依据,设计思路本身情况等;

●功能架构和流程:整体功能架构,本期所处位置。本期业务流程(可能会含有子流程);

●设计状态和名词定义:约定好系统、状态等的名词,提高沟通效率;

●共有基础规则:一些功能,规则的约定。形成模板库,不断积累。(积累较多后,可以从原型中抽离,放到其他工具中维护,例如WiKi)

3.产品功能需求:本期产品功能设计。

(很多产品经理需求原型,只会写这部分内容!!)

这里也给出个示例,大家感受下:

页面名称定义示例

页面需求示例


需要将功能元素、数据格式规则、交互等描述清楚。具体写的多详细,可以参见前面第一节“问题4”中的建议。

4.数据采集需求:

本期需要进行的数据采集项目;

---三、其他细节---


还有其他一些经验,也说一下,供参考:

●数据统计:有数据统计需求的,在需求中写清楚需要统计的数据内容;

●争取团队支持,一起完善:产品方案、需求一定会存在漏洞、遗漏或可优化空间,需要团队一起完善;

用URL链接传递原型:就是原型文档导出,团队内部查看的时候使用URL的方式查看。这样在多个版本时,避免发送本地文件出现的“大家查看版本不一致的情况”。

以上是我在产品需求纂写过程中的一些心得,希望在实际工作中能帮到大家!!

完-------------------------

--------------------------------------

作者:董小圣(微信公众号:小圣聊产品)

--------------------------------------

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表