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