The Essential Guide toRequirements Management and Traceability

产品需求文档 (PRD) 被称为产品经理最好的朋友。它充当指南针、路线图和 GPS，帮助引导您的产品发布。给予您的 PRD 应有的关注，它将成为您值得信赖的助手！

PRD 是一个动态文档，您的开发团队中的每个人都会在整个开发过程中为其做出贡献并参考它。

虽然从技术上讲，PRD 可以以多种形式维护，例如 Word、电子表格或数据库，但拥有像 Jama Connect 这样的需求管理解决方案可以提供许多好处和节省时间的功能 – 我们稍后会介绍！但除非您所在的行业由政府或行业标准规定了文档格式，否则您的组织将需要提出自己的 PRD 格式或模板，除非有带有预建模板的正式需求管理平台提供帮助。拥有标准化模板可确保参与产品开发的每个人都可以轻松浏览 PRD 并与团队的其他成员“保持一致”。

在本文中，我们将介绍：

• 什么是 PRD
• PRD 的主要组件
• 创建 PRD 时应采取的步骤
• 编写 PRD 时遇到的最常见挑战或问题
• 什么是好的 PRD 模板
• 为什么要开发模板
• 产品需求文档与利益相关者需求文档的区别
• 好的产品需求文档模板具有哪些功能
• 什么是好的敏捷需求文档的示例
• 什么时候文档不合适
• 模板在以数据为中心的产品开发中的位置

最后，我们将提供有关如何为您的团队构建 PRD 模板的信息，以及您可以在哪里了解有关在需求管理平台上维护 PRD​​ 的更多信息。

---

什么是产品需求文档 (PRD)？

产品需求文档定义：

• 待开发产品的目的和价值主张
• 产品的特性和功能（即需求）
• 产品发布的目标和时间表

PRD 与 MRD 不同。MRD（营销需求文档）由营销部门开发，记录用户对产品的需求和期望。MRD 在产品需求文档之前创建。

PRD对比BRD？

在产品开发中，产品需求文档（PRD）和业务需求文档（BRD）都是必不可少的组成部分，但它们的用途不同，并迎合不同的利益相关者。

1. 产品需求文档 (PRD)：
   • PRD 主要侧重于从功能角度描述产品应该做什么。它概述了产品应该具有的特性、功能和用户交互。
   • 它通常由产品经理、设计师和开发人员使用，以了解产品的范围并指导开发过程。
   • PRD 包括用户故事、用例、UI/UX 设计规范、技术要求和验收标准等详细信息。
   • 其主要目标是确保开发团队构建满足用户需求并与业务目标保持一致的正确产品。
2. 业务需求文档 (BRD)：
   • BRD 侧重于产品旨在实现的更广泛的业务目标、目标和策略。
     它由不同部门的利益相关者使用，包括业务分析师、项目经理、高管，有时还有外部合作伙伴或客户。
   • BRD 包括产品解决的业务问题或机会、市场分析、竞争格局、业务规则、监管要求和财务考虑等信息。
   • 其主要目标是确保产品符合总体业务战略和目标，并为组织及其利益相关者带来价值。

虽然 PRD 和 BRD 服务于不同的目的，但它们往往是相互关联的。PRD 提供满足 BRD 中概述的业务需求所需的详细规范。它们共同提供了一个全面的框架，用于指导成功产品的开发和部署。

---

产品需求文档的主要组成部分

产品需求文档有四个主要组成部分：

1. 目的

• 产品解决了什么问题？
• 谁会使用它？
• 它如何与公司的战略目标和计划保持一致？

2. 功能

• 需求（定义每个功能）
• 背景和理由（有助于解释需求）

3. 发布标准（应涵盖五个领域）

• 功能 – 发布所需的最低功能
• 可用性 – 如何确保产品易于使用
• 可靠性 – 如何确定系统足够可靠
• 性能 – 产品必须达到的基准
• 可支持性 – 如何确保公司能够支持该产品

4. 时间线

• 目标发布窗口
• 项目里程碑
• 发布依赖关系 – 可能影响发布的已知因素（超出发布标准）

---

产品需求文档的主要组成部分

步骤 1：做功课

要创造一款出色的新产品，您需要彻底了解该产品将要解决的问题。获得这种了解的唯一方法是做一些功课。

