上一篇文章我们讲解了需求分析如何做。本文继续分享需求分析之后，如何写好PRD这个关键文档。

上节讲完怎么做需求分析，那做完需求分析就需要输出产品需求文档：PRD。

产品小白不迷路04：需求分析阶段需要做什么？

那怎么才能写好一份PRD呢？

一、什么是PRD？

PRD，全称Product Requirement Document，即产品需求文档，是产品经理在产品开发过程中编写的一份详细的产品需求说明书。它主要用于指导产品的设计、开发、测试等后续工作，确保产品开发团队对产品的功能、性能、用户体验等方面有清晰的认识和一致的理解。

考古一下，宝洁在二十世纪二三十年代第一次提出了产品经理的概念，并有了产品经理的岗位，第一份PRD推测也诞生于宝洁公司的第一位产品经理手上。

再延伸一下，有PRD之前，应该先有MRD（Market Requirement Document），市场需求文档，用于市场调研，发掘可发展的市场商机。然后是BRD（Business Requirement Document），商业需求文档，类似商业白皮书，用于产品在投入研发之前，由企业高层作为决策评估的重要依据，评估整体的商业目标和价值。

二、PRD的作用是什么？

说到作用，那就要知道PRD一般来说是什么人会看，而这些人为什么会看，一般来说是这几类角色会查看：

• 产品经理：查漏补缺
• 提需求的业务方：了解业务以及调整效果
• 设计师（UI/UE）：了解业务，进行界面设计
• 开发（技术、测试、架构师等）：功能开发说明

所以，PRD的主要作用是作为产品开发的说明书，它详细描述了产品的各项需求，包括功能需求、界面设计、数据处理、操作流程等，以便开发团队能够按照既定的要求进行工作。

此外，PRD还可以作为项目管理的工具，帮助团队跟踪项目进度，及时调整开发计划，确保产品按时交付。

三、PRD的内容

通常每家公司都会有自己的PRD模版来规范需求的输出格式，但都会包含以下内容：

1、文档命名：包括时间、迭代版本、需求名、版本号等，便于版本控制和追踪。如果是外包对接，还可以加上公司名称、机密等级说明。

例如：0203（上线时间/开始时间）迭代1-订单流程优化需求说明文档

2、修订记录：记录文档的修订历史，包括修订章节、修订原因、修订日期、修改人等信息。

修订记录如果是内部自研，可以只写创建文档时间，过程中的修改只要业务、产品、技术达成一致，没必要记录。但如果是外包，则需要详细记录，以便后续验收时追溯。

3、目录：列出文档的主要章节和子章节，方便查阅。这里只要根据编写规范，Word或在线文档均可自动生成目录

4、概述：包括产品背景、场景、目标、Roadmap、风险等内容，概括产品的整体情况。

• 目的是让看文档的人知道产品需求的相关背景以及目的，后续产品功能的调整都需要围绕这个目的为前提或者考虑，不要偏移需求的初衷。
• 这里还可以说明一些非业务需求，可以是对产品的性能、交互体验的约定规范。这样就不需要每个需求都写很细致，提高文档编写的效率。

5、产品设计概述：描述目标客户、需求描述、场景描述、优先级等，明确产品的服务对象和需求点。

• 需求命名：【需求类型】+需求简述，可根据需求类型是新功能还是功能优化或界面优化建立标签，可快速了解需求情况。
• 涉及功能模块：实际运营和开发过程中，会按照功能模块进行维护，所以标注出涉及的功能模块，可快速定位相关业务和开发。
• 需求描述：描述需求，什么人，在什么地方，做什么，得到什么结果
• 优先级：多需求同时开发，需要明确需求的优先级
• 输入/前置条件：相关的需求前置条件，例如：查看购物车需要先登录、查看客户信息需要有相应的角色权限等。
• 需求说明：详细描述产品需求，需要清晰的一条一条列出来，考虑正向和逆向（无数据、异常等）的场景解决方案，描述可用流程图、用例图、状态图、字段说明等辅助说明。
• 涉及产品/端：如果是跨产品开发，标明是什么产品，什么端（PC、APP、小程序、H5等）
• 补充说明：一般是辅助的资料，例如：原型地址、设计稿地址、导入导出文件等
• 原型说明：文字描述总没有图直观，且交互展示也需要原型中表达出来

四、PRD的撰写原则

既然已经清楚了PRD的基本结构是怎样的，那么具体应该怎么去撰写呢，我觉得需要把握住几个原则：

• 符合实际：每个团队合作都需要磨合和配合，大家和跟进实际情况增减PRD中的信息，不要为了写文档而写文档
• 结构化清晰：合理安排文档结构，使内容条理分明，易于理解和查找。
• 详细准确：对每个需求点进行详细描述，包括功能细节、操作步骤、预期效果等。
• 动态更新：随着项目进展，及时更新PRD内容，确保信息的实时性和准确性。

五、总结

PRD的编写应根据团队的实际情况和需求进行调整，避免生搬硬套模板。