首先，我想说，题主是一个不严肃的人（严肃脸），所以每次干个啥事之前我都喜欢唠唠嗑，说说废话，沟通沟通感情，曾经以为自己将会成为一个幻想中的产品经理那般大展身手，作为非计算机专业出身的应届生，后来才发现自己一直了解的都是业务产品经理牛逼的一面，并没有全面的看透产品经理这一职位。
但事实却是，产品经理，这个岗位在行业内没有明确的定义，所以其工作内容也是非常的广泛，SO，小白们，作为过来人告诉你（认真脸），不要以为你以为的产品经理就是你以为的那样（哈哈哈，绕口令来一发）
回归主题，题主就这么懵逼的成为了研发产品经理（好东西不会啊，55555····专业术语看不懂啊，5555···），不过我们始终要积极的相信，每一段经历都有它存在的价值，也必定会在未来的某一个时刻发挥其作用，所以，咱们还是脚踏实地的一步一步学习吧
在第一节中提到了研发产品经理最常接触的文档——PRD和原型，今天这篇文章就着重分享一些关于PRD文档的总结
一、PRD文档的三大核心作用
1、传达产品开发需求
2、保证各部门沟通有理有据
3、产品质量控制有具体标准
二、PRD文档的必备要素
1、命名、编号和时间戳
PRD的命名和编号很关键，因为每个产品都是经过若干迭代才完成,有时还会经过多人合作，所以命名和编号可以帮助我们知道该文档是哪个版本，到了哪个阶段
时间戳有助于文档修改时，多次传递中，我们区分文档是否是最新
示例：XX产品V1.0PRD_20160623_2006，意为在2016年6月23日20:06分修改的XX产品1.0版
2、PRD文档结构
2.1修订记录
PRD文档从创建到最终定稿，需要经过研发的评审，以及业务方的确定，所以在这个过程中经常会有一些改动，所以我们需要明确的记录下每一次的改动，以便清晰的了解整个需求的管理过程。
示例：
其中，版本号命名说明：V1.0.0
完整的版本号定义分三项<主版本号><次版本号><修订版本号>
主版本号——功能模块有大变动，比如增加多个模块或整体架构发生改变
次版本号——局部的变动
修订版本号——小部分的改动，或者BUG修复
2.2目录
目录用来了解文档结构，直接在文档中生成即可
2.3概要
需求背景：了解需求的起因，重要程度，面临的问题是什么。
需求范围：简要说明需求包括哪些部分，涉及关联系统、关联产品或者接口。
需求风险：完成需求可能遇到的风险和约束，包括产品风险，业务风险，运营风险以及技术风险。
需求来源：说明需求的来源，来源的负责人或者团队，业务方是谁，以便以后查看联系。
2.4功能需求
功能简要说明：介绍功能的用途
场景描述：说明该功能在哪些场景下会使用
业务规则：比如在京东的结算页京券和东券不可同时使用，这些业务规则可以说明，有助于测试、研发了解需求规则
界面原型：涉及页面交互过程，页面原型有助于研发，测试，设计理解
异常情况：网络异常，数据异常，功能异常以及产品的边界值等异常情况说明
2.5数据需求
我们做了什么功能，最终有什么效果，可以通过数据来体现，数据有助于更好的做出产品决策。
2.6性能
页面加载时间、数据缓存时间，功能响应速度等说明，便于研发对性能的优化。