研究您的客户。与他们交谈。确切地了解他们需要您为他们解决什么问题。为什么这对他们很重要？他们要付出什么代价？

研究您的竞争对手。研究他们解决问题的方法。根据您从客户那里了解到的信息，确定您的竞争对手在解决问题方面的优势和劣势。您如何更好地满足需求？

咨询市场营销、销售和技术专家，任何对问题有见解的人。

评估您团队的能力。他们如何应对问题？他们熟悉或对哪些技术感兴趣，哪些技术可能有助于解决问题？

研究可用的技术。相对于解决问题，它们的优势和劣势是什么？

所有这些功课的目的是让您做好准备，领导您的产品开发团队。当您知道自己在说什么时，您就会表现出信心。这将激发团队的信心，并让大家做好迎接未来挑战的准备。

第 2 步：定义产品的目的

利用您在步骤 1 中学到的知识，您现在将在此步骤和接下来的两个步骤中填写 PRD 的第一部分。

您需要建立一个清晰、简洁的价值主张，简洁地传达产品将满足的需求，并说明产品如何与您公司的总体目标和产品战略保持一致。将这个价值主张细化为可以在一分钟内背诵的“电梯游说”。

提供指导，帮助团队在产品的设计和实施过程中做出权衡 让每个人都清楚产品的成功实施将带来什么。

第 3 步：定义产品的原则

为产品建立一套原则，指导团队完成开发。

例如，对于医疗设备，原则可能是：

• 极其安全
• 高度可靠
• 易于使用且直观

您可能会发现，定义产品原则会引导您完善和完善价值主张陈述。或者您可能会发现您的原则只是脱离了价值主张练习。无论哪种方式，您的产品原则都将充当指南针，帮助您的团队在接下来的两个步骤中定义用户任务和产品功能。

步骤 4：确定用户资料、目标和任务

一旦您确定了产品的目的，就需要确定产品的目标客户。您需要清楚地了解产品的用户、他们使用产品的目标以及他们为实现这些目标将使用产品执行的任务。这是一个深入的练习：首先定义用户资料，然后定义目标，最后定义任务。

构建用户资料

当您开始定义用户资料时，您可能能够确定产品的几个潜在用户。从这些用户中，您需要确定主要用户：就产品销售而言对您的公司最重要的用户。

确定主要用户后，构建描述性用户资料或角色。此资料将表明目标用户的性别、年龄、行业、工作职能和其他人口统计数据。它还应包括用户可能影响他们使用产品的任何习惯和态度。

建立用户档案的目的是为了集体了解主要用户的来源。当您的团队考虑新功能时，他们应该问问自己，该用户会如何反应以及他们使用新功能的可能性有多大。

让您的用户档案尽可能真实且具有代表性非常重要。团队成员需要将用户形象化。档案还应代表主要用户的确切需求、愿望、习惯和态度，这样您最终才能为主要用户群的大多数而不是其中的一小部分塑造产品。

最重要的是，一定要只关注主要用户。不要让次要用户参与讨论。取悦所有人是不可能的，所以不要尝试。针对主要用户进行优化。

确定用户目标

获得主要用户档案后，确定该用户使用产品的主要目标。他或她需要完成什么？

请注意，当您与用户交谈时，他们可能会告诉您他们认为他们想要的解决方案，而不是他们的目标。用户通常很难区分他们想要完成什么以及他们如何完成它。这很重要，因为可能有比他们想的更好的方法来解决他们的问题。

您需要让设计师和工程师自由地寻找最佳解决方案。专注于确定用户需要完成的确切任务以及阻碍他们前进的障碍。

确定用户任务

最后，与您的团队合作设计任务以帮助用户实现他们的目标。

在此练习中鼓励创造力和创新。尝试设想用户可以快速轻松地实现目标的方法。然后，相互评估替代方案。

注意：任务不是功能。功能支持任务，稍后定义。功能应通过任务映射到更高级别的目标。

步骤 5：指定产品的功能

现在，您的团队将开始填写 PRD 的主要内容。在本节中，您将根据其功能描述每个功能。您将描述对产品设计施加的任何限制。您还应该注意在定义需求时所做的任何假设。

产品的功能将以所谓的功能需求来表达。功能需求规定产品必须做什么。但是，它们不能规定产品如何做。“如何做”将在产品设计和开发期间确定。

