写在前面
———————————————————————————————————
今天看到产品群里有人讨论，PRD到底要用word写，还是用Axure写？哎都9102年了，这个问题还是有争议。其实我觉得用什么工具都可以，只要受众对象接受，自己用着方便就可以，没必要非要争个你死我活吧。那么，什么 样的需求文档是受众对象乐意看，自己写着又清晰的呢~
正文开始
————————————————————————————————————
先放出思维导图来展示下本文的结构（sorry，我的是使用模式有水印，懒所以没去）：
霸王花需求分析.png
需求来源
需求的来源有很多，比如公司业务、用户的反馈、运营的抱怨等。看似是分人群或者方向，其实我觉得更应该是分阶段，阶段不同，需求不同，阶段不同，采集方式也不同。
0.大方向：公司业务发展需求
1.产品规划阶段（定性需求，确定大方向）
用户调查：一对一访谈、焦点访谈小组、电话调研等。
2.产品早期阶段
问卷调查：扩大样本，定量需求
竞品分析：确认功能范围
运营建议：运营同学根据经验及公司发展需要一起评估需求
3.产品上线阶段
用户反馈：用户已经使用了就会有大量的反馈信息，从而确定产品的方向，以及迭代的优先级
4.产品优化阶段
数据分析：根据运营后台的数据，分析出用户使用情况，再根据数据进行优化。
需求优先级
需求优先级的确定有很多优秀的方法，但是很多情况下，项目周期紧，根本没时间想那么多，比如市场调研后再根据结果来分析每个需求的各种优先级，像必备属性、期望属性、魅力属性、无差异属性等。
我比较喜欢用【四个象限】的方式，下面来简单介绍下吧。
四个象限，有【两个维度】，包括重要性与紧急程度，如下图所示：
四个象限.png
除了从这两个维度考虑，还要考虑一下实现的难度哦~
需求文档
需求文档不仅是产品人自己看，还有研发、UI、测试、运营等小伙伴看，所以里面的内容要尽量详尽。但是，详尽的意思不是啰嗦，是应该把需要注释的东西都言简意赅的注释在旁边，这样会大大降低其他小伙伴询问你和你修改文档的频率。注释些什么呢？交互动作、特殊UI需求、数据需求等，这些是参与研发的小伙伴需要看的，但是运营可不太关心这些，他们想知道这些功能会给他的用户与内容带来什么，会给数据上带来什么变化。
以下是PRD的目录：
prd目录.png
写prd需要注意的点：
1.描述详尽，有必要的话，可以使用表格来列出需求点，采用5w1h原则描述就可以。
如下：
需求表.png
2.各种状态表述清楚，比如上传图片的功能，没上传的时候是什么样，上传后预览是什么样，删除是什么样。
3.交互，比如页面之间的过度，你希望平滑的过度，就要在文档里进行注释，不然研发就可能做成翻转或者逐渐显现之类的效果。
初来乍到，请多关照~~~
网友评论