产品需求文档(PRD)写作指南

微信扫一扫，分享给好友

关闭

一份好的PRD，能让研发团队快速理解需求、准确实现功能、减少沟通成本。

但大多数PRD要么太简单（研发团队看不懂），要么太复杂（没人愿意看）。

PRD的核心结构

• 背景与目标

• 为什么要做这个功能？
• 解决什么问题？
• 预期达到什么效果？

长度：不超过半页。让研发团队在30秒内理解需求的背景。

• 需求范围

• 本次需求做什么
• 本次需求不做什么

明确边界，防止范围蔓延。

• 用户故事

作为[用户角色]，我希望[功能]，以便[价值]。

示例：作为内容运营，我希望批量导入文章，以便提高效率。

• 功能详述

每个功能的详细描述，包括：

• 页面/模块布局
• 交互逻辑
• 业务规则
• 异常处理

• 数据埋点

需要采集哪些数据？事件名称、触发时机、属性列表。

• 验收标准

功能上线后，如何验证是否达到预期？包括功能验收和数据验收。

写好PRD的五个原则

原则一：以用户视角写，不是以系统视角写

坏的描述：「系统在用户点击按钮后调用API，返回数据后渲染列表。」

好的描述：「用户点击「搜索」后，看到符合条件的商品列表，按相关性排序。」

原则二：用流程图补充文字

复杂的交互流程，用文字描述容易歧义。用流程图或状态图辅助说明。

原则三：明确异常场景

不要只写「正常流程」。明确列出：

• 网络异常时怎么处理？
• 数据为空时显示什么？
• 用户权限不足时如何提示？

原则四：提供参考和示例

如果有竞品参考、设计稿、历史类似功能，提供链接或截图。

原则五：保持更新

PRD不是写完就扔的。需求变更时，及时更新PRD，并通知相关人员。

PRD模板

```

需求名称：XX功能

1. 背景与目标

• 背景：...
• 目标：...

2. 需求范围

• 包含：...
• 不包含：...

3. 用户故事

• ...

4. 功能详述

4.1 XX功能

• 描述：...
• 交互：...
• 规则：...

5. 数据埋点

| 事件 | 触发时机 | 属性 |

6. 验收标准

• ...

```

写在最后

PRD的价值不在于「写得多厚」，而在于「沟通得多清楚」。一份让研发在看完后没有疑问的PRD，才是好PRD。

建议：写完PRD后，找一个不了解背景的研发同事读一遍。如果他看完后能准确复述需求，你的PRD就达标了。