重要的是，需求不会规定实施或使其偏向一种或另一种解决方案。只有“与解决方案无关”的需求，您的设计师和工程师才能自由地找到针对实现用户目标而优化的解决方案。

产品的约束将以所谓的非功能性需求来表达。非功能性需求捕获利益相关者对产品设计施加的任何限制或约束。

约束通常指定兼容性需求。例如，用户可能需要产品运行特定平台。您的公司或客户可能需要产品与一个或多个现有系统交互。约束可用于指示产品操作环境的限制 – 产品必须承受的温度范围和其他环境条件。

您可能会发现，通过在模板中将每个功能的描述分解成几个部分来组织描述会很有帮助。您的“功能模板”可能包括：

• 描述
• 目的
• 功能解决的用户问题和任务
• 功能
• 约束
• 假设
• 设计（初步线框或模型）
• 不做（任何不包含在发布中的内容）
• 验收标准

最后，回过头来质疑您的假设。您是否完全确定了您所做的所有假设？这些假设有效吗？忘记了什么吗？很容易在没有意识到的情况下做出假设。检查您的需求以确保它们与解决方案无关。

步骤 6：对您的概念进行原型设计和测试

产品经理和开发人员经常犯这样的错误：在完成起草后对他们的 PRD 过于自信。问题是，当 Beta 反馈到达时，进行重大更改已经太晚了。

解决此问题的方法是使用原型进行产品验证测试。现代原型设计工具使这一过程变得前所未有的简单。

产品验证测试通常分为三种类型：可行性测试、可用性测试和产品概念测试。

可行性测试

可行性测试包括构建原型或模型，然后检查它以确定是否可行。

让您的工程师、架构师和设计师参与进来。探索可用的技术和可能的方法。确定障碍并评估其严重程度。它们是否无法克服？最好现在就知道。

可用性测试

可用性测试是一种从目标客户那里获得反馈的高效方法。它通常会识别缺失的要求或比最初设想的更少必要的要求。

您和您的设计师需要想出展示功能的方法，以便用户了解如何使用产品。在获得令人满意的用户体验之前，计划运行多次迭代。

产品概念测试

仅仅知道您的产品是可行的和可用的是不够的。最重要的是确保人们会真正购买它。为此，您需要将产品展示给真正的用户，并确定它是否真的能以令人满意的方式帮助他们实现目标。这就是产品概念测试的作用所在。

产品概念测试通常可以与可用性测试相结合。然而，为了实现这一目标，原型必须高度逼真。幸运的是，当今的原型设计工具不仅使这一点成为可能，而且快速而简单。

结合您的反馈

在测试产品概念时，请根据您获得的反馈更新您的要求。这一步骤的重要性怎么强调也不为过。大多数工程错误都源于需求，一旦开始实施，纠正这些错误的成本就会急剧上升。

第 7 步：建立发布标准和时间表

建立并验证了需求后，重要的是对它们进行优先排序和排列，并设定发布目标。

许多产品经理通过给功能贴上标签来确定其优先级，例如“必须有”、“非常想要”和“最好有”。但对这些类别中的每个需求进行排序也很重要。这样做有两个原因。

首先是上市时间。时间表经常会延误。当它们发生时，您可能需要削减功能和需求以满足发布日期。您不希望您的团队首先实现最简单的需求，结果却发现没有足够的时间来完成所有必备需求。

第二个原因是需求在不断发展。在实施过程中，您可能会发现新的需求。有些需求可能至关重要，并且在优先级上取代了现有需求。您需要知道这些新需求在您的优先顺序中处于什么位置。如果不这样做，不太重要的因素将决定首先实施什么，这可能会对产品的成功产生负面影响。

除了优先考虑需求之外，您还应该建立一些可量化的成功指标，以确定产品是否适合发布。您的成功指标可能包括以下测量：

• 性能
• 可靠性
• 可用性
• 安全性
• 可支持性
• 可扩展性
• 可本地化性
• 与您的产品相关的其他因素

第 8 步：审查并修改 PRD 草案

在开始实施之前，请测试 PRD 的完整性。

让所有利益相关者参与进来。他们应确保 PRD 满足他们的需求和顾虑。开发人员是否完全了解要解决的问题？QA 是否有足够的信息来制定测试计划和编写测试用例？

