「产品需求文档」是一个强大的产品管理工具，被众多敏捷团队推荐，并被一些行业中的大公司使用。

它有助于使团队保持一致，促进长期合作，并向团队成员传达优先必做事项，以完成工作。

如果你还没有开始制作，我们强烈建议你将它加入文档库里。如果你需要一个框架来制定你的产品需求文档，那你来对啦！

这篇文章将介绍「产品需求文档」是什么、有什么作用、文档内应该包括哪些内容等等。

什么是产品需求文档？

产品需求文档 (PRD) 概述了开发产品或功能的人员、内容、原因、时间和方式。

产品开发过程中，相关团队和领导者在对人员安排、项目范围、项目时间表等其他方面有疑问时可以通过它来确认。这份动态文档使使开发团队、产品经理和其他技术团队在产品从概念到上市的过程中保持一致。

因为产品需求文档是为每个从事产品开发过程的人提供参考的文档，所以它应该是一个高层次的概述，并着重于回答有关该产品或项目的基础问题。

产品需求文档有什么好处？

以下是产品需求文档对产品创建过程产生积极影响的一些主要原因：

1. PRD 在项目前和项目中给每个人以清晰的认知

在开始开发前明确项目的依赖关系、障碍、风险和假设，使过程更加顺利。

对于项目中涉及的多个利益相关者也是如此。拥有产品需求文档可以为每个人提供一些参考。这一切都是为了让火车保持在轨道上。

2. PRD 设定了合理的预期

PRD不仅告诉我们产品或功能需要工程团队或开发团队做什么，它还允许有时间和空间来让他们确定在产品发布时不会进行的功能。

识别风险和项目依赖关系衡量成功的关键部分，对吗？

这就是为什么你必须弄清楚你能做什么来最小化风险，同时对附有关键依赖关系的任务进行优先排序。如果操作正确，它将把这些信息放在一个地方，这样产品经理或相关人员就可以设定合理的时间表，并使其保持在正轨上。

3. PRD 建立更好的团队关系

没有人喜欢错过发布日期，特别是产品经理。

PRD真正有助于使开发过程成为团队共同的努力。一个有据可查的流程不仅给出了总体业务目标，而且还应该概述谁负责什么，这样核心团队才能取得成功。

当团队可以看到每个人在做什么时，信任和尊重就更容易建立。更不用说，当其他团队的工作分配不足或过多时，一个强大完备的规划过程会给人们留下谈论功能规范的空间。

妙记多的需求管理模板示例

产品需求文档中应该包含哪些内容？

PRD的关键是要在全面和简洁之间取得平衡。太多的细节会让人更难阅读、吸收和记住。细节过少会导致错误、不正确的假设、未回答的问题以及整体成功指标的中断。

与许多其他策略文件一样，最简单的方法是通过回答“谁、什么、什么时候、为什么和怎么做”这些标准问题来进行分解。使用大量链接来提供更深入的信息，而不至于使主要文件变得杂乱无章。

谁负责以及在做什么？

你的文件应该有一个明确的领导层（特别是对于那些有战略问题的人），并清楚地说明哪些团队（或个人）参与其中以及承担什么责任。

这不是在团队层面上进行细化的地方（记住：这份文件是高级别的，适用于整个组织），但它应该告诉团队 A 他们是否需要联系团队 B 或人员 C 来解决问题 X。

例如，如果设计团队 B 负责设计产品，则文档中的一栏应指定“设计师”或“设计团队”，并应标记该团队的负责人（或负责设计的人员）。这使得有疑问或需要与设计对话的人可以轻松找到对应的人。

你正在做什么？

这是产品需求文档的核心内容，它应该被非常明显地放在前面和中心。这里还有一些其他的问题需要回答，包括：

• 你对该产品的目标是什么？
• 这一轮开发中包括（或不包括）哪些功能？

回答最后一个问题可以确保团队不会陷入不必要的困境，或优先考虑你计划在以后的版本中发布的功能。

产品的推出时间，大家什么时候才能真正知道？

在某些情况下，在你知道该产品或功能在优先级列表中的哪个位置之前，你就已经在制定产品需求稳单了。在这种情况下，可能将要回答“何时”的问题。

如果你有时间表，请在文件中加入冲刺、目标发布日期，或项目其它重要里程碑等内容。没有这些时间线？不用担心。在时间表、关键要素、发布标准或实施细节没有完全确定的情况下开发PRD是很正常的。

你的文档还应该回答，什么时候大家会知道这个项目已经准备好了，可以发布了？ 换句话说： 你在制定的产品策略中的发布标准是什么？

通常，发布标准包括功能、可用性、可靠性、性能、安全性以及可能需要的持续维护。

「为什么」很重要？

