都有吧资源网 如何创建完美的产品需求文档
关于客户如何描述他们想要的产品和最终交付的产品之间的误解，有一个有趣的模因。
第一张图片展示了客户所描述的内容（一个简单的木制秋千挂在两根树枝之间）并通过各种迭代（沙发秋千的图像描绘了“业务顾问如何描述它”特别贴切）直到最后一张图片。
这张照片显示，实际交付的是一个悬挂在一根树枝上的轮胎秋千——与客户想要的有所不同。
当然，我们都嘲笑这个模因，但这很有趣，因为它听起来很真实。
您如何非常清楚新产品的关键要素？答案是产品需求文档 (PRD)。
在本文中，我们将深入探讨 PRD 是什么、使用 PRD 的好处、PRD 和 MRD 之间的区别，甚至引入模板 PRD 以帮助您开始创建自己的 PRD。
什么是产品需求文档 (PRD)？
简而言之，产品需求文档详细说明了特定产品版本中必须包含的特性和功能。对于参与设计和开发特定产品的所有团队来说，这是一个至关重要的参考点。
传统上用于瀑布项目环境（产品开发过程是连续的），它也可用于敏捷产品管理。
可以根据 PRD 中捕获的信息创建其他几个文档。工程部门可能会创建一份技术要求文档，详细说明产品的系统要求。
业务分析师可以创建功能需求文档，详细说明用户与系统交互时会发生什么，包括显示产品设计的线框图。
用户体验 (UX) 设计人员可能会创建一个用户界面需求文档来解释产品的外观和感觉。
什么时候应该使用产品需求文档？
在产品开发过程开始时创建产品需求文档至关重要。一旦企业确定需要该产品，就应该开发 PRD，共享发布所需的确切功能。
PRD和MRD有什么区别？
市场需求文件 (MRD) 详细说明了产品的市场机会或客户需求。它对于支持产品开发的商业案例至关重要，应该在 PRD 之前创建。
市场需求文档中的示例目录，在确定产品的商业案例时应在 PRD 之前创建。
MRD 通常包含目标市场的定义，并提供产品成功所需满足的客户需求的优先列表。然后可以使用它来塑造 PRD 中描述的核心能力列表。
MRD 通常还会建议产品发布的时间框架，以便在适当的情况下利用首先进入市场的定位。
编写 PRD 有什么好处？
花时间编写综合 PRD 有几个好处。让我们来看看其中的几个：
1. 它让所有利益相关者都在同一页面上
对于参与产品开发的许多利益相关者来说，一个完善的 PRD 是一个单一的事实来源。它清楚地详细说明了将要交付的内容、所做的任何假设、验收标准以及发布的时间表。
PRD 不是静态文件；如果客户或市场需求发生变化，它可以在整个产品开发过程中更新。确保所有相关人员都能看到它，确保团队拥有完成工作所需的最新和相关信息。
PRD 应在客户初次签署后与所有利益相关者共享，并在整个开发周期中保持可访问性，以供根据需要参考。使用产品需求软件平台，团队可以轻松地就需求达成一致并确定优先级，制定 PRD，并在整个开发过程中进行有效沟通。
2. 明确超出范围的内容
详细说明不会开发的内容与将开发的内容一样重要。许多 PRD 包含一个“超出范围”部分，其中列出了不会在该版本中开发的任何特性或功能。
澄清超出范围的内容对于帮助开发人员掌握时间和预算非常重要。频繁的范围变更是项目失败的主要原因之一。有时，与耗时更长、成本更高的镀金解决方案相比，满足客户需求的更适度的功能是一种明智的权衡。
3. 它促进团队之间的协作
产品需求文档不是在孤岛中创建的。至少，无论如何都不是好东西。创建有效的 PRD 需要多个团队之间的合作和沟通。
业务和营销团队通过探索市场和客户需求以及获得领导支持和资金来确保潜在产品的可行性。
业务分析和用户体验团队围绕可用性和功能需求提供意见。工程团队提供系统知识，以确保技术基础设施到位以支持产品。
跨职能领域的协作——以及偶尔的妥协——确保了一致性，并使 PRD 成为所有团队的有用中心参考点。
4.它将客户的观点置于产品的核心
很明显，我们应该在开发产品时考虑到客户。
但是（正如我们最喜欢的模因所示），有时，在所有其他声音中，很容易忘记我们实际上是为谁设计的：
PRD 使用来自 MRD 的输入来创建可能对用户有价值的核心特性和功能的列表。客户研究和市场分析构成了 MRD 的支柱，并确保最终用户得到充分代表。
如果客户是业务利益相关者，PRD 会明确详细说明他们应该期望收到的产品及其开发时间表。详细的验收标准阐明了成功发布所需的功能、可用性、可靠性、可支持性和性能水平。
产品需求文档应该包含什么？
让我们快速了解一下 PRD 应该包含的内容。
文档元数据
PRD 是一份活文件，可能会发生变化。适当的元数据可帮助您适当地跟踪和存储文档。
产品目标
清晰的问题陈述，准确地分享开发产品应该帮助企业实现的目标，让每个人都专注于总体目标。
客户研究
在本节中，添加可能影响产品开发过程的任何有用的客户或市场研究。可以包含指向 MRD 的链接。
特征
可以说是 PRD 中最关键的部分，使用此部分列出您将在发布中提供的所有商定的产品功能、特性和功能。在敏捷开发中，这部分可能包括用户故事，您还可能包括 UX 设计说明。
负范围
确保还详细说明版本中不包含的内容。其中一些元素可能会被视为潜在的未来增强功能。
系统和环境要求
使用您的工程团队的意见，在此处详细说明任何系统和环境要求。
假设、约束和依赖
列出开发产品的任何假设总是值得的。您还可以列出可能阻碍进展的任何潜在障碍以及发布成功所依赖的任何内容。
发布标准
本节描述了产品被认为可以发布的特定验收标准。
这些通常分为五类：
- 功能 – 是否已达到功能的最低要求？
- 可用性——产品是否易于使用？
- 可靠性——它可靠吗？例如，它是否在系统故障后恢复？
- 性能——它是否满足性能基准，例如加载速度？
- 可支持性——普通用户系统是否有效地支持它？
成功指标
牢记您的产品目标，您可以在此处定义可让您确定产品是否成功的指标。例如，这可能包括用户与特定产品功能交互的频率。产品分析软件可以帮助您监控用户交互。
时间线
毫不奇怪，这是您详细说明目标发布日期的地方。为不断变化的需求留出一定的灵活性，但不要增加太多的脂肪，因为你会让自己面临范围蔓延的风险。
什么是产品需求文档的示例？
有时使用视觉效果更容易理解文档中需要包含的内容，因此这里有一个完整的 PRD 示例。
产品需求文档的最佳实践
希望我们已经明确了 PRD 应该包含的内容，所以让我们深入研究一些将其组合在一起的最佳实践。
- 获得利益相关者的意见。最好的 PRD 是根据所有关键利益相关者的意见创建的。创建一长串关键功能只是为了让工程师解释它不支持是没有意义的。尽早让其他团队参与会带来清晰性，并能够标记假设、约束和依赖关系。
- 根据需要进行迭代。PRD 是一份活的文件。不断变化的客户或市场需求可能意味着可能需要增加、重新确定优先级或完全取消产品功能。时间线可能需要压缩以确保首先进入市场的地位，如果假设没有实现，则可能需要延长时间线。
- 使用版本控制。虽然根据需要审查和修改 PRD 很重要，但产品经理始终可以参考最初同意的内容也很重要。使用版本控制并确保适当的访问级别意味着始终记录历史上同意的内容、更改的内容以及原因。
- 保持可见。PRD 不是在项目计划会议后扔进办公桌抽屉的一次性文件。正如我们所讨论的，您的 PRD 充当了所有从事产品工作的团队的参考点，因此保持可见性至关重要。
确保它存储在中央某个地方，以便任何需要深入了解并澄清某些事情的人都可以根据需要这样做。确保任何外部利益相关者都可以获得一份副本，包括原始文档和任何修改后的版本。
创建 PRD 的步骤是什么？
即使我们已经分享了所有信息，但将您的第一个 PRD 放在一起可能会让人望而生畏。不用担心; 我们有你！这是我们创建坚如磐石的 PRD 的六步清单。此外，我们甚至提供了一个模板来帮助您捕获所有正确的信息。
第一步：明确问题
在做任何其他事情之前，重要的是你要清楚你要解决的问题。这将准确影响您在产品中包含的功能以及您优先发布的功能。
业务需求文档应包含详细说明面临的问题以及产品应如何解决该问题的需求说明。在起草 PRD 之前，审查 BRD 并明确业务对产品的需求是很重要的。
第 2 步：审查市场和用户研究
在构建 PRD 之前审查 MRD 也很重要。MRD 将包含一个客户需求列表，这些需求应该塑造产品的商定功能。
它还将包含对于对功能需求感兴趣的 UX 设计团队和业务分析团队可能很重要的洞察力。
MRD 中的信息还可能通过提供有关如何通过加快开发创造市场优势的信息来影响发布时间表。时间线限制可能会影响同意发布的特性和功能。
第 3 步：让职能利益相关者参与进来
正如我们所提到的，最好的 PRD 是协作开发的。召开跨职能会议，从业务的不同领域征求意见，以告知您的需求文档。
对于利益相关者来说，这是一个很好的机会来提出任何假设，提出对风险或约束的担忧，并注意可能影响产品开发过程的任何依赖关系。
第 4 步：起草 PRD
使用跨职能会议期间收集的信息以及来自 BRD 和 MRD 的输入，产品经理现在可以起草 PRD。
他们需要确保将客户需求有效地转化为产品特性和功能，设置发布标准和成功指标，并制定适当的时间表。
起草 PRD 后，确保与利益相关者共享并要求其审查。根据收到的任何反馈迭代 PRD。
第 5 步：安全签核
PRD 完成后，请确保它已由客户签署。对于内部项目，这可能是项目发起人或高级领导团队。这有助于确保业务一致性和对产品开发过程的支持。
接受发布标准至关重要，因此在开发过程结束时，不会对产品在功能、可用性和性能方面的确切功能产生误解。
第 6 步：分享和交流
签署 PRD 后，分享 PRD 的存储位置，并传达产品开发过程中访问、查看和更改 PRD 的过程。
最终确定的 PRD 应用作整个项目的参考点，并且可以在需求发生变化时进行更新。但是，应该始终有一种方法来确定最初同意的内容，并且所做的任何更改都应该有详细的记录并附有更改的原因。
产品需求文档模板
总结一下，这里有一个 PRD 模板，您可以使用它来立即开始起草您的第一个产品需求文档。
确保您对其进行自定义以适应您的项目需求，并根据需要添加和删除部分以提供清晰性。
产品需求文档模板
立即明确您的产品需求
如果您忠实地阅读了上述信息，那么您就可以创建出色的产品需求文档了。
虽然前期可能需要一点时间，但这样做的好处是值得的，我们的示例模板应该可以帮助您入门。
1. 本站资源来源于站长个人积累和互联网，对DUB会员免费分享，如有侵权请邮件联系站长处理
2. 本站官方微信号：mzm645597829，公众号：产品经理逛世界
3. 标价为平台服务费、辛苦费而并非当前资源本身价值，请知释
4. 有任何疑问，可以点击右侧边栏的联系QQ315991578进行咨询
都有吧资源网 » 如何创建完美的产品需求文档