一旦您解决了利益相关者发现的任何问题，您就会有一个 PRD，可以从中开始构建产品。

第 9 步：管理产品开发

在产品开发过程中，会出现无数与需求（或缺乏需求）有关的问题。请始终参考 PRD。如果没有答案，请解决问题并记录决定。

您的 PRD 是一份动态文档。使用它来跟踪整个开发和产品发布过程中的所有功能和需求。

最重要的是，保持准确性。这样做将简化里程碑评审的准备工作。此外，您的整个团队将清楚地了解你们的目标。

---

编写产品需求文档时遇到的常见挑战

挑战 1：确保可用性

说到可用性测试，两个常见错误是 (1) 做得太少，以及 (2) 做得太晚。

如果您是可用性测试的新手，您可能会对首次使用原型的用户遇到的困难程度感到惊讶。您很快就会发现他们遇到的问题以及如何解决这些问题。

在规划和执行可用性测试时，请牢记以下一些要点：

在需求开发期间而不是实施期间进行可用性测试
计划进行多次迭代
确保项目经理和设计师出席大多数（如果不是所有）会议
邀请其他内部利益相关者进行观察（可能会令人大开眼界）
注意用户做什么，而不是他们说什么
如果您不确定用户为什么做某事，请询问，但更重要的是观察他们与产品的互动。如果您的组织中没有可用性工程师，您可能需要与专门从事可用性的公司签约来运行此测试。

挑战 2：您不是您的客户

客户很少像产品创造者那样沉浸于技术中。通常，对于产品设计者来说显而易见且直观的功能对于首次接触该产品的潜在用户来说可能显得晦涩难懂且违反直觉。糟糕的第一印象可能会让潜在客户对您的产品产生反感。

您必须持续不断地与真实用户一起对您的产品进行现实检查。他们是否了解其工作原理？他们会使用它吗？他们会重视它吗？客户反馈在开发过程中是无价的。

挑战 3：解决方案偏向

在编写需求时，您必须指定产品必须做什么（要解决的问题），而不是产品将如何做（解决方案）。重要的是不要将需求偏向于一种或另一种解决方案。

解决方案偏向需求有两个陷阱。

首先，工程师可能会做出错误的假设。同一问题可能有许多不同的解决方案。有些会比其他的更好。错误的假设可能会排除其中最好的解决方案，从而关闭创新之门。

其次，你可能会让开发团队感到失望。你的工程师是被雇佣来提出解决方案的，然后他们必须实施和维护这个解决方案。他们是必须接受并支持它的人。工程师希望自主创新。他们往往讨厌读起来像处方一样的规范。

确保 PRD 中的每个要求都清楚地说明了产品必须做什么，而不是规定解决方案本身。

挑战 4：细节太少

虽然你想给工程师和设计师足够的自由来找到最佳解决方案，但你仍然需要完全指定产品。

如果你的 PRD 存在差距，你可能会在以后付出沉重的代价。团队成员可能会做出假设来填补差距。不同的团队成员可能会做出不同的假设。没有人预料到的问题可能会在游戏后期出现，那时纠正这些问题的成本要高得多。

防止这种情况的最佳措施是让团队尽早并经常审查 PRD 的草稿。解决所有问题并在 PRD 中解决它们。规划开发过程中出现的问题。分配时间解决这些问题。解决问题后更新 PRD。

挑战 #5：细节太多

细节太多和太少一样糟糕。如果 PRD 变得厚重，团队成员将失去耐心，不会阅读它。这会导致更多的假设。

请记住，PRD 是顶级文档。使用适当的细节级别。如果您的产品非常复杂，您可能需要为每个子系统提供较低级别的文档，例如软件需求规范。

简洁地陈述需求。分离解释性文字并保持简洁。仅添加上下文所需的内容。如果您发现在编写简洁的需求时遇到问题，或者团队成员不断要求澄清，您可能需要考虑使用严格的需求语法，例如 EARS。

挑战 6：功能过载

您希望您的产品能够吸引尽可能多的客户和用户。因此，添加功能以满足每个人的需求和愿望可能很诱人。不幸的是，尤其是对于高科技产品，添加功能往往适得其反。

