PRD到底该怎么写？更全面的文档范例来了
副标题[/!--empirenews.page--]
2015年，我写了一篇梳理PRD的文章《PRD到底该怎么写？》，获得3.5万次阅读，423次收藏。至今已过去5年，在这5年里，我一直从事产品产品相关的工作，也经历过一次完整的创业，对PRD又有了一些新的思考。 这篇文章是《PRD怎么写》的升级版，弥补了之前文章的不足，对怎么写PRD，描述得更具体、更全面，是我思考的沉淀，也希望对大家有一定帮助。 01 你是否遇到过这样的问题？
如果遇到以上一个或多个问题，那么你可能需要反思，自己写PRD的思路是不是有问题？写PRD是产品经理非常重要的基本功，写好PRD，可以提高团队效率，减少无效的沟通。 02 什么是PRD？PRD是Product Requirement Document的简称，其中文翻译为：产品需求文档。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。 PRD的主要使用对象有：研发、测试、交互设计师及其他业务人员。
PRD是项目启动之前，必须经过评审达成共识的最重要文档。 产品经理的PRD，就像建筑设计师的设计图纸，是设计和思考的文档化呈现。 《用户体验要素》作者在书中有一句很经典的话：“文档不能解决问题，但定义可以”，PRD就是要定义需求。 03 动手之前，先思考这几个问题1. 解决什么问题？解决用户什么问题？发现问题比解决方案更重要。给公司能否带来收益？相关干系人的需求是什么？是不是老板说这样做的？是不是“他们”说这样做的？他们是谁？真正的问题是他们说的那样吗？ 产品经理正确的设计思路如下：
这叫RTPA设计框架，是一种逆向思维假设分析，我们要使用这样一种思考技巧：假设初始需求都是错误的，即问题并不存在，你需要重新发现问题。 不要需求方一提需求，就开始着手设计，多问几个为什么并着手调查，以了解真正的问题。 下面是一次完整的设计思路示例：
2. 怎么衡量？不同的干系人，通过什么指标去衡量问题是否已解决？有没有埋点？有没有业务数据？谁来运营？ 3. 需要多少资源？为了实现这个解决方案，需要多少资源、多少人？能大致评估吗? 4. 会不会太复杂？这个解决方案会不会太复杂？复杂是产品的坟墓。有没有性价比更高的解决方案？会不会影响现有的业务？会不会影响历史数据？ 5. 有风险吗？这个方案会有风险吗?有没有违法？相关政策是什么？尤其是金融、游戏领域，国家监管比较严，有可能上不了应用市场，有可能三方服务商不会提供服务。 6. 有创新吗？有更创新的解决方案吗?竞品怎么做的，有没有调研3个以上的竞品方案。 7. 用户怎么说？需求真的是提交人说的那样吗?有亲身体验过场景吗？有跟用户面对面交流吗？熟悉相关领域的基本知识吗？有看不懂的名词吗？ 动手写文档或做设计方案之前，一定要问问自己以上几个问题，想清楚了在动手，任何一个问题没想清楚，都不要进行下一步。 04 写PRD的基本步骤搭框架、定流程、扣细节，这是从一名产品前辈那了解到的产品设计流程，写PRD，也可以按照这个思路。 1. 搭框架首先遍历出所有用户角色，再针对每个角色，提供相应的系统/功能，然后按照某种维度进行结构划分。这个步骤完成后，就可以输出产品的系统架构图及系统的功能结构图。
产品架构图，出自《电商产品设计全攻略》
更细化的功能结构图 产品由一个个功能组成，功能是逻辑结构，一个完整的功能具备输入、处理、输出三大特性。从大到小的划分是：系统>功能模块>功能，用户+功能组成了用例，用例是PRD文档里描述占比70%以上的内容，所以合理的功能结构，是写好PRD的前提。 2. 定流程每个产品都有一个核心业务流程，这个核心业务流程涉及多个角色，这个步骤就是把各个角色和功能联系起来。通过核心业务流程，阅读者可以了解产品全貌，对产品有个宏观的认识。 此外，每个系统也有各自的核心业务流程，全业务流程+子系统业务流程，可以概括产品的业务逻辑。 这个步骤输出产品核心业务流程图，子系统核心业务流程图，活动图，状态机图，与外部系统交互可能还有时序图。 3. 扣细节这一步的核心的画原型和功能设计，通过原型表达产品的界面和交互。功能设计主要是从输入处理输出三个方面去考虑，用户执行输入指令后，系统会进行逻辑处理，然后输出结果。此外，还要考虑功能涉及到哪些数据，表结构怎样设计，这些会涉及大量细节，PRD大部分内容，都是在描述这些细节。 步骤1和步骤2没有严格的顺序，也可以先梳理业务流程，再根据流程中的具体场景梳理出实际功能或系统结构。 05 文档的组成部分1. 修订记录记录每次文档更新的时间、作者、修订内容，便于追溯历史变动； 2. 全局说明（编辑：源码网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
