一、产品经理的三大文档之PRD文档的意义
（一）百度百度
该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
（二）简单概述
跟项目成员说明产品的需求，可以更高效、高质量的进行工作。
二、个人工作中的PRD文档迭代路径
（一）1.0版本（word+原型的形式）
15年多数PM都在用此形式编写PRD文档。
缺点：1.项目成员查看需要打开两个文件进行查看，阅读成本高、效率低；
2.word文档格式文字占了较大的篇幅，随便一翻密密麻麻的文字~阅读较枯燥，需求描述送达率较低；
（二）2.0版本（原型+便签的形式）
新版Axure迭代出了便签的形式，在原型旁边附上便签，在便签写上需求说明，再拉个虚线连接对应的元件。
缺点：页面的需求说明较少时，此方法还是可以的~然而当说明较多时，页面上悬浮着许多虚线、五彩斑斓的便签...视觉体现不好，而且展示的太多，在项目成员读者看来也会无重点！
（三）3.0版本（原型+元件注释+流程图形式）
利用Axure新版需求控件的功能~把对应的需求写到元件说明里，流程图用Axure画（或者把visio画好的流程图帖过来），旨在把表达需求的输出物整合到一起，自己在17年中之前竟然没有发现Axure的这个功能（捂脸痛哭状），虽说Axure、word等都是工具，但我们还是要善用工具！
三、PRD包含的内容以及意义
先展示一下Axure制作的3.0版本的原型目录
先展示一下Axure制作的3.0版本的原型目录
1.项目背景
简单描述项目的背景、目标等，让项目的参与者明白项目是为什么而做和价值所在，方便项目的参与者有整体的认知以及明确方向。
2.修订历史
写清楚每次修改的编号、修改的内容、备注等，方便沟通和追溯。
3.用户范围
本系统涉及的角色以及对应角色的职能、描述、权限等
4.名词术语表
具体专业名词、缩写的解释以及说明，帮助项目成员方便理解业务并统一名称。
5.迭代记录
上线后的每一次迭代的记录，产品迭代记录了产品成长路径，从产品的迭代中察觉产品动向，为规划未来产品成长提供参考。
6.全局交互
记录整个项目通用的交互形式，如：弹框样式、异常页面等，在某个页面需要用到的时候直接写引用规范就可以，避免重复设计。
7.项目排期进展
项目启动定完大概的排期后，明确对应职能人员以及对应的时间节点，方便协作、跟进、追溯；
8.产品功能结构图
结构化的描述系统内部对需求实现的具体功能，便于功能评审、沟通等
9.用例图
定义了系统的的功能需求，系统功能之间以及同功能参与者之间关系的鸟瞰图，使读者对象对功能需求、角色之间的关系有主体上的认知；
10.流程图
以水流的形式由浅入深的描述事件、任务、管理等的过程，可以帮助设计人员梳理过程、逻辑、准确传达需求、查漏补缺。流程图又分为业务流程图、页面流程、功能流程、数据流程等，根据项目、团队的需要，流程图的粒度自行把控。
11.非功能需求
非功能性需求的描述，如：
(1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求；
(2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求；
(3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求；
(4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求；
(4) 运行环境约束：用户对软件系统运行环境的要求；
(5) 外部接口：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求；
(6) 数据监控需求：数据埋点监控，在新功能上线后，验证是否达到预期的商业目标，用数据反馈驱动迭代；
四、优秀PRD需要具备的要素
1.可验证：对于功能性的描述，不要描述一些无法定性的东西，例如：支持高并发、响应快都是模棱两可的，无法验证的；
2.正确、无歧义：确保文档的表述跟你的思路是一致的，表述不会产生歧义；
3.一致：文档中用词用语一致，对于同一事物的表述应该一样，避免混用同义词 ；
4.方便迭代：利于后期的修改以及调整；
5.可追踪：每个功能性需求的来源应该是清楚明白的
6.完备：MECE原则的思考方式尽量保证对产品功能需求表述的系统完整；
7.具有优先级：产品的功能性需求是有先后主次的，对于一次性规划叫多功能的PRD，应该注明功能性需求的先后主次
最最最重要的：把问题、需求表述清楚！
五、元件库的念叨
虽然现在网上有不少元件库，但是真正实用，适合自己的少之又少，建议每个PM都花点时间花点时间整理一份属于自己的元件库，这样可以提高画图效率、保证视觉的统一，整理元件库的分类可以考虑从常用性、适用性、交互组件、逻辑组件、页面框架等方面去考虑。
六、结语
其实PRD并没有规定的格式，可以根据自己公司、项目阶段等实际需要来写适合自己产品团队的PRD。写文档的目的在于把事情说清楚，且有记录（防止秋后算账），可传阅，多跟研发人员沟通，重要的是让他们了解需求，把问题和想法表述清楚才是王道！
----------------欢迎讨论、交流----------------
需要原型和组件库的童鞋可关注“社稷狮笔记”，回复“原型”，即可获取下载地址！本公众号定期更新互联网产品经理干货，欢迎众汪讨论交流~~~
公众号： 社稷狮笔记
网友评论