堆积功能会增加产品的复杂性。这会使某些功能更难找到并导致用户困惑。过多的功能还会增加维护成本和客户支持成本。

谨慎添加功能。遵守纪律。科技界充斥着一些产品，它们一开始很棒，后来变得如此臃肿以至于客户放弃了它们。它们不再像刚推出时那样能很好地发挥作用。

挑战 7：工程驱动的需求

您的工程团队可能迷恋他们想要使用的新兴技术。他们可能会对想要解决的具有挑战性的问题感到兴奋。这可能会导致他们向产品经理提出大量要求，从而有效地决定他们想要构建的解决方案。

产品经理应该倾听工程需求，但要关注价值。他们需要定义一种客户会购买且可制造的产品，一种经过大量努力可以按时完成的产品。他们不能让工程师制造他们想要的任何东西，也不能让工程师制造在计划时间限制内无法实现的东西。

挑战 8：市场驱动的需求

销售和市场营销也希望在产品定义方面有发言权。他们与最好的客户保持密切联系。他们掌握客户需求的第一手资料，并负责销售这些产品。

这成为问题的一种方式是所谓的“特价”。贵公司的某个人向客户承诺提供一款特殊版本的产品，其中包含客户要求的新功能。通常，这是以额外的购买或费用为交换条件的。

特价会给贵公司带来几个问题。

首先，额外的功能会增加复杂性，从而导致客户感到困惑和沮丧，正如我们之前在挑战 6（功能过载）中讨论的那样。

其次，您最终会得到多个版本的产品，现在您必须构建、测试、维护和支持这些产品。所有这些额外的任务都会拖累工程，并阻止您的公司从事更有利可图的工作。

最后，客户经常难以表达他们的需求。所要求的功能可能是他们认为自己想要的。一旦他们收到新功能，用户可能会发现它们根本不符合他们的需求。

为了避免这个陷阱，要有纪律。评估每个提议功能的价值。知道何时放弃并愿意这样做。

更好的是，确保您的标准产品足够有用和引人注目，以便客户可以在没有定制功能的情况下生活。让那些有价值的客户参与产品概念和可用性测试。深入挖掘以了解他们真正需要什么。

挑战#9：可追溯性

最后，您的 PRD 不仅仅跟踪您的产品需求。它还需要跟踪问题、测试用例、错误和每个需求问题解决方案的机制。它必须支持需求可追溯性。

在 Word 文档或电子表格中实现可追溯性可能很复杂且繁琐。专用的需求管理工具（例如 Jama Connect）可以极大地促进需求的可追溯性。

---

什么才是好的 PRD 模板？

确定什么是好的 PRD 是一回事，而实际创建一个 PRD 则更具挑战性。许多团队都在寻找在线模板，但尽管这些模板可以作为有用的起点，但它们可能并不适合每个团队或产品。每个团队和产品都是独一无二的，团队完全有可能需要创建自己的模板或定制现有模板以满足他们的需求，然后再编写 PRD。PRD 中包含的数据和信息的内容和组织对于每个组织来说都会有所不同，具体取决于他们的产品线、文化和产品开发流程——一刀切的做法并不适用所有组织！下表显示了不同组织使用的一些示例 PRD 模板。表 1 显示通用部分，表 2 扩展了设计输入要求部分 3.2.x。

---

优质产品需求文档模板的特点

好的 PRD 模板将遵循逻辑顺序，从产品构思到设计，再到最终产品发布。您的 PRD 模板在语言或定义上可能会有所不同，但它应该大致按照指示的顺序包含以下元素：

目标：这是为谁准备的？哪些角色或用例是相关的？产品如何与战略计划保持一致？
发布详细信息：包括里程碑、依赖关系、名称、发布日期和其他与产品发布相关的详细信息。
产品功能：这部分显然是您的 PRD 的主要内容。命名并描述功能、其用途以及功能解决的问题。不要包含超出每个功能范围的项目。
线框和模型：正如人们所说，一张图片胜过千言万语。使用视觉元素来帮助定义用户流程和设计。
分析：使用此部分建立对产品的期望。尽可能具体。例如，“我们认为更改聊天界面将提高客户满意度”不如“我们认为将聊天界面重新设计为白底蓝字将使我们的 NPS 得分提高 1 – 2 分”具体。
未来计划：假设最好的情况——您的产品将取得成功，您需要在此基础上继续前进！成功的产品发布可能会带来哪些未来的工作、计划和目标？

