产品需求文档模板：产品需求文档包括哪些内容？编写PRD的5个步骤

对于使用传统项目管理的团队来说，产品需求文档 (PRD)是最重要的文档之一。然而，越来越多的敏捷团队开始意识到在流程中增加更多规划的价值。

乍一看，这似乎违反直觉。敏捷就是保持精益并适应用户反馈，对吧？那么，为什么要费心写出一堆在下一次冲刺回顾后会发生变化的需求呢？

令人尴尬的事实是，70% 的项目失败是因为缺乏需求收集。然而尽管如此，太多团队认为敏捷只是盲目建设的借口。那么，如何平衡长期规划和资源聚集的结构与敏捷开发的灵活性和反馈驱动性质呢？

输入一页纸的 PRD：一份简单、简洁的文档，为您的团队和利益相关者提供有关您正在制作的内容的愿景，阐明用户故事，并确保您已经彻底考虑过产品需求。

在这篇文章中，我们将向您介绍如何研究、编写和呈现一份真正有用且有价值的产品需求文档，无论您使用什么样的软件开发流程。

什么是产品需求文档？

产品需求文档（PRD）是一种描述您即将构建的产品的用途、特性、功能和行为的文档。虽然工作说明或项目计划会深入探讨如何构建产品的具体细节，但 PRD 更侧重于正在制造的产品。

大多数人会将其与瀑布（或传统）开发方法联系起来，在这种方法中，你需要在开始构建之前创建一个详细的计划。

然而，敏捷团队正在采取一种越来越适应项目规划的方法，通过不断将需求添加到他们的待办事项中，并在需求出现时对其进行优先排序。但除了在产品开发中发挥功能性作用之外，一页纸的 PRD 还可以迅速成为团队的指路明灯。

如何通过5个步骤编写产品需求文档

首先选择 PRD 的存放位置——最好是可以轻松更新和访问的位置。这是一个动态文档，将随您的项目一起发展。wiki 不仅可以为您的团队提供知识和文档结构以及清晰度，而且通过将所有内容保存在您的项目管理工具中，您可以快速引用特定问题或项目、链接到文档和代码存储库，甚至可以关注页面以在发生更改时收到通知。

第一步：明确你的目的

涵盖的要素： 产品特性、目标、背景和假设。如果你不知道你的目标是什么，你怎么知道你是否已经实现了它？

写下这些细节会迫使你明确产品的目标用户以及你开发它的原因。作为额外的好处，它还可以凸显你所做的任何缺陷或不切实际的假设。

产品需求文档包括哪些内容

你的目标应该尽可能清晰。如果团队中有人不确定或仍有疑问，那么它就不够清晰。如果有任何差距，不要忽视它们。这将构成你的 PRD 的基础，因此它必须坚如磐石。

为了填写此部分，请回答以下几个简单问题：

• 电梯游说是什么？您会如何用一两句话描述您的目标？与目前的情况相比，您的目标有何不同或独特之处？

• 它适合谁？考虑一下您的理想用户以及他们将如何与您的产品互动。如果可能的话，请说出他们的名字并写一个简短的描述。

• 你为什么要开发它？你对市场、用户和你自己公司的目标了解多少，从而决定开发这个产品是否合适？你对这三个类别做了哪些假设？

不要将你的目的与解决方案混淆。明确你的目的应该能帮助你清楚地了解你需要去哪里，明确你的目的地。它不是一张如何到达那里的地图。

第 2 步：描述您的功能

涵盖的元素：用户故事、设计和交互、解决的问题。用户实际上将如何使用您的产品？在这里，您的 PRD 将通过回答有关拟议结果的一些关键问题来深入了解您的下一个项目。

你的产品的核心元素是什么（从用户的角度来看）？你的用户将如何与你的产品互动？他们需要知道哪些术语？你的核心互动流程是什么？您正在为用户解决哪些问题？他们为什么要关心这个问题？在这里，您可以使用用户故事将理想用户与他们期望的功能和结果联系起来。

产品的外观和感觉会是什么样的？包括一些关键的模型或原型链接，以便团队中的每个人都可以将 PRD 中的内容与完成后的外观联系起来。

再次强调，清晰度至关重要。您的描述需要足够详细，解释用户与产品交互的具体方式（无需规定明确的解决方案）。这应该以您上一步的工作为基础，而不是一个独立的练习。您描述的功能应该与您在第一步中列出的产品目标清晰对应。

如果你有一个功能却没有目标，那么它真的是必需的功能吗？如果你有一个目标却没有功能，你怎么能指望你的产品会成功呢？

您的工作是了解和传达依赖关系并收集需求。在 PRD 中内置需求可追溯性可以帮助您了解功能与目标之间的关系，从而使您的团队能够做出更明智的决策并充分掌握添加或削减这些功能的影响。

产品需求文档包括哪些内容

步骤 3：设置发布标准

涵盖的元素：发布目标、你没有做的事情。您如何知道您的产品何时可以发布？作为敏捷团队，您习惯于定期发布软件。但我们在这里谈论的只是为您的产品何时准备好进行测试设定目标，而不是在冲刺规划期间添加的更多技术部分。

考虑围绕以下五个标准设定目标：

功能：发布版本需要包含哪些内容？哪些必不可少的特性或功能不能缺少？

可用性：核心功能需要有多简单和有效？UX和设计在这个阶段有多重要？

