今天梳理下PRD的内容，看完这篇文章，如果还不清晰，直接来找John吧。
不知道大家在写PRD的时候有没有思考这些问题：
- 总觉得PRD是有规范的 —— 其实没有规范，但是需要让团队的小伙伴能看懂。
- 可能你PRD写了几万字，技术只花了10分钟就看完了。剩下的时间都在找你问细节。
- 在产品评审时，你发现写的PRD忽然变得很陌生。
- ……
可能很多小伙伴下载一个所谓的PRD模板，把其中的内容进行替换，最后发现只剩下“产品功能”这部分自己还看得懂。其它地方连自己都不能理解。导致产品要么没有可读性，要么需求不明晰，团队沟通需求成本极高。
与其说是产品经理偷懒行为，不如说压根不清楚PRD，不得其法。接下来John根据自己的经验来聊下PRD文档如何更清晰的阐述。
一、PRD的定位
在John梳理的产品经理工作流中，PRD承接的是产品经理把业务需求梳理成产品需求对接给项目组的其他小伙伴。所以重要性不言而喻。首先你明确两个问题：
- 产品实现的过程中，谁会看PRD？——角色包括：产品伙伴、研发、UI、测试、运营和客服等团队成员。
- PRD是否能清晰的表达这个版本的需求？——这版本需要做什么？用户路径是怎么样的？版本的整个功能架构，对应的原型和逻辑。
产品经理需要清晰的知道PRD最重要的包含哪些内容。才能在评审会上不至于有分歧。
二、PRD的结构
在现阶段一般是敏捷开发、注重的是项目管理和沟通高效。PRD最重要的是适合你的团队配合。但是最基础的PRD结构可以通过如下的脑图来总结：
其中整体呈现出来如下图所示：（全部在Axure呈现出来）
1.产品历史版本规划
主要是说清楚每个版本功能迭代的目的是什么。其中包括编辑的时间、上线版本号、具体的内容、功能架构和用户路径（方便点击跳转）、原型版本号和修订人。如下图展示：
2.PRD阶段
经常有小伙伴问John，PRD是每个版本分开写还是聚合写在一起。其实你会发现，分开写之后，查看对应的文章就很麻烦，且不容易管理。所以John最后就采用这种管理方式。
2.1.功能架构图
首先建议输出功能需求池，说清楚有哪些功能需求。如下图：
然后针对需求池输出对应的功能架构：
输出功能需求池的目的是产品经理更好的存档。功能架构方便项目组的伙伴更好的清晰每个版本所对应的模块是什么？
2.2.用户路径流程图
输出用户路径是为了清晰每个模块之间的跳转关系和路径。做到整体流程无遗漏无缺失。（重点是一定要说清楚）
单一用户多模块操作的泳道图：
多用户多模块操作的泳道图：
2.3.原型
John之前说过，原型是最不重要的，但是它是最基础的。如果你原型都不能保障，那建议先去好好练习基本功吧。
其中仔细看会发现，初始的页面，配套写清楚逻辑，加上交互的点击事件说明。只要会阅读的技术，都能很清晰的看清楚内容。
以上就是极简且清晰的PRD一份。
