如何创建产品需求文档 (PRD)

摘要：产品要求文档 (PRD) 定义了特定产品的要求，包括产品用途、特性、功能和性能。该文档可为业务和技术团队提供指导，帮助他们打造、发布或推销产品。

打造出色的产品需要大量的研究和全面的规划。但是您要从哪里着手呢？产品经理一般是从产品需求文档 (PRD) 着手。

产品要求文档定义了您要打造的产品，概述了产品用途、特性、功能和性能。

接下来，您需要向利益相关者（业务和技术团队）分享产品要求文档（并征求他们的意见），他们可帮助您打造、发布或推销产品。

一旦所有利益相关者达成一致，产品要求文档便将发挥指南针的作用，针对产品用途提供明确的方向，同时确保业务和技术团队达成共识。

在敏捷世界，收集要求的过程是怎样的？听起来很棘手，事实也确实如此。但是不用担心。在 Atlassian，我们了解在敏捷环境创建产品要求文件的所有知识。下面是需要牢记的几点：

敏捷要求是产品负责人的完美搭档。不使用敏捷要求的产品负责人会陷入事无巨细全部列出，以提供合适软件的陷阱（然后手指交叉，以祈祷自己没有做错）。此外，敏捷需求还取决于产品负责人、设计师和开发团队就客户达成的共识。对目标客户的共识和同理心可释放产品负责人的潜能。他们可以专注于更高层次的要求，而将实施细节留给完全有能力的开发团队执行，这也是因为双方达成了共识。（繁荣。）

如果您对达成共识的想法感到兴奋，但不知道要怎样实现，请尝试采用以下技巧：

• 在进行客户访谈时，安排一位设计和开发团队的成员参加，方便他们直接听取客户的意见，而不必依赖产品负责人的笔记。他们因此也能够有机会在客户心中浮现某个话题时，进行更深入的探究。
• 团队共同努力创建和使用客户的人物角色。每个团队成员都有独到的视角和见解，并且需要了解人物角色对产品开发的影响。
• 团队共同练习分类事务和梳理待办事项。这些都是很好的机会，可以确保所有人步调一致，并了解产品负责人在工作优先级排列方面的依据。

想要试一试？请注册或登录 Confluence >>

创建客户访谈模板以记录您的客户洞察信息。按照我们的教程，开始进行有价值的客户访谈：

• 创建富有洞察力的客户访谈页面
• 利用客户访谈金字塔将信息转化为洞察力

好的：您已经与工程师和设计师讨论了一些用户故事。前前后后也召开了多次白板会议，得出的结论是，对于要处理的这一功能，还有几个维度需要考虑。您需要充实所做出的一些假设，更深入地思考怎样融入整体方案，并跟踪您需要回答的所有尚未解决的问题。接下来呢？

编写要求文档时，建议整个团队使用统一的模板，方便所有人跟进并提供反馈。在 Atlassian，我们使用 Confluence 中的产品要求文档模板来创建产品要求。我们发现，以下部分提供的背景信息“恰到好处”，便于了解项目要求及其对用户的影响：

1. 定义项目细节
建议按如下所示在页面顶部添加高级别指导：

• 参与者：有哪些人参与其中？包括产品负责人、团队、利益相关者
• 状态：该项目当前处于什么状态？达到目标、存在风险、耽搁、延期等
• 目标发布：预计何时发货？

2. 团队目标和业务目标
直截了当。信息充分，但不乏味。

3. 背景和战略契合
我们为什么要这样做？这样与公司总体目标的契合度如何？

4. 假设
列出您可能会做出的技术、业务或用户假设。

5. 用户故事
列出或链接所涉及的用户故事。还可链接客户访谈，并附上您所看到内容的屏幕截图。提供充分的细节来整合完整的故事，并添加成功指标。

6. 用户交互和设计
团队为每个用户故事景充实解决方案后，在页面中链接设计探索和线框图。

7. 疑问
团队了解了要解决的问题后，经常会有疑问。创建“待决定或待研究事项”表，以跟踪这些项目。

8. 哪些事情还没有做
清楚地指出哪些事情还没有做，让团队专注于手头工作。标记当前不需要做，但稍后可能需要考虑的事情。