可靠性：产品的一致性如何？什么程度的故障是可以接受的？

性能：最低预期性能是多少？执行所需任务的速度应该有多快？

可支持性：哪些级别的持续维护和支持是可能的（或现实的）？

要明确的是，这一步只是设定目标，而不是提出解决方案。同样重要的是明确你不打算做什么。设置发布标准可以帮助你知道何时可以放弃用户故事或将其推迟到以后的版本。

虽然这一步无疑会涉及更多的技术细节，但这仍然与目的地有关，而不是到达目的地所遵循的确切路线。

步骤 4：根据限制条件而非日期设定时间表

涵盖的要素：时间表、预算和资源限制。PRD 不应该有确切的时间表，因为它可能会让您对由于反馈或市场变化而可能改变的功能或决策负责，这是 Agile 开发的目的，以避免这种情况！

相反，更好的选择是围绕约束条件构建 PRD。在上一节中，您写出了产品约束条件——您正在构建的内容和最低可接受发布标准。在这一节中，您将写出工作流程约束条件。

时间、预算和资源限制可让您更准确地进行逆向工作并分配切合实际的冲刺长度。以下几个问题可帮助您明确所采用的工作流程限制：

您理想的发布日期是什么时候？您希望何时上市或开始 Beta 测试？这个时间灵活吗？灵活程度如何？

您还有哪些其他限制？您是否需要考虑预算问题？其他团队是否依赖您的发布？您还缺少哪些其他资源？

产品需求文档包括哪些内容

步骤 5：与利益相关者分享反馈

最后，简短的 PRD 是获得利益相关者的早期反馈和认可的好机会。这份文件不应该由一个人撰写然后锁起来不再被看到。虽然您需要与核心团队合作创建文档，但参与项目的每个人都应该有机会审阅文档并发表自己的想法。

然而，要求开放式反馈有时可能会带来灾难，尤其是当你与核心团队以外的人打交道时。确保设定背景并明确你正在寻找什么样的反馈：

解释一下这份文档是一份指南。让他们知道这是一份指导文档，用于指导正在构建的内容，而不是如何实现目标。要求他们从用户的角度而不是团队的角度来思考。

问问你的假设是否正确，或者是否遗漏了某些关键考虑因素。你在编写 PRD 时是否做出了正确的假设？他们认为你遗漏了哪些关键要素？

询问其他限制条件：利益相关者通常了解您不知道的限制条件和即将做出的业务决策。在您开始之前，他们知道哪些可能影响此项目的信息？

为什么要花时间在PRD上？如何说服敏捷团队需要一页纸的产品需求文档

如果操作正确，产品需求文档可以为敏捷团队提供多项显著的优势，而且所有内容都在一页纸上。但如果您的团队持怀疑态度，以下是他们应该考虑使用这种方法的几个主要原因：

1. PRD在团队间建立共识

创造和发布产品需要团队共同努力。但是，即使只有一个团队（或队友）朝着错误的方向前进，您也会遇到问题。最好的情况是，您会面临延误和沟通问题；最坏的情况是，缺乏凝聚力可能会使整个项目脱轨。

PRD以简单、简洁的方式回答了有关您的项目的核心问题。您应该能够向任何 5 名团队成员询问产品的总体目的、功能、发布标准和时间表，他们应该会给您大致相同的答案。

通过将所有这些详细信息放入 PRD，您的团队中的任何成员都可以随时查看参考。使用一页纸，您还可以获得简洁的描述，这些描述很容易浏览。

2. PRD 帮助敏捷团队摆脱“产品隧道视野”

技术团队有一个坏习惯，就是直接进入如何构建产品和解决问题的讨论。这是可以理解的。当你把一生都投入到技术细节中时，很容易认为这就是用户最关心的事情。然而，事实却大不相同。一个非常常见的错误，尤其是在高科技公司，就是认为如果你喜欢你的产品，那么你的客户也会喜欢。

PRD不会强迫你纠结于选择什么具体技术或者处于前沿技术，而是迫使你从用户的角度思考你的产品。虽然PRD是一种强大的方法，但它并不是您唯一可以使用的工具。事实上，亚马逊将其融入到他们的产品发现流程中。

产品需求文档包括哪些内容

在开发任何功能之前，产品经理首先需要“逆向思考”并撰写一份内部新闻稿来宣布成品。这有助于他们将注意力集中在客户问题上，而不是花哨的新技术上。

虽然您可能不想每次开始新项目时都撰写新闻稿，但 PRD 可以通过让您从用户的角度关注产品需要完成的任务来实现相同的结果。

3. PRD 可帮助你在敏捷世界中收集需求

最后，最明显的是，PRD 可帮助敏捷团队弥合高级产品需求与开发团队的实施细节之间的差距。在 Agile 中，收集需求非常棘手，甚至可能适得其反。但是，精益的 PRD 可以兼顾两方面的优点，而不是花费大量时间和精力收集需求。

总结

掌握敏捷中精细的文档编写艺术，你的团队会感谢你。当您管理一支不断变化和适应的敏捷团队时，文档可能感觉是在浪费时间。但是，一定程度的规划可以避免您在事情发生变化时陷入混乱。

精益产品需求文档是敏捷团队和传统团队的指导文档。使用它来规划您的理想版本，从用户的角度考虑您的产品，并专注于您正在构建的内容。