---

为什么要开发 PRD 模板？

如果您没有使用可以自动完成大部分工作的正式需求管理解决方案，那么拥有一个针对您的产品线量身定制的标准模板可以方便重复使用，并提供有助于确保完整性的检查表。模板应该适用于您组织内开发的所有产品，但可以根据各个项目的需求针对特定类型的产品进行定制。

PRD 模板可以包含的不仅仅是大纲。它们可以包含在产品线中通用的“样板”文本。此外，通常有一组适用于组织开发的许多产品的通用要求，例如质量要求、安全和保障要求、显示和控件的用户界面要求以及处理标准和法规的要求。

从 PRD 模板开始，项目团队成员可以专注于定义 PRD 中要包含的要求，而不必首先制定大纲来组织这些需求和要求。一旦开发了此类模板，它们就可以重复用于未来的项目。为您的需求制定一个标准组织可以更轻松地在文档中查找信息。标准大纲、样板文本和产品线通用的要求也可用作检查表，以防止遗漏。

虽然您可以使用 PRD 模板在多个项目中重复使用，但如果此模板位于 Word 文档或电子表格中，您仍将面临版本控制问题和冗长、混乱的文档。在此视频中详细了解为什么 Word 和 Excel 不足以管理复杂的要求。

---

产品需求文档与利益相关者需求文档有何区别？

在创建或定制 PRD 模板之前，了解 PRD 到底是什么以及其用途非常重要。

PRD 用于定义产品技术设计输入要求。PRD 应传达什么、谁和如何。文档和产品的目的是什么、为谁服务以及如何满足利益相关者的需求。一些组织可能将 PRD 称为产品需求规范 (PRS)、软件需求规范 (SRS)、系统需求文档 (SRD) 或系统设计规范 (SDS)。

重要的是要记住，PRD 与利益相关者需求文档 (SND) 不同。理想情况下，SND 应该放在首位，因为它专注于客户、用户和其他关键利益相关者的需求和愿望。与 PRD 一样，一些组织可能会用各种名称来指代 SND：营销需求文档 (MRD)；利益相关者需求文档 (SRD)、业务需求文档 (BRD)、范围定义文档 (SDD)、产品概念文档 (PCD) 等。名称不如内容重要。)

任何成功的产品开发工作都必须从客户和其他关键利益相关者的需求开始。产品要解决什么问题？定义预期结果的愿景、目标和目的是什么？驱动​​因素和约束条件是什么？预算和时间表？用例和操作场景是什么？利益相关者需要哪些功能、特性、性能和质量水平？必须解决与使用产品相关的哪些安全风险？适用哪些标准和法规？所要求的内容是否可行？

这些是项目开始时必须在 SND 中解决和记录的一些问题。在定义技术设计输入要求之前，了解利益相关者对产品的需求和期望非常重要。SND 中记录的综合需求集将转化为纳入 PRD 的要求。 PRD 中的需求向开发团队传达了产品必须做什么才能满足客户、用户和其他利益相关者的需求。

了解有关定义和管理需求的更多信息。

---

哪些是好的敏捷需求文档的示例？

一般来说，敏捷开发的重点导致敏捷项目团队避免使用文档作为沟通需求和要求的正式方法。敏捷项目确实处理了传统上包含在 SND（利益相关者需求文档）和 PRD 中的信息，如上所述，但形式不太正式，依赖于团队成员和客户之间的频繁互动，以“冲刺”的方式进行。团队将非正式地定义每个冲刺的期望和预期结果。

但是，许多组织会在一些人称之为敏捷需求文档 (ARD) 的内容中定义一组高级项目期望、需求和要求。这些信息是高级的，用于识别要解决的问题、产品的目的、愿景、目标和目的、关键驱动因素和约束、高级用例、功能、特性、预期性能、合规性要求等。

ARD 的目的是向敏捷项目团队传达一个高级定义，以限制项目范围。 ARD 用于启动项目，传达高层客户期望，产品验收将以此为基础。在此级别的沟通中，ARD 的内容通常在确定基线并启动项目后不会改变。解决 ARD 中的愿景、目标、目的、需求和要求的细节留给敏捷团队。

