如何创建产品需求文档 (PRD)
没有人会喜欢写冗长而又过于详细的产品要求文档。事实证明，也没有人愿意使用这样的文档。
开始使用免费的产品需求模板
优化产品需求、验证用例，并指导团队完成产品发布前与发布后的关键检查工作。
打造出色的产品需要大量的研究和全面的规划。但您要从哪里着手呢？产品经理通常会从 PRD 开始。
什么是 PRD？
A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.
Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.
Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.
用于敏捷工作的 PRD
在敏捷世界，收集要求的过程是怎样的？听起来很棘手，事实也确实如此。但是不用担心。在 Atlassian，我们了解在敏捷环境创建产品要求文件的所有知识。下面是需要牢记的几点：
敏捷要求是产品负责人的完美搭档。不使用敏捷要求的产品负责人会陷入事无巨细全部列出，以提供合适软件的陷阱（然后手指交叉，以祈祷自己没有做错）。
另一方面，敏捷需求的实现还依赖于产品负责人、设计师与开发团队之间对客户达成的共识。这种对目标客户的共识与共情，能释放产品负责人的潜能。
他们可以专注于更高层次的要求，而将实施细节留给完全有能力的开发团队执行，这也是因为双方达成了共识。（繁荣。）
创建有效 PRD 的提示
如果您对达成共识的想法感到兴奋，但不知道要怎样实现，请尝试采用以下技巧：
在进行客户访谈时，安排一位设计和开发团队的成员参加，方便他们直接听取客户的意见，而不必依赖产品负责人的笔记。他们因此也能够有机会在客户心中浮现某个话题时，进行更深入的探究。
团队共同努力创建和使用客户的人物角色。每个团队成员都有独到的视角和见解，并且需要了解人物角色对产品开发的影响。
将工作项分类和待办事项列表梳理也打造为团队协作事项。这些环节是确保所有人达成共识，并理解产品负责人如此安排工作优先级的绝佳机会。
想要试一试？请注册或登录 Confluence >>
创建客户访谈模板以记录您的客户洞察信息。按照我们的教程，开始进行有价值的客户访谈：
利用客户访谈金字塔将信息转化为洞察力
应留意的反模式
在任何工程工作开始之前，整个项目就已经制定了非常详细的规范
甚至工作还没有开始，所有团队就已经完成了彻底的审查，并充分签了字。
设计人员和开发人员不了解要求是什么时候更新的
要求从一开始一直都不会更新（因为每个人都签了字，记得吗？）
产品负责人在没有团队参与的情况下编写需求
好的：您已经与工程师和设计师讨论了一些用户故事。前前后后也召开了多次白板会议，得出的结论是，对于要处理的这一功能，还有几个维度需要考虑。您需要充实所做出的一些假设，更深入地思考怎样融入整体方案，并跟踪您需要回答的所有尚未解决的问题。接下来呢？
PRD 应该包括哪些内容？
编写要求文档时，建议整个团队使用统一的模板，方便所有人跟进并提供反馈。在 Atlassian，我们使用 Confluence 中的产品要求文档模板来创建产品要求。我们发现，以下部分提供的背景信息“恰到好处”，便于了解项目要求及其对用户的影响：
1. 定义项目细节
我们建议在页面顶部包含如下高层次的指导：
参与者：有哪些人参与其中？包括产品负责人、团队、利益相关者
状态：该项目当前处于什么状态？达到目标、存在风险、耽搁、延期等
目标发布：预计何时发货？
2. 团队目标和业务目标直截了当。信息充分，但不乏味。
3. 背景和战略契合我们为什么要这样做？这样与公司总体目标的契合度如何？
4. 假设
列出您可能会做出的技术、业务或用户假设。
5. 用户故事
列出或链接到所涉及的用户故事。还可链接客户访谈，并附上您所看到内容的屏幕截图。提供足够多的细节，以构成一个完整的故事，并包括成功指标。
6. 用户交互和设计
在团队为每个用户故事制定出解决方案后，将设计探索和线框图链接到页面上。
7. 疑问
当团队了解要解决的问题时，他们往往会有疑问。创建“待决定或待研究事项”表格，以跟踪这些项目。
8. 哪些事情还没有做
明确指出您没有做的事情，让团队专注于手头的工作。标记目前不在范围内，但以后可能会考虑的事情。
PRD 示例
下面是我们使用 Confluence 创建并充分完善后的产品需求文档。请记住，没有两个产品需求是完全相同的。使用此示例可了解 PRD 中应包含的不同元素，但不能将其作为不可改变的方法。
精心编写的 PRD 的好处
如果说要从这篇博客中学点什么，建议您着重理解“原因”，而非“内容”，因为原因可帮助您探索最适合您的团队的东西。下面是我们在使用单页仪表板方法时发现的一些优势和挑战：
1. 一个页面，一个来源
保持简单。产品需求文档将成为与特定长篇故事中的一系列问题相关的所有内容的“登陆页面”。将一些内容放在核心位置可节省团队成员访问相关信息的时间，并为他们提供简洁视图。
2. 额外的敏捷性
使用简单的页面进行协作的好处之一（相对于专用的需求管理工具）是，您可以敏捷地处理文档！您不必每次都遵循同样的格式，您可以随意操作，不限时间，一切都可以敏捷处理。您还可以根据需要不断改变。
3. 足够的背景信息和细节
我们常常忘记一个简单的链接有多么强大。我们在产品需求文档中嵌入了很多链接。这有助于抽象出复杂的内容，并根据需要逐步向读者披露信息。所链接的详细资源可能包括：
关于功能的背景、验证或其他背景信息的客户访谈
提出相似想法的其他页面或博客
之前的讨论、技术文档和图表
来自外部来源的产品演示视频或其他相关内容
4. 活生生的故事
一旦故事经过粗略构思并作为工作项输入到 Jira 中后，我们便会将其链接到我们的页面（这时也会非常方便地创建从工作项返回页面的链接）。Confluence 与 Jira 之间的双向同步意味着我们能够直接从需求页面自动查看每个工作项的当前状态。
5. 集体智慧
在 Confluence 中记录产品需求可让不同团队中的其他人轻松作出贡献并提出建议。我曾多次惊讶地发现，来自其他团队的成员在对话中发表了评论，提供了很好的反馈、建议或类似项目的经验教训。这让一个大型组织感觉就像一个小团队。
6. 吸引人的“额外内容”
使用 Visio、Gliffy 或 Balsamiq 等工具制作的图表能更好地向团队传达问题。除此之外，还可以嵌入外部图像、视频和动态内容。
7. 协作！
一切的一切，重中之重是让所有人参与进来。千万不要再自己编写产品要求文档了，一定要让一位开发人员和您一起编写。与团队共享页面并寻求反馈。给出评论、提出问题、鼓励他人贡献自己的想法和创意。这一点对于经常不能面对面讨论项目的分散团队来说尤为重要。
挑战
每种方法都有缺点。下面是我们从客户角度经历和发现的两个主要挑战：
1. 文档可能会过时
当您实施了一个故事，获得了反馈，然后修改了解决方案后，会发生什么？有没有人会带着最终实施的情况返回更新要求页面？对于任何类型的文档来说，这都是一大挑战，因此我们总是要质疑这样的权衡是否值得。跟您的团队聊一聊，遇到这类情况，您会怎么做。
2. 参与度低
“我怎样才能鼓励人们发表评论？”、“我怎样才能鼓励人们在我们的内联网上撰写更多规范和故事？”这是一个很难解决的问题，归根结底要看您的组织是否采用了各种维基技术。这里有很多资源可以为您提供帮助。这里可能还有更深层的文化问题。
现在开始工作！
如果要求很灵活，那么产品负责人可以有更多的时间去了解并跟上市场的步伐。保持信息丰富且简单明了，这样有助于开发团队使用最适合其架构和技术堆栈的任何实现方式。
当项目需求得到合理完善后，我们建议将上面第 5 节中的用户故事与开发团队工作跟踪器中的对应故事进行关联。这样可以让开发过程更加透明：方便查看每项工作的状态，帮助产品负责人以及营销和支持等下游团队做出更明智的决策。
专业提示
请记住，在项目要求的演变过程中，一定要保持敏捷。随着团队开始构建、发布和获取反馈，完全可以更改用户故事。始终要保持较高的质量标准和健康的工程文化，即使这意味着交付较少的功能。