在任何项目中，对于客户和员工来说，最大的动力就是 为什么。这将如何对客户、企业或内部团队产生积极的影响？我们为什么首先要做这个？

这个问题的答案通常以简短的背景或战略陈述的形式出现在PRD中。例如，一家公司推出一个移动视频app的桌面版，可能会有这样的声明：

在一年前推出App X后，我们收到了大约20%的用户的请求，询问我们是否计划推出桌面版。经过两次后续调查，65%的用户表示他们会使用桌面版，70%的低参与度用户表示他们会在桌面版上有更多的参与。

声明需要简明扼要，并包括支持性研究。无论你使用什么研究或调查，请确保有细节支持，并在PDR中添加指向其他文档的支持链接，让人们可以深入了解用户（或研究人员）的解释。

妙记多的「产品需求文档」模板

如何开发产品？

现在，我们开始讨论细节问题了。PRD 的核心是 团队将如何开发该产品。 这个问题在 PRD 中通过用户故事来回答——从客户或目标用户的角度对软件功能进行的非正式描述。

在我们的例子中，一个移动视频app增加了一个桌面应用，用户故事通常可以按 必须拥有 和 应该拥有的 问题进行排序。应该使用客户访谈和建议以及内部（有时是外部）分析。

你可能希望在 PRD 中回答的其他 与“我们将如何做”相关的问题：

• 该产品的假设是什么？
• 有什么约束条件？
• 依赖关系是什么？
• 我们在哪里可以找到系统和其他要求？
• 用户体验/设计是什么样的？

请记住，只有一个团队或一个人需要的任何详细信息都可以保存在其他地方，并从这个核心文件中链接出来——让那些只需要更高级别视图的人不觉得杂乱。

制作「产品需求文档」的 5 个步骤

第 1 步：确定参与人员、内容、时间、原因和方式

在创建文档之前，你需要回答上述问题。谁负责？你在做什么内容？为什么这有关系？…需要特别注意项目背后的原因——业务案例、客户需求、团队需求。

收集这些答案通常意味着 跨团队协作， 以过去的项目作为模板 （或做什么 或 不做什么），以及最重要的是了解业务优先级和客户需求。这也可能意味着合并以前的文档，包括业务战略文档和 MRD。

深入挖掘： PRD 和 MRD 有什么区别？ MRD（营销需求文档）通常出现在 PRD 之前，描述了新的或升级的产品或功能的商业案例和市场需求。该文档是为市场和领导层准备的，而PRD是为产品团队本身准备的。

第 2 步：制作用户故事

你的用户需要用这个产品做什么？大多数 PRD 都包含一个用户故事列表，其中包含优先级、附加文档的链接以及任何相关注释。

制作这些的最佳方法是通过用户研究。一个常见的错误是认为我们自己就是我们的用户——我们的需求和对产品的了解与使用产品的人完全一直。在推进之前，请确保验证这些假设。

与任何文档一样，在详尽性和简洁性之间找到平衡点很重要。一些 PRD 具有三个用户故事，有些有 10 个。如果这部分开始感觉太长，你有必要与你的团队核实一下，以确保他们能够在分配的时间内完成所有事情。

并且不要忘记排列优先级。当故事列表很长时，这会变得非常重要。

第 3 步：协作和编辑

一旦你记录了产品计划，就该征求相关参与者的意见了。确保每个参与的团队都有机会标记缺失的依赖关系、不正确的假设、缺失的信息等等。

在你更广泛地分享你的文档前，利用这些反馈来润色你的文档。

妙记多支持划线评论并在页面内部进行实时沟通

第 4 步：完成文档并分享

广泛分享你的文档，并确保人们可以在项目期间轻松查阅它。相关参与者应及早并经常参与。这样来确保你的文档反映了真实的用户需求、集合了整个团队相关者的专业意见。

该文档应指定需要完成的工作，但允许团队使用他们的专业意见来定义 如何完成它。

妙记多支持邀请相关成员查看、编辑、评论，并允许拷贝页面到成员个人空间

第 5 步：保持最新状态

对于很多公司来说，这是缺失的部分： 确保你的文档能反映发生的变化。

团队 A 是否发现了新的依赖项？团队 B 被拉到一个更优先的项目上，影响了你的时间表？领导层是否发生变动？新用户的需求在测试期间是否变得明显？

这些事情的发生时（而且它们经常发生！），需要有人负责保持文档的更新并反映最新的信息、链接等。不要跳过这一步！

开始使用 妙记多 Mojidoc 的产品需求文档模板

准备好开始你自己的PRD了吗？我们为此准备了一个（免费）的模板。使用妙记多的产品需求模板来开发、起草、协作和分享你的产品计划，为任何需要它的人提供参考。

使用 妙记多 的产品需求模板来规划、调整和汇总所有参与者所需知道的一切。