如何编写产品需求文档？一个产品需求文档（PRD）是使用传统的项目管理团队中最重要的文件之一。然而，越来越多的敏捷团队开始看到在他们的流程中添加更多计划的价值。
起初，这似乎违反直觉。敏捷就是保持精益和适应用户反馈，对吗？那么为什么要写出一堆在你的下一个冲刺回顾之后会改变的需求呢？下面我们来介绍编写产品需求文档步骤及其相关产品需求文档编写示例内容。
编写产品需求文档（PRD）教程
- 什么是产品需求文档？（它有什么特别之处？）
- 精益、平均的一页纸 PRD 的基本要素
- 如何通过 5 个步骤编写产品需求文档 (PRD)
- 一个（稍长的）PRD 示例：Product Hunt
- 为什么要花时间在珠三角？如何推销你的敏捷团队需要一份一页的产品需求文档
- 掌握敏捷中精致的文档艺术，你的团队会感谢你
尴尬的事实是，70% 的项目由于缺乏需求收集而失败。尽管如此，还是有太多团队认为敏捷是盲目构建的借口。
那么，你如何在长期规划和资源收集的结构与敏捷开发的灵活性和反馈驱动性质之间取得平衡？
进入一页纸 PRD：一个简单、简洁的文档，它让你的团队和利益相关者了解你正在制作的内容，阐明用户故事，并确保你已经彻底考虑了你的产品需求。
如何编写产品需求文档？在这篇博文中，我们将向你介绍如何研究、编写和展示实际有用且有价值的产品需求文档，无论你使用何种软件开发过程。
获取免费模板并像专业人士一样规划你的产品
我们设计了一个易于使用的模板供你免费使用。获取免费模板
什么是产品需求文档？（它有什么特别之处？）
PRD 是描述你将要构建的产品的目的、特性、功能和行为的文档。
虽然工作的陈述或项目计划将挖掘到的细节如何你要建立一个产品，是珠三角地区更侧重于什么是正在取得进展。
大多数人会将其与瀑布（或传统）开发方法相关联，在这种方法中，你可以在开始构建之前创建详细的计划。
然而，敏捷团队正在对项目规划采取一种越来越具有适应性的方法，通过不断地将需求添加到他们的待办事项中并在出现时对其进行优先级排序。但除了在你的产品开发中发挥功能作用之外，一页纸的 PRD 还可以迅速成为你团队的指路明灯。
精益、平均的一页纸 PRD 的基本要素
选择进入你的珠三角的东西是一种平衡行为。
过多的信息会使文档成为敏捷开发的障碍。太少了，它无法提供我们刚刚讨论的那些重要好处。
为了获得最佳结果，你的 PRD 需要包含以下关键元素。
- 产品细节：关于产品创建过程的基本细节是什么？例如，团队中有哪些人？该项目的现状如何？你的发布日期是什么时候？
- 目标：你的团队希望通过此产品版本实现什么目标？它如何符合你的业务目标？
- 背景和假设：你的原因是什么？是什么让你开始研究这个产品？也许你已经确定了市场的新趋势，新的竞争对手已经推出，或者客户访谈揭示了一个新的机会。不管是什么原因，把它和影响你的决定的任何假设一起记录在你的 PRD 中。
- 用户故事：产品将包括哪些功能？写下或链接到你的用户故事，以及澄清这些故事所需的任何相关信息，例如你进行的采访以及你将使用哪些指标来衡量成功。
- 设计和用户交互：你的设计是产品的一个组成部分，应该在你的 PRD 中解决。包括你的功能的最具影响力的线框和模型，并指定用户将如何与这些功能进行交互。
- 要解决的问题：虽然你的 PRD 不应该涵盖你如何解决用户的问题，但你必须知道这些问题是什么。你可能需要提高对这些问题的理解，因此请包括你的任何未解决的问题或你需要进行的任何其他研究。
最后，PRD 还可以包括你没有做的事情。
知道你需要做什么显然是必要的，但清楚你没有做什么也同样重要。
当你确定可能有用的功能（甚至可能在未来版本中实现）但不是当前优先级的功能时，尤其如此。为了防止你的团队分心，请调用这些功能并明确表示他们不会对它们进行处理（至少现在不会）。
如何通过 5 个步骤编写产品需求文档 (PRD)
现在，是时候把它们放在一起了，所以......🎁获取你的 PRD 模板！🎁
产品需求文档编写示例：首先选择你的 PRD 将居住的地方 - 最好是可以轻松更新和访问的地方。这是一个动态文档，将随着你的项目而发展。因此，请确保你使用的是Planio team wiki 之类的协作工具。
Wiki 不仅为你的团队提供知识、文档结构和清晰度，而且通过将所有内容保留在你的项目管理工具中，你可以快速引用特定问题或项目、链接到文档和代码存储库，甚至关注页面以在发生更改时获得通知.
有了合适的工具，让我们通过一个简单的过程来实际编写你的 PRD。
为此，我们将受产品主管 Marty Cagans原始PRD指南的启发，将文档分为四个部分：
- 产品用途
- 特征
- 发布标准
- 日程
编者按：有趣的是，Marty 不再提倡使用 PRD。这不是因为他认为它们无效，而是因为产品经理很容易在它们上花费太多时间而在实际产品上花费的时间不够。通过保持你的 PRD 精益化并专注于基本要素，你仍然可以享受好处，而无需花费过多的时间和资源将其组合在一起。
第 1 步：编写产品需求文档（PRD） - 定义你的目的
涵盖的要素： 产品细节、目标、背景和假设
编写产品需求文档步骤：如果你不知道你的目标是什么，你怎么知道你是否实现了它？
写下这些细节会迫使你具体了解产品的用途以及构建它的原因。作为额外的好处，它还可以突出你所做的任何差距或没有根据的假设。
你的目的应该尽可能明确。如果团队中的任何人不确定或仍有疑问，则说明还不够清楚。如果有任何差距，请不要忽视它们。这将构成你的 PRD 的基础，因此它必须坚如磐石。
以下是一些需要回答的简单问题，以便填写此部分：
- 什么是电梯间距？你会如何用一两句话描述你的目标？是什么使这与目前的情况不同或独特？
- 它是给谁的？考虑你的理想用户以及他们将如何与你的产品互动。如果可能的话，给它们命名并写一个简短的描述。
- 你为什么要建造它？你对市场、用户和你自己公司的目标了解多少，使之成为构建正确的产品？你对这三个类别有什么假设？
不要将你的目的与解决方案混淆。定义你的目的应该有助于你清楚地了解你需要去哪里，并说明你的目的地。它不是如何到达那里的地图。
第 2 步：如何编写产品需求文档？描述你的功能
涵盖的元素：用户故事、设计和交互、解决的问题
用户将如何实际使用你的产品？
通过回答有关拟议结果的一些关键问题，你的 PRD 将在这里进入你的下一个项目。
- 你的产品的核心元素是什么（从用户的角度来看）？你的用户将如何与你的产品互动？是否有他们需要知道的术语？你的核心交互流程是什么？
- 你正在为你的用户解决哪些问题？他们为什么要关心这个？在这里，你可以使用你的用户故事将你的理想用户与其所需的功能和结果联系起来。
- 产品的外观和感觉如何？包括几个关键的实体模型或链接到原型等你的团队，每个人都可以连接什么在珠三角如何应该它结束时的样子。
再次，清晰是必不可少的。你的描述需要足够详细，解释你的用户与产品交互的具体方式（而不是规定一个明确的解决方案）。
这应该建立在你上一步的工作之上，而不是作为一个独立的练习。你描述的功能应该清楚地映射到你在第一步中列出的产品目标。
如果你有一个没有目标的功能，它真的是一个必要的功能吗？如果你有一个没有功能的目标，你怎么能期望你的产品成功？
你的工作是了解和传达依赖关系并收集需求。将需求可追溯性内置到 PRD 中可以帮助你了解你的功能与你的目标的关系，使你的团队能够做出更明智的决策并完全掌握添加或删除这些功能的影响。
第 3 步：产品需求文档编写示例 - 设置发布标准
涵盖的要素：发布目标，你没有做什么
你如何知道你的产品何时可以发布？作为敏捷团队，你习惯于定期发布软件。但我们在这里讨论的只是为你的产品何时准备好进行测试设定目标（而不是你将在sprint 计划期间添加的更多技术部分）。
考虑围绕这五个标准设定目标：
- 功能：发行版中需要包含哪些内容？有哪些不可缺少的基本特征或功能？
- 可用性：核心功能需要有多简单和有效？在这个阶段，用户体验和设计有多重要？
- 可靠性：产品的一致性应该如何？什么程度的失败是可以接受的？
- 性能：最低预期性能是多少？执行所需任务的速度应该有多快？
- 可支持性：什么级别的持续维护和支持是可能的（或现实的）？
需要明确的是，这一步只是关于设定目标。没有提出解决方案。
同样重要的是要清楚你不会做什么。设置发布标准可帮助你了解何时可以删除用户故事或将它们推送到更高版本。
虽然这一步无疑会涉及更多的技术细节，但这仍然与目的地有关，而不是你到达目的地的确切路线。
第 4 步：根据约束而非日期设置时间表
涵盖的要素：时间表、预算和资源限制
PRD 不应该有一个确切的时间表，因为它可以让你对可能因反馈或市场变化而改变的功能或决策负责（这是开发敏捷旨在避免的事情！）
相反，更好的选择是围绕约束构建你的 PRD。在最后一部分中，你写出了产品限制——你正在构建的内容以及可接受的最低发布标准。在本节中，你将写出工作流约束。
时间、预算和资源限制为你提供了一种更准确的方式来向后工作并分配切合实际的 sprint 长度。这里有几个问题可以帮助你澄清你正在处理的工作流限制：
- 你理想的发布日期是什么时候？你想什么时候上市或开始 Beta 测试？这个灵活吗？到多少？
- 你的其他限制是什么？你有预算问题需要考虑吗？其他团队是否依赖于你的版本？你还缺少哪些其他资源？
第 5 步：与利益相关者分享以获得反馈
编写产品需求文档步骤：最后，简短的编写产品需求文档（PRD）是获得利益相关者早期反馈和支持的绝佳机会。
这份文件并不是由一个人写的，然后锁起来就再也看不到了。
虽然你需要与核心团队合作来创建文档，但参与项目的每个人都应该有机会查看它并添加他们的想法。这就是将它像Planio 团队维基一样公开的地方是一个很好的选择！
然而，要求开放式反馈有时可能是一场灾难，尤其是当你与核心团队之外的人打交道时。确保设置上下文并清楚你正在寻找什么样的反馈：
- 说明这份文件是一份指南。让他们知道这是一份关于正在构建什么的指导文件，而不是你将如何到达那里。让他们从用户的角度而不是作为团队的一部分来考虑它。
- 询问你的假设是否正确，或者你是否遗漏了任何关键考虑因素。你是否以正确的假设开始编写 PRD？是否有他们认为你缺少的关键要素？
- 询问额外的限制：利益相关者通常了解你没有的限制和即将做出的业务决策。在你开始之前，他们知道什么会影响这个项目？
自己试试：
获取免费的一页式 PRD 模板试试看！
一个产品需求文档编写示例：Product Hunt
了解 PRD 的好处是一回事，但是当你开始执行这些步骤时，可能会感到困惑。
哪些信息对你的产品至关重要？你应该深入到多少细节？为了保持精简，很容易错过重要信息。同时，PRD 可能会因不必要的细节而迅速变得臃肿，占用团队过多的时间并变得如此庞大，以至于没有人愿意对其进行审查。
如果你正在寻找一个很棒的（虽然稍微长一些）PRD 示例，Product Hunt背后的团队已经分享了他们原始的产品需求文档。
Product Hunt 的 PRD 尤其擅长回答具体问题，比如它是为谁以及为什么要构建它。然后他们深入研究what，涵盖不同的用户故事并包括他们可能看起来的模型。
作为奖励，它们还包括以前的迭代（“下面的旧东西”），以允许团队和利益相关者跟踪围绕产品的想法随着时间的推移是如何变化的。
为什么要花时间在珠三角？如何推销你的敏捷团队需要一份一页的产品需求文档
如何编写产品需求文档？如果做得正确，产品需求文档可以为敏捷团队提供几个显着的优势，所有优势都在一个页面上。
但是，如果你的团队持怀疑态度，以下是他们应该考虑使用一个的几个重要原因：
1. PRD 创造了跨团队的共同理解
创建和发布产品是一项团队工作。但是，即使只有一个团队（或队友）在朝着错误的方向前进，你也会遇到问题。充其量，你将面临延误和沟通问题；在最坏的情况下，缺乏凝聚力可能会使整个项目脱轨。
PRD 以简单简洁的方式回答有关你项目的核心问题。
“你应该能够向任何 5 名团队成员询问产品的总体目的、功能、发布标准和时间表，他们应该给你大致相同的答案。”
通过将所有这些详细信息记录到 PRD 中，你就有了一个参考，团队中的任何人都可以随时查看。使用一页纸，你还可以获得易于浏览的简明描述的额外好处。
2. 编写产品需求文档（PRD）帮助敏捷团队摆脱“产品隧道视野”
技术团队有跳跃的坏习惯，直冲如何，他们将要构建的产品和解决的问题。
这只能理解。当你一生都沉浸在技术细节中时，很容易认为这是你的用户最关心的问题。然而，事实却大不相同。正如硅谷产品集团的Martin Cagan解释的那样：
“一个非常普遍的错误，尤其是在高科技公司中，就是认为如果你喜欢你的产品，那么你的客户也会喜欢。”
PRD 迫使你从用户的角度思考你的产品，而不是沉迷于你要选择的特定技术或处于最前沿。
虽然 PRD 是实现此目的的强大方法，但它并不是你可以使用的唯一工具。事实上，亚马逊将这一点融入到他们的产品发现过程中。
在构建任何功能之前，产品经理首先需要“向后工作”并撰写内部新闻稿，宣布成品。这有助于他们将注意力集中在客户问题上，而不是花哨的新技术上。
虽然你可能不想每次开始新项目时都写新闻稿，但 PRD 可以通过从用户的角度关注产品需要完成什么来实现相同的结果。
3. PRD 帮助你在敏捷世界中收集需求
如何编写产品需求文档？最后，也是最明显的，PRD 可以帮助敏捷团队弥合高级产品需求和开发团队的实施细节之间的差距。
在敏捷中收集需求很棘手，甚至可能会适得其反。然而，与其在需求收集上花费大量时间和精力，精益 PRD 可以提供两全其美的效果。
掌握敏捷中精致的文档艺术，你的团队会感谢你
当你运行一个不断变化和适应的敏捷团队时，编写产品需求文档（PRD）可能会让人觉得浪费时间。但是，一定程度的计划可以使你免于在情况发生变化时陷入混乱。
精益 PRD 是敏捷和传统团队的指导文件。用它来绘制出你理想的释放，想想你的产品从用户的角度来看，和家庭在什么你正在构建。希望以上的编写产品需求文档步骤可以帮助到你，如有问题，请在下方评论。