下面是我们使用 Confluence 创建并充分完善后的产品要求文档。请记住，世界上不存在两份完全一样的产品要求。本示例仅供参考，方便您了解产品要求文档中应该包含的几个不同元素，但并非只能这样编制。

如果说要从这篇博客中学点什么，建议您着重理解“原因”，而非“内容”，因为原因可帮助您探索最适合您的团队的东西。下面是我们在使用单页仪表板方法时发现的一些优势和挑战：

1. 单页，单来源
保持简单。产品要求文档将成为与特定战略举措中问题集相关的所有内容的“登录页面”。将一些内容放在核心位置可节省团队成员访问相关信息的时间，并为他们提供简洁视图。

2. 额外的敏捷性
使用简单的一页（而非专用的要求管理工具）展开协作的一个巨大优势在于，您可以非常敏捷地处理文档！您不必每次都遵循同样的格式，您可以随意操作，不限时间，一切都可以敏捷处理。您还可以按需分解和变更。

3. 恰到好处的背景信息和细节
我们常常忘记一个简单的链接可以多么强大。我们在产品要求文档中嵌入了很多链接。这样有助于降低复杂性，并根据需要逐步向读者披露信息。所链接的详细资源可以包括：

• 关于功能的背景、验证或其他背景信息的客户访谈
• 提出相似想法的其他页面或博客
• 之前的讨论、技术文档和图表
• 来自外部来源的产品演示视频或其他相关内容

4. 真实的故事
我看到很多客户也这样做。一旦故事经过粗略思考并作为事务输入到 Jira 中后，我们便会将其链接到我们的页面（这时也会非常方便地创建从事务返回页面的链接）。Confluence 与 Jira 之间的双向同步意味着在要求页面可自动显示每个事务的当前状态。

5. 集体智慧
通过从 Confluence 中获取产品要求，来自不同团队的其他人员也可以轻松贡献自己的力量和提供建议。出乎意料的是，我经常会发现来自其他团队的人员加入对话，发表评论，提供不错的反馈、建议或从类似项目中吸取的经验教训。这样一来，即使是大型组织也让人感觉像个小团队一样。

6. 引入“附加配置”
使用 Visio、Gliffy 或 Balsamiq 等工具制作的图表可以更好地将问题传达给团队。除此之外，还可以嵌入外部图像、视频和动态内容。

7. 协作！
一切的一切，重中之重是让所有人参与进来。千万不要再自己编写产品要求文档了，一定要让一位开发人员和您一起编写。与团队共享页面并寻求反馈。给出评论、提出问题、鼓励他人贡献自己的想法和创意。这一点对于经常不能面对面讨论项目的分散团队来说尤为重要。

每种方法都有缺点。下面是我们从客户角度经历和发现的两个主要挑战：

1. 文档可能会过时
当您实施了一个故事，获得了反馈，然后修改了解决方案后，会发生什么？有没有人会带着最终实施的情况返回更新要求页面？对于任何类型的文档来说，这都是一大挑战，而且我们也需要去质疑这样的权衡是否值得。跟您的团队聊一聊，遇到这类情况，您会怎么做。

2. 参与度低
“我可以做些什么来鼓励大家发表评论？”，“我可以怎样鼓励大家在我们的内联网上撰写更多细节和故事？”。这是一个很难解决的问题，它归结于组织中的各种 wiki 采用技术。这里有很多资源可以为您提供帮助。这里可能还有更深层的文化问题。

如果要求很灵活，那么产品负责人可以有更多的时间去了解并跟上市场的步伐。保持信息丰富且简单明了，这样有助于开发团队使用最适合其架构和技术堆栈的任何实现方式。

项目要求得到合理完善后，我们建议将上面第 5 节中的用户故事链接到开发团队事务跟踪程序中的对应故事。这样可以让开发过程更加透明，方便轻松查看每项工作的状态，产品负责人以及营销和支持等下游团队也因此可以做出更明智的决策。

请记住，在项目要求的演变过程中，一定要保持敏捷。随着团队开始构建、发布和获取反馈，完全可以更改用户故事。始终要保持高质量标准和健康的工程文化，即使这意味着交付的功能数量会减少也没关系。