由于敏捷产品开发的性质，SND 和 PRD 类型文档的模板不适用。敏捷团队必须灵活并快速响应不断变化的需求。对于 Scrum 团队来说，短冲刺和快速周转意味着几乎没有时间创建文档，更不用说更新和维护它们了。

在敏捷指南下工作的团队需要保持敏捷，这意味着避免使用文档。在敏捷环境中，团队可能只有很短的冲刺时间来完成功能或新版本。在这个短暂的过程中添加正式文档的开发只会增加不必要的工作量和复杂性。

---

什么时候文档不合适？

从历史上看，非敏捷产品开发项目以“文档”的形式定义和记录与各种产品开发工件相关的数据和信息，如上文所述的 SND 或 PRD。但是，使用以文档为中心的方法对当今的产品有许多不利之处。

随着产品变得越来越复杂和规范，文档的数量可能会让人难以承受；尤其是在整个产品生命周期的配置管理、变更控制和变更影响评估方面。通常，许多文档是由不同的、地理上分散的组织单位在孤岛中开发和管理的，协作有限。

在以文档为中心的方法中，几乎不可能使各种文档中包含的所有数据和信息保持同步、最新、正确和一致。因此，没有真正的单一事实来源 (SSoT)。例如，产品的需求和要求可能会发生变化，这使得文档中的数据和信息的维护变得繁琐且耗时。对于受到严格监管的产品，必须开发、维护并提供给监管机构以证明合规性的文档数量已经变得非常庞大。这些文档中的不一致可能会导致产品无法获准使用。

与管理文档中数据和信息更改相关的成本和时间开销消耗了开发成本的很大一部分，侵蚀了利润率。时间开销通常会导致更长的开发时间和上市时间，从而降低公司的竞争力。此外，质量受到影响，导致产品发布后的成本增加，与报销、召回、保修工作以及与负面社交媒体评论相关的公司形象下降有关 – 所有这些都会侵蚀利润。未经批准使用的受到严格监管的产品可能会导致公司的股价暴跌，在某些情况下，甚至会导致公司破产。

尽管 SND 或 PRD 等文档很有价值，但以文档形式管理需求和要求存在上述缺点。当发生变化时，项目团队需要一种有效的方法来评估每个变化如何影响整个生命周期中的其他工件。

为了有效地开发和管理这些复杂且受到严格监管的产品，组织需要过渡到需求管理软件平台（例如 Jama Connect），以便项目团队启用 Live Traceability™ 来建立 SSoT、建立整个产品生命周期的可追溯性以及管理和评估变更。

即使对于不太复杂的产品，使用文档作为记录通常包含在 PRD 中的数据和信息的主要形式也可能不是正确的选择。如果团队分散，即使将这些文档存储在云中，也要保持其最新、同步和一致，这可能具有挑战性。

---

模板在以数据为中心的产品开发中处于什么位置？

上述模板的必要性和好处同样适用于使用需求管理软件平台（如 Jama Connect）进行以数据为中心的产品开发。不同之处在于，数据和信息的组织是根据支持可追溯性的特定类型的数据和信息来定义的。针对各种类型的数据和信息及其关系定义了“模式”。

与文档不同，需求和要求是以“集合”的形式组织的。您可以建立一组集成的利益相关者需求（而不是 SND）和一组与产品架构相对应的需求（而不是 PRD 和其他需求文档）。

这并不意味着不会有文档。虽然 SSoT 在软件应用程序中存储和管理的数据和信息中维护，但文档可以创建为“报告”。每个报告都可以在软件应用程序中定义一个具有前面讨论的相同特征的模板。

使用这种方法，SSoT 在需求管理软件应用程序中维护，而不是在作为应用程序输出的报告中维护。这些类型文档的用户需要了解“文档”中数据的货币仅在文档从应用程序输出时有效。

---

结束语

产品开发团队知道，好产品和优秀产品、好产品发布和优秀产品发布之间的区别往往在于规划。从清晰的定义和描述开始，在整个开发过程中追踪需求，并保持足够的灵活性以适应过程中的变化，这些都是关键。文档并不总是为真正的实时可追溯性方法提供正确的框架。

Jama Connect 可以帮助您的开发团队迈向产品开发的未来，摆脱文档的束缚。要了解 Jama Connect 如何简化需求，请联系我们。