3.11. PRD¶
商业需求文档(BRD)和市场需求文档(MRD)主要是前期项目调研的产物，而研发和测试主要是以产品需求文档(PRD)为蓝本来开展工作的
3.11.1. 定义 1¶
PRD是产品汪思考后的产品方案呈现载体，主要用于需求开发过程中沟通研发、测试、设计、运营等，也会用于存档便于查看和回溯。
目的是让开发人员知道如何按照产品经理的思路为需求撰写代码，让UI 设计人员知道他们需要输出哪些UI 设计稿，让测试人员知道测试用例中需要包含哪些测试点。PRD 的撰写侧重点是需求描述、需求逻辑、需求原型。PRD 是所有产品经理都会接触到的，也是产品经理平时写得最多的文档，所以大家一定要好好研究。
- 内容主要包含整体说明、用例文档、产品Demo等，对产品功能具体描述；FSD功能详细说明，比较像用例文档，经常包含在PRD中，涉及很多技术内容，产品界面、业务逻辑等。与此同时，硬件系统的设计、数据库设计、表结构设计等工作也开始由架构师、系统分析师编写了。
3.11.2. 需求 到 PRD¶
梳理PRD怎么写，无法脱离于项目流程单独思考，需要带入流程。
需求拟定：产品原型、交互说明、业务流、数据流、资金流
战略层：产品目的，用户需求，经营者和用户想从产品中得到什么
范围层：规格功能，某个功能是否应该成为该产品的功能之一，各种功能的组合方式
结构层：流程结构，用户如何达到某个页面，并且他们昨晚流程之后能去哪
框架层：页面布局，按钮，表格这边和文本区域的位置，是否达到这些元素的最大效果。
表现层：视觉设计，产品图片，文字的表现样式，交互形式。 4
很多初级PM刚开始写竞品分析，上来就直接从结构层开始分析，之后写框架层、表现层，这就很难再顾及战略层和范围层了。然而想要对一个产品的设计认知深刻，就要从战略层开始思考，才能有效理解和指导下面的层级。这就是一个中高级PM应有的认知和思路——你的责任和你的视野是挂钩的。 5
3.11.2.1. 战略层——用户需求&产品目标¶
将需求背景、用户需求写在开头，后续撰写都要围绕这个核心，相当于定了方向，也可以指引阅读者更好更快的了解需求。 不管是定量目标还是定性目标，都要落实到PRD上，这是整个项目团队工作的预期成果。
比如36氪的目标用户就是创业者、投资人、互联网职场人和学生，创业者要找36氪报道项目，投资人要通过看36氪找可以投资的好项目，互联网职场人和学生要看36氪开拓视野，了解圈内大事，以补充自己的知识储备量。 另外注意，考虑用户时，如果是多边平台型产品，就不仅要考虑 C 端，还要顾及 B 端用户，比如广告主、机构负责人等等。
给公司带来多大价值：分金钱收益和流量收益，结合时间维度分别说明短期收益和长期收益。比如3个月内聚集用户，半年内展开招商，一年内有持续现金流等等。 注意：在描述收益时，尽量「量化」收益数值，尤其是需要和公司历史收益对比，和同行业其他家收益对比，和行业规模对比，才能做到具备一定说服力。 6
3.11.2.2. 范围层——功能规格&内容需求¶
战略层中明确了用户需求和产品目标后，范围层就要确定做哪些功能、提供什么内容来实现产品目标，可以将各个功能点以及它们的优先级用脑图或excel画出来（工具随意），相当于把整个需求分拆成各个模块，便于理解和评估工作。
3.11.2.3. 结构层——交互设计&信息架构¶
范围层把需求分拆之后，结构层再把各个部分用流程图或思维脑图连接起来，让阅读者能抽象出产品的使用流程或信息架构。
偏交易、工具的产品需求可以使用流程图，偏内容的产品需求可以使用思维脑图，此处放一个点餐交易的局部流程图，仅做示例参考。
3.11.2.4. 框架层——界面设计&导航设计¶
结构层将需求分拆模块，框架层梳理整体流程，相信这时候PRD读者已经对需求有了清晰的思路，框架层主要对每个模块或页面的逻辑、布局做详细阐述。
3.11.2.5. 表现层——视觉设计¶
表现层主要包括但不限于视觉、听觉、触觉等内容，需要做一些高保真的设计，建议与UED、用户体验部门联合产出，这里不做过多展开。
3.11.3. 过程¶
在写需求文档前，面对我们的用户——相关协同人员，产品经理需要去了解他们。了解他们的工作方式、工作习惯、工作态度、工作认知、工作能力等与工作相关的内容，同时，对他们与人相处的方式、生活习惯、兴趣爱好等等的了解，有助于产品经理更全面的了解，从而建立更加立体的用户画像。
在输出判断结果时会更准确，写需求文档会更有侧重点——哪些是他们需要知道的，哪些是他们需要特别详细表述的，哪些是需要特殊标注的，哪些是省略表述即可的。 7 保证无遗漏、无歧义。把层次关系梳理出现，再用图表或流程图表现。拆分组块业务逻辑，梳理业务上下游。实际工作中，很可能你写的东西，开发压根懒得看，上司也压根不看，但是一定要有，等和开发撕逼的时候，拿出来，反正你写了，他不看，是他的责任！ 8
3.11.4. 作用¶
Fig. 3.11.2 协同人员与其需求[^40]¶
对于开发而言：开发可以通过需求文档知道产品的各个功能点，以及设计到的交互逻辑。
对于测试而言：测试通过需求文档来编写测试用例。
对于设计师而言：可以通过需求文档来确定交互细节。
对于运营而言：可以通过需求文档了解我们的战略及规范，了解到产品的亮点，从而制定相应的运营策略。
对于项目经理而言：可以根据需求文档来拆分相应的工作包。
对于产品经理自身而言：人的大脑容量是有限的，我们不能保证在产品迭代的后期还能清楚的知道每一个功能点的细节，所以需求文档就是一个很好的“复习”工具。特别是版本需求讨论、需求评审会、内容交叉、Bug处理、版本迭代时。
另外，当出现人员异动（人员项目变更、人员离职等）时，新接手的产品经理，可以通过需求文档来快速的全方面的了解产品。 9
3.11.5. 表现形式¶
产品需求文档的表现形式有很多种，常见的有 Word、图片和交互原型这三种形式，文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。虽然产品需求文档没有标准的规范，但是有两项是必不可少的，那就是文件标识和修改记录。文档在撰写过程中，我们可以自行不断的修改完善，但是如果正式发布或交给团队其他成员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录，这样可以方便大家查看和了解改动的内容。关于文件标识和修改记录，格式都大同小异。
3.11.6. 目录： 10¶
产品背景
版本历史
名词解释
产品综述
用户故事
需求详述
评审记录
其他问题描述
3.11.6.1. 产品背景¶
3.11.6.1.1. 背景概述¶
含义解释：背景概述是用简单的语言大概概括一下大的背景，让人知道我们本次要讲的内容大概是什么。
描述正文：官网为用户提供产品试用，目前，完整的试用流程如下：
用户在官网进行注册，填写申请试用表单。商务（运营）在管理后台，对用户的申请进行授权操作（允许/拒绝）。
注释：这样的背景描述，是将云官网，本次的产品需求，用业务流程串联起来，从前端到后端。从业务流程出发，将业务串联起来，这是一种非常好的方式。用一个事件，将涉及的所有产品功能都串联起来，让本次讨论有主线。
一般来说，这段话的作用在于让人阅读后明白我们为什么要花时间做这件事，以及明白了这件事的意义所在。重点在WHY，关于WHY的重要性，大家可以看一个演讲叫做How great leaders inspire action。
既然是完善和优化，那么产品经理就需要向运营、向研发证明，为什么这样的修改，相较于原来的流程，更好。
Example: http://www.woshipm.com/pd/4167090.html
TODO：芒果金融APP PRD：https://t.qidianla.com/1156795.html
3.11.6.1.2. 文档介绍 11¶
版本控制是管理需求的一个重要方面，而作为每一个公布的需求文档的版本有着两个重要的部分：一是关于版本状态；二是修订历史。
为了尽量减少困惑、冲突、误传，文档的版本必须被统一确定，且在版本介绍中具备版本号、作者、日期、版本状态，在修订历史中记录文档版本、修订时间、变更人姓名、修订属性以及版本内容描述。
3.11.6.1.3. 开文介绍¶
开文介绍中主要是说明该文档的V1.0版本是关于哪一个产品、IOS还是Android（可以移动端用一个文档说明）、当前版本、V1.0版本作者、完成日期以及文档状态。
3.11.6.2. 版本历史¶
我这里面以QQ举例，例如QQ第一版本主要支持点对点的文字信息通讯功能。 12
这个时候我们叫做V1.0.0；
第二个版本你又增加文件传输功能，这个时候叫做V1.1.0；
有一天你发现一个bug，需要紧急上线一个版本，这个时候命名为V1.1.1
3.11.6.3. 需求说明 13¶
字段说明：字段长度、字符类型、取值范围
如手机字段的最大长度为11位，若少于或者多余会怎么显示？
如类型则指能输入什么？数字？字母？汉字？
如取值范围指如果有下拉的选项菜单，则必须进行说明会出现哪些下拉选项。
排序规则：数据是按照时间排序，还是按照某个字段排序或者其他规则排序。
状态说明：初始状态、常见状态、特殊状态。例如一个界面的初始选项状态，是可选还是不可选，是打开还是关闭，未登录和登录区别等等。
操作说明：按钮的反馈，点击前，点击后，点击中，不可点击
反馈内容：用户交互后的反馈，如弹窗提示，页面跳转，加载过程等
数据来源：只要页面上有数据，就要告诉开发这个数据是怎么来的。
例如 （手机号输入框，下拉选项框，列表数据排序，按钮状态，交互反馈信息，数据来源）
一个注册手机的输入框，他的最大输入长度是11位，字符类型是数字。
填写地区的下拉选项框的取值范围，有多少个省市等等。
如果是一个列表数据，那么这些数据的排序规则是什么？按照时间还是按照首字母或类型排序？
一个按钮的状态，例如点赞按钮，初始是灰色的，点击后变成了红色。
还有一些页面交互的反馈内容，如弹窗提示，页面条状，加载过程等等。
只要是页面上的数据，就必须告诉开发，这些数据怎么来的。
3.11.6.4. 名词解释¶
专业词汇
3.11.6.5. 其他问题描述¶
TODO： 4.5 法务说明
凡涉及隐私权、知识产权、专利权、商标、服务条款（TOS）、版权、合同责任、客户沟通等方面需要
标明来源。（法务应提供协助）
4.6 性能需求
技术提供
4.7 安全需求
技术提供
4.8 兼容需求
技术提供
4.9 时间显示说明
举例：
六 附录
6.1 名词解释
6.2 原型
6.3 其它
3.11.6.5.2. 修订历史¶
修订历史是一个版本的可追溯源，因为一般来说，各个公司都是处于铁打的产品需求文档流水的产品经理的状态，利用它，就可以对产品的整个发展历程有一个清晰的认识，便于把握产品发展路线。
新建默认为相应模块的首次使用，对于文档的修改以及增加的地方可加入超链接，同时在增加与修改的具体地方进行颜色标示或者其他标志来进行区分，方便其他人员进行查询。
3.11.7. AI产品¶
二者的差异主要集中在需求内容的部分。而需求内容这方面的差异又因PM角色的不同而有所不同。
机器学习是满足用户需求的一种方式，而不是需求本身。
3.11.7.1. 数据需求 15¶
数据是机器学习的输入和输出。
3.11.7.1.1. 数据要求¶
需要什么数据？ 答：找出产品或特定功能所需要的数据
哪些特征是已知的，将是有用的？等等。 答：已知属性称为特征
这些特征可用吗？如果不可用，获取成本是多少？ 答：要预测的值称为标签。按可用性、有无困难和成本来排定优先级。
3.11.7.1.2. 数据采集策略¶
上述数据来自哪里？答：想到所有对这个任务有帮助，而且你也能拿得到的数据。如，可从公共记录中获得房子的年龄、用公共地图数据计算离最近的杂货店的距离。
现有数据是否存在质量问题？答：注意因为不同格式的特征值或语义，如，单位。
你认为需要多少数据？答：尽量多、迁移、预算、限定。
3.11.7.1.3. 隐私与安全¶
数据存储和处理的方式是否安全？ 答：最好咨询专家。
你有收集/使用数据的权限吗？ 答：考虑什么是应做的，什么是不该做的。
从用户的角度来看，新功能或产品的好处是否能超过他们在提供数据时的担忧？ 答：用户得到什么好处。
3.11.8. 测试完整性 16¶
现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？
当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。
3.11.9. 管理产品 17¶
解决所有PRD中存在问题，如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。
如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。
记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。
confluence：这个不多说了，非常好用的一款产品PRD在线编辑软件。 18
3.11.10. COD评分表方法¶
3.11.11. 信息架构¶
组织系统、标签系统、导航系统、搜索系统
3.11.12. 好的产品需求文档 19¶
页面（数字标示需要进行说明的按钮、图片、热区、说明文案等）
需求场景（简单的人物故事说明）
需求对应功能
业务说明（业务的流程）
页面说明
前置后置流程
补充说明（有其他需要说明的进行补充）
3.11.13. 完善评审流程和项目管理 20¶
产品评审：对PRD进行阅读，然后评论，关键是提问。
整体流程如下：
创建日程，将参加评审同学添加至日程，并编辑会议摘要，说明评审内容
日程开始后，通过日程快速创建会议群，群内发出评审PRD，大家在各自电脑打开阅读文档编辑评论
一次PRD评审控制在45分钟，PRD作者组织评审，一般会15分钟阅读文档，过程中PRD作者通过文字回答评论提问，阅读完成后文档底部点赞代表阅读完成，多数人点赞后开始对评论答疑讨论，并记录todo
拉齐需求，对战略目标，对同组同仁