产品经理文档之PRD

PRD：产品需求文档，全称是Product Requirement Document，是产品文档中最底层最细致的文档。文档侧重对产品功能和性能的说明，主要是把产品规划与设计中的产品流程，界面，功能等定义向研发、设计、测试等团队做清晰的描述说明。

1、帮助团队存档产品信息

产品实现过程中，有很多的逻辑、算法需求，没有文档的记录，容易在团队变更、交接班的时候出现较大风险。通过产品需求文档记录产品的各种需求与实现方式，能有效降低团队的风险，同时也能提高交接效率。

2、提升内部信息沟通的效率

虽然需求可以口述，但是不代表说一次全员就都能记得，会遇到开发、设计或测试记不清楚的地方，可以直接查看文档。结构明确、表达清晰的文档仍然有不可取代的作用。

3、产品工作有据可查

各方需求理解不一致，或延期产品工作的时候，通过产品需求文档都可以有效的找到问题根源。

研发人员：由于研发人员本身专注于功能的实现与性能，所以他们相对于其他岗位比如运营，时长，设计等，表现相对不太关系，对于产品更多地了解来自于产品经理的产品宣讲。

设计人员：设计人员本身更多的会关注产品的表现形式与原型，所以对PRD的需求是相对较弱的。

还有老板、项目经理、运营、市场、客户、财务……

所以，PRD文档，根据阅读对象，可以用最平铺直叙的话，把产品描述清楚就行。

文字模式 ：Word。时间较为充裕的或岗位责任制分明，有文档要求规范的团队，建议选择Word撰写文档。

原型图模式 ：Axure。追求时间效率灵活性的团队，建议选择Axure撰写文档，原型搭配产品说明，无需切换，只用一个文件就可，方便快捷。

无论哪种方式，都是大同小异，本质上并不影响PRD文档的使用效果。

1、修订记录：版本号、修订日期、修订章节、修订内容、修订人等。

版本号说明，以1.25举例：

版本号（ 1 .25）：重大调整升级，一般是产品结构功能等有调度。

子版本号（1. 2 5）：在原有基础上对局部功能进行了升级或调整。

修正版本号（1.2 5 ）：局部小范围优化与Bug修复，一般是不动功能性的东西。

版本号的命名规则：

归零原则：前一个数字增加一位，后面的数字都归零。

修订记录旅埋的作用：

对修改前后进行比较

有利于维护和管理PRD

记录修订人和修订日期

方便查询，可以只看修订部分，快速查找变更之处

2、名词术语：将一些产品里面不易理解，容易混淆，或者缩写的词汇在开篇进行统一的列表说明，有利于阅读。

全局说明包括：权限说明、授权说明、异常情况、键盘说明等。

权限说明：对角色权限进行划分，例如登录和未登录状态下可访问的功能权限。

授权说明：手机号授权、地理位置授权、相缺镇枯册授权等。

异常情况：加载失败、网络异常等。

键盘说明：数字键盘、字母键盘。

......

1、产品结构：包括产品功能结构图、信息结构图。

2、业务流程图：通过用户行为串联信息结构和产品结构，可以更好的理解产品经理设计的用户行为。

3、功能清单：清单包括功能模块、功能点、功能描述等。

4、功能详情：原型设计、功能说明和用例。

功能详情的表述顺序可以按照功能的逻辑来表述，或按照产品结构来表述，具体可以看个人习惯和团队要求。

用例：用例图和用例说明。用例图表述的是系统的外部参与者与系统之间的关系，是由参与者与用例组成的示意图。

注意：

撰写前要保证思考到位，产品结构本身短期内不会有重大改动。这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况。

文档中用词用语一致，对于同一事物的表述应该一样，避免混用。

非功能性需求是对产品非功能性需求的说明，包括性能需求、技术组件需求、安全性需求、可用性需求、质量需求等。

性能需求：系统满足多用户同时工作，保障同时在线用户五千人，并发 *** 作一千人的使用需求伏洞。

技术组件需求：数据存储及计算使用星环大数据平台等。

安全性需求：涉及外网环境的需保证数据网络架构上保证数据的传输安全、具备良好的跨平台部署能力等。

可用性需求：系统支持IE11并向下兼容，支持Chrome等主流浏览器。

质量需求 ......

上面的文档结构只是PRD的基本结构，并没有成为固定的可以供套用的东西，文章只是一种思路的分享，具体还是要根据自己公司及团队的习惯和达到你的目的为依据来进行调整，切勿生搬硬套。

阅读原文

对产品经理感兴趣的朋友，可以移步“ 行业与市场分析 ”，期待共同交流。

1、BRD:Business Requirements Document,商业需求文档。这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、赢利预测等，通常是给老竖笑祥板们演示的PPT，比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要是获得认可，争取资源。

2、MRD:Market Requirements Document,市场需求文档。获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分那几块，功能的优先级等。实际工作中，PD在这个阶段余搏常见的产出物有产品的Feature List、业务逻辑图等，这是从升雹商业目标到技术实现的关键转化文档。

3、PRD：Product Requirements Document,产品需求文档。PRD是对产品功能的进一步细化，是PD新人写的最多的文档，也就是“需求开发”的过程。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述。

4、FSD：Functional Specifications Document,功能详细说明。比较像常写的用例文档，经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左右中对齐？保留几位小数等，有点像“概要设计”。

产品需求文档，PRD

1、总体说明

1.1修订历史1.2项目概述1.3功能范围1.4用户范围1.5词汇表1.6非功能需求1.7其他说明

2、UC部分

2.1整体说明2.2UC正文

产品经理rp文件要分享给其他人。首先作为产品经理，在脑中拥有清晰的产品原型是基础，但是举孝做如何将原型表达出来确实比较难的一点。制作一款APP，首先我们正衡要想明白每一个页面需要哪些模块，需要如何布局，不同的模块需要实现哪些功能，这些功能组合在一起如何让这款APP变得简洁又好看。AXURE就是将脑子中想法可视化的一款软件。因笔者制作的APP具有商业机密慎旦，故暂不能贴图入帖。

---