产品需求文档（PRD）被誉为产品经理的最好朋友。它像指南针、地图和GPS一样，帮助指导您的产品走向发布。如果您给予PRD应有的重视，它将成为您值得信赖的助手！
PRD是一份动态的文档，开发团队中的每个人在开发过程中都会对其进行贡献和参考。
尽管PRD在技术上可以通过任何形式维护，其中就包括Word、电子表格或数据库，但使用像 PingCode 这样的需求管理解决方案则为我们提供了节省时间的功能。比如一个标准化的模板可以确保参与产品开发的每个人都能轻松阐述标准化的PRD，并与团队其他成员“在同一认知层面上”。
所以本文我们将介绍：
- 什么是产品需求文档（PRD）
- PRD的主要组成部分
- 编写PRD的步骤
- 编写PRD时最常遇到的挑战或问题
- 什么是好的PRD模板
- 产品需求文档与利益相关者需求文档的区别是什么
- 好的产品需求文档模板有哪些特点
- 什么是好的敏捷需求文档的例子
- 模板如何适应数据为中心的产品开发
最后，我们将提供如何为您的团队构建PRD模板的信息，以及在需求管理平台上维护PRD等。
一、什么是产品需求文档 (PRD)？
产品需求文档定义了：
- 待开发产品的目的和价值主张
- 产品的功能和功能（即，需求）
- 产品发布的目标和时间线
PRD与MRD（营销需求文档）不同。MRD是由营销部门编写，旨在挖掘市场的需求和期望，主要从市场的角度来定义产品的功能性和非功能性需求。MRD先于PRD创建。
二、产品需求文档的主要组成部分
产品需求文档主要由以下四个部分组成：
1.目标
- 产品要解决什么问题？
- 预期用户群体是谁？
- 产品如何有助于实现公司的战略目标和规划？
2.功能特性
- 需求（定义每个功能）
- 背景和理由（为什么需要这些功能）
3.发布标准（应覆盖以下五个方面）
- 功能性——产品发布所需的最低功能
- 可用性——如何确保产品易于使用
- 稳定性——如何证明系统的稳定性和可靠性
- 性能——产品需要达到的性能基准
- 可支持性——如何确保公司能够对产品提供支持
3.时间线
- 预期的发布时间窗口
- 项目里程碑
- 发布依赖——已知的可能影响发布的因素（除发布标准之外）
三、撰写PRD的流程
第一步：做好准备工作
要创建一个伟大的新产品，你需要对该产品要解决的问题有深入的理解。获得这种理解的唯一途径就是做一些准备工作。
研究你的客户，和他们交谈，发现他们需要你为他们解决的确切问题是什么。为什么这对他们来说很重要？这个问题让他们付出了什么代价？
研究你的竞争对手。研究他们对问题的解决方案。从你从客户那里学到的信息，确定你的竞争对手在解决问题方面的优势和劣势。你如何能更好地满足需求？
咨询市场部、销售部和你的技术专家，任何对问题有洞察力的人。
评估你团队的能力，他们要如何装备来解决问题？他们熟悉或对哪些可能有助于解决问题的技术感兴趣？
研究可用的技术，对于解决问题，这些技术的优点和缺点是什么？
所有这些准备工作的目的是为了让你自己准备好领导你的产品开发团队。当你知道你在谈论什么，你会显示出自信。这将激发你的团队的信心，并使你们所有人准备好面对前方的挑战。
第二步：定义产品的目的
利用第1步中获得的信息，你要在本步骤和接下来两个步骤中，完成PRD内容的第一部分内容。
第二步需要建立一个清晰、简洁的产品价值主张，以简明扼要地传达产品将满足的需求，并说明产品如何与公司的总体目标和产品战略保持一致。将这一价值主张精炼为一分钟内可以背诵的“电梯演讲”。
这也将帮助团队在设计和实施产品过程中提供权衡参考。它将向所有人明确，成功实施产品将带来什么。
第三步：明确产品原则
为产品制定一套原则，以指导开发团队的工作。比如，对于医疗设备来说，其原则可能包括：
- 安全性至上
- 高度稳定、可靠
- 使用简便直观
你可能会发现，定义产品的原则会让你重新考虑并精简你的价值主张。或者你可能会发现你的原则就是从价值主张练习中得出的。无论哪种方式，你的产品原则将作为指南针，帮助你的团队在接下来的两步中定义用户任务和产品特性。
第四步：构建用户画像、目标和任务
一旦产品的用途得以明确，接下来我们需要确定产品的目标用户群。我们要了解产品的用户群是谁、他们使用产品的目标以及他们为实现这些目标所需完成的任务。这是一个逐层深入的过程：首先为用户画像，接着明确目标，最后确定用户任务。
构建用户画像
一开始制定用户画像时，我们会发现好几个潜在用户群体。我们需要从这些群体中识别出主要用户群体——这个群体应该是购买主力。
一旦确定主要用户群体后，我们需要构建用户画像或角色，包括描述目标用户的性别、年龄、行业、职业以及其他相关的画像统计数据，还应包括可能影响用户使用产品的习惯和态度等因素。
制定用户画像的目的在于让你的团队获得对主要用户的集体理解。当你的团队考虑新特性时，他们应该问自己，我们主要用户会如何反应，他们可能会使用这些特性的可能性有多大。
用户画象应尽可能切合实际且具有代表性。团队成员能够清晰地在头脑中将用户具象化。用户画像应该是你的主要用户的一个可靠的横截面：呈现出他们的需要、愿望、习惯和态度，这样你最终形成的产品就会针对你的主要用户群体的大多数人，而不仅仅是其中的一小部分人。
尽量避免在讨论中过多考虑次要用户群体的需求，因为我们无法满足所有人的需求，也不需要去满足所有人的需求，只需要将目标集中在主要用户群体上即可。
确定用户目标：
一旦你有了你的主要用户画像之后，我们需要确定他们在使用产品时的主要目标，他们希望通过使用产品来完成什么样的任务。
请注意，当你和用户交谈时，他们可能会告诉你他们认为他们想要的解决方案，而不是他们的目标。用户往往很难把他们想要达成的目标和他们如何达成这个目标区分开来。
这很重要，因为解决他们的问题可能有比他们想象中更好的方式。你需要给设计师和工程师自由去找到最好的解决方案。你的重心应该在确定用户需要完成什么以及什么阻碍了他们的方式上。
确定用户任务：
最后，你需要与你的团队（可能包括产品设计师、工程师等人员）一起制定出用户在使用你的产品时需要完成的具体任务，这些任务应能帮助用户达成他们使用产品的目标。这可能涉及讨论和规划产品的功能、界面设计、用户交互等方面，以便最终提供一款符合用户需求和目标的产品。
在这个过程中鼓励创新和创意。尝试设想用户可以如何快速、轻松地完成他们的目标。然后，评估各种备选方案之间的比较。
需要注意的是，任务并不等同于功能。功能是为了完成任务而设计的，会在后续步骤中确定。产品的功能应该与用户的任务相对应，并且这些任务又能够与更高级别的目标相联系。
第五步：确定产品功能
现在，你的团队将开始填写你的PRD的主要内容。在这个部分，你将按照其功能来描述每一个特性。你将描述任何已经对产品设计施加的限制。在定义你的需求时，你也应该注意任何做出的假设。
产品的功能将以所谓的功能需求来表达。功能需求规定产品必须做什么。然而，它们不能规定产品如何做。”如何”将在产品设计和开发过程中决定。
很重要的是，需求不能规定实现方式，也不能偏向于某一解决方案。只有在“解决方案中立”的需求下，你的设计师和工程师才能自由地找到一个针对实现用户目标的最优解决方案。
产品设计的约束通过非功能性需求来表达。非功能性需求描述了所有利益相关者对产品设计的限制或约束。例如，用户可能需要产品在特定的平台上运行。你的公司或客户可能需要产品与他们的一个或多个现有系统接口。限制可用于指示产品的操作环境的限制，比如产品必须承受的温度范围和其他环境条件。
在对每个功能进行描述时，最好将其分解成多个组成部分。“功能模板”可包括以下几个部分：
- 描述
- 目的
- 解决的用户问题和任务
- 功能性
- 约束
- 假设
- 设计（初步线框或模型）
- 当前版本中不包含哪些功能或内容
- 验收标准
最后，回过头来质疑你的假设。你是否已经完全确定了你所做的所有假设？这些假设是否有效？有没有遗漏的东西？我们很容易在不自知的情况下做出假设。回顾你的需求，确保它们是解决方案中立的。
第六步：构建原型并进行概念验证
产品经理和开发人员经常会犯一个错误，那就是在他们完成PRD草案后过于自信。问题在于，当Beta反馈到来时，已经太晚以至于无法进行大的修改。
解决这个问题的办法是使用原型进行产品验证测试。现代的原型设计工具使这一过程变得比以往任何时候都更简单。
产品验证测试通常可以分为三类：可行性测试、可用性测试和产品概念测试。
可行性测试
可行性测试包括构建原型或模型，并进行评估，以确定是否可行。工程师、架构师和设计师都要参与其中，共同探索可使用的技术和可实现的方法，识别可能存在的难题并给予评估，以便及早发现是否存在无法解决的问题。
可用性测试
可用性测试是从目标用户获取反馈的有效方法，通过测试，我们可以识别到未被获取的需求或哪些现有需求与实际用户需求不符。产品经理和设计师需要构思出展示产品功能的方式，以使用户了解如何使用产品。在达到满意的用户体验之前可能需要进行多次迭代。
产品概念验证
仅确认产品的可行性和可用性不足以验证用户是否会购买产品，是否可以实质性地帮助他们实现目标，所以我们需要进行产品概念验证。
通常情况下，产品概念验证可以与可用性测试同时进行，那么就要求所创建的原型必须尽可能接近最终产品。当前的原型制作工具可以帮助团队更快、更简便地创建出高度接近最终产品的原型。
整合反馈信息
在产品概念验证阶段，团队应收集并分析用户和其他利益相关者的反馈信息，然后根据这些信息来修订和优化产品需求。这个步骤非常重要，因为很多工程问题主要源于需求错误。
如果在产品开发的早期阶段发现需求错误并给予修正，那么纠正错误的成本会相对较低。但如果需求已经进入了实施阶段，那么纠正错误就会耗费更多时间和资源。我们可能需要对已经开发出的产品功能进行修正，甚至重做。
第七步：制定发布标准和时间表
一旦确定产品需求并通过验证，下一步就是对需求进行优先级排序，设定发布目标和时间表。产品经理通常会使用如”必须有”、”非常期望有”和”有也不错”等字眼来标记需求优先级，同时也需要基于这些分类对每个需求进行详细排序，原因有两个：
时间的重要性：由于项目开展后日程发生变化并不少见，我们可能需要对需求进行缩减，以确保产品能在规定日期前完成。如果团队首先选择实现最简单的需求，而忽略了更重要的需求，可能就没有足够的时间来完成所有必要的需求。
需求的变化：在产品开发过程中，可能会有新的需求出现。有些新需求非常重要，需要优先完成。如果没有详细的优先级排序，可能会导致团队优先完成的是次要需求，而忽视了更重要的需求。
此外，还需制定一些可量化的成功指标，以便确定产品是否达到发布标准，这些指标包括：
- 性能
- 稳定性和可靠性
- 易用程度
- 安全性
- 可维护性和支持性
- 可扩展性
- 适应性
- 与产品相关的其他因素
第 八步：审查和修改产品需求文档（PRD）草案
在产品实施之前，需要对产品需求文档（PRD）进行全面的审查，确保文档的完整性和准确性。
所有相关的利益者都应参与此过程，以确保产品切实满足了他们的需求。开发人员应充分理解需要解决的问题，以便根据需求来开发产品；而质量保证（QA）团队需要获取足够的信息来设计测试计划，编写测试用例。
在处理和解决了所有利益相关者提出的问题后，我们就会得到一个完整的、可供产品开发团队使用的产品需求文档。
第 九步：产品开发管理
产品开发过程中必然会出现各种与需求相关的问题，甚至会发生需求遗漏，这时候应以实际需求为基准，尽可能找到问题的解决方案。如果不能立即找到明确方案，也要及时解决问题，并记下相关的决策。
在整个产品开发和发布过程中，PRD应是“活”的文档文档，可作随时更改和调整，可供团队参考和追踪所有功能和需求。
如果PRD足够准确，就更利于里程碑审查的准备工作，确保整个团队对产品的目标有清晰的理解，从而保证产品开发的顺利进行。
四、编写产品需求文档时常遇见的挑战
挑战1：确保可用性
可用性测试常见的两个误区是：测试不充分和测试太晚。可用性测试旨在观察并理解用户使用产品时遇到的问题以及他们如何解决这些问题。
在设计和实施可用性测试时，以下是一些需要注意的要点：
- 应在需求开发阶段而非实施阶段进行可用性测试
- 需要计划多个测试迭代
- 项目经理和设计师应尽可能参与更多（如果不是全部）测试会议
- 邀请其他内部利益相关者观察测试，他们可能会提出不一样的见解。
- 在进行可用性测试时，要关注用户的使用反馈，而不仅仅是口头反馈。
注意观察用户跟产品的互动情况。如果团队中没有专门进行可用性测试的工程师，可以考虑与专业公司合作。
挑战2:你不是你的用户
客户可能不像产品设计者那样深入理解产品的技术细节。产品设计者可能认为某些功能已经非常明了易用，但对于首次接触产品的潜在用户来说，这些功能可能并没想现象的那么直观，甚至可能与他们的预想相反。如果用户对产品的第一印象不好，他们对产品的接受度就不会很高。
为了解决这个问题，我们需要经常和真实用户一起检查和测试产品。他们能理解产品的工作原理吗？他们会使用产品吗？他们对产品满意吗？在产品开发过程中，客户的反馈至关重要。
挑战 3：解决方案偏好
编写产品需求时的一大挑战就是容易偏好某个解决方案。在明确产品需求时，应注重产品需要解决的问题（即功能需求），而不是规定如何解决这个问题（即解决方案）。
如果需求偏向某一特定的解决方案，会存在两个问题。第一，工程师会做出错误的假设。同一个问题可能存在多种不同的解决方案，其中一些可能比其他解决方案更优。如果错误地假定了一种解决方案，就会排除更优的解决方案，这就限制了创新的可能性。第二，会增加开发团队的挫败感。工程师负责提出解决方案并实施，他们希望能有创新的自由，而不是按照既定的解决方案执行。
因此，应确保产品需求文档（PRD）中的每个需求都清楚地描述了产品需要实现的功能，不应规定解决方案。
挑战 4：细节不足
给予工程师和设计师一定的自由度的同时，仍需要在产品需求文档（PRD）中对产品进行详细的描述。
如果PRD中的信息不够详细，团队后期将面临高昂的纠错成本。团队成员可能会根据自己的理解来补充PRD中不够明确的地方，但不同的人可能会有不同的假设，在开发后期很可能会导致预料之外的问题出现，而这个时候的纠错成本会大幅度提高。
最好的解决方法是让团队在早期阶段反复审查PRD草稿。随时解决发现的问题，并在PRD中更新相关内容。在开发过程中也要预留一些时间来应对突发问题，并即时更新PRD。
挑战 5：细节过多
细节过多也是一个问题。如果产品需求文档（PRD）内容过于复杂，团队成员可能会没有耐心认真研读，他们或许会基于自己的理解作出错误的假设。
务必牢记PRD是最高级别的文档，详细程度也要适当。如果要构建的产品非常复杂，我们可能需要针对每个子系统编写低级别文档，比如软件需求规范。
需求应该简明扼要。解释性的文本和核心需求应该分开，且表达要简洁。只添加与上下文相关的内容即可。如果不知道怎么简洁明了的表达需求，或者团队成员多次请求就某个表达进行解释，可以考虑使用“简洁需求句法”（EARS ）。
挑战 6：功能过载
过度增加产品功能也是一个问题。我们有时候会以为添加更多功能，就会吸引更多用户。但是对于高科技产品而言，过度增加功能效果会适得其反。
功能过多会增加产品的复杂程度，导致用户难于找到所需功能。而且，功能过多也会增加产品的维护成本和客户支持成本。
因此，我们要仔细斟酌需要添加哪些功能。科技行业里的很多产品一开始都挺好，之后越来越多功能被添加进去，产品就变得越来越“笨重”，最终导致用户流失，反而初始版本更能满足用户需求。
挑战 7：工程驱动的需求
工程团队可能会因为被新技术吸引或者热衷于解决某个难题，而想要产品经理按照工程团队的想法和方式来制定产品需求，这就是”工程驱动的需求”。
然而，产品经理在处理这种情况时，应以实现客户价值为主导，要坚持制定那些能为客户带来实际价值、能在合理的时间内成功开发出来，并能按时交付的产品需求。产品经理不应该只是满足工程团队的兴趣和期望，而去制定那些在给定时间内无法实现的需求。
挑战 8：市场驱动的需求
“市场驱动的需求”是指销售和营销团队根据他们对市场的理解和与客户的互动，对产品的需求产生影响的情况。他们可能会根据客户的反馈，要求产品团队在产品中添加某些特定功能。
这可能会导致”特殊版本”的问题。公司的销售代表可能会向客户承诺，产品团队会按照客户需求开发出一个特殊版本，其目的通常是为了获得额外的销售收入。
“特殊版本”可能会带来以下问题：
- 如挑战6所述，新添加的功能可能会增加产品复杂性，导致用户操作困难。
- 可能存在多个产品版本需要构建、测试、维护和支持，附加的任务会占据工程团队工作时间，导致他们没有时间完成对公司回报更高的工作。
- 客户通常无法准确表达他们的需求，所要求构建的功能可能并不是他们真正的需求。
为了避免上述情况，产品经理需要评估每个功能请求对产品的整体价值，并知道应该拒绝哪些请求。理想情况下，我们应该开发出广大用户都能找到价值的产品，无需针对某些特定用户定制特殊版本。最好将用户纳入产品的设计和测试阶段，这样我们可以更深入地理解他们的需求和期望，从而更好地满足他们的需求，提高产品的成功率。
挑战 9：可追溯性
“可追溯性”指的是能够追踪需求在产品开发生命周期中的各个阶段的能力。例如，可以将一个需求链接到相关的设计决策、开发任务、测试用例，甚至是报告的缺陷。这样的链接能够提供一个完整的上下文解释，帮助团队理解为什么有这个需求，以及这个需求如何影响到产品的其他部分。
在Word文档或电子表格中追踪需求很繁琐也很容易出错。一些专门的需求管理工具，如 PingCode 可以结构化的方法来捕捉、管理和追踪需求。
