产品路线图是我们将在我的 4 部分系列中深入探讨的第二个路线图。如果您尚未阅读它们，请阅读第 1 部分：路线图概述和第 2 部分：能力路线图。顾名思义，产品路线图定义了产品或产品及其功能的预期未来推出。由于我们正在谈论技术，因此我们将假设后者进行讨论。
与我们正在讨论的其他路线图一样，产品路线图随着时间的推移展示了产品的未来。通常，企业架构不会产生产品路线图。通常，这可能是营销或产品管理的功能，或任何这些实体的组合。实际上，它将涉及所有三个方面的输入：EA、产品和营销，因为每个都为路线图提供关键信息。
产品路线图的受众不仅仅是开发人员，它用于提供有关何时创建功能的指导。它被用作一种元认知工具，用于组织产品团队的思想，以及与高管和其他内部利益相关者的沟通媒介。它也可以用于外部利益相关者，但应注意确保外部受众知道这不是合同承诺或对即将发生的事情的硬性定义。许多组织不会在产品发布之前共享产品。苹果因限制对其产品的可见性而臭名昭著，使他们受到许多谣言和猜测的影响。
产品路线图的基本输入，例如战略、当前产品和技术需求以及市场需求，都会影响路线图，应该以批判的眼光进行评估。如果在其中一个影响路线图的变化中发现了变化，则应注意并立即或在其下一次迭代中调整路线图。
您将产品路线图预测到未来多远？与所有优秀的建筑师一样，答案是视情况而定。与功能一样，如果产品具有较长的开发周期或强烈的资本需求（如 CPU），那么它会更长。对于大多数软件产品，您需要 18 到 24 个月，但这实际上取决于您的需求。投影越远，它的价值就越小。换句话说，随着时间的推移，产品路线图的不确定性更大。
Figure 1 — An example of a product roadmap created in Lucid Chart
产品路线图看起来像一个项目计划——它不是。有一些相似之处。两者都有时间线，都可能有依赖关系，并且都可能在垂直轴上有分组。但它们的不同之处在于意图。产品计划更加详细，代表要完成的任务。产品路线图旨在显示功能何时可以推出。请注意，一旦功能完成，它不会自动推出，它只是准备推出。
哦，所以如果功能正在计划中，这不违反敏捷原则吗？并不真地。开发人员不会选择用户故事。有人会这么认为，但不一定。产品路线图并非一成不变。它是根据战略和市场需求确定功能以及何时需要它们。它受到 IT 将基础架构部署到位的能力以及依赖业务合作伙伴提供交付和支持该功能所需的服务或材料的能力的影响。它为开发团队提供指导，但不是强制要求。产品路线图的输入之一是产品的当前状态。这会根据开发人员实际完成的工作向路线图提供反馈。开发人员仍然是自我管理的，但与往常一样，他们需要了解企业想要完成什么，并且路线图为他们提供决策指导。
开发产品路线图的过程并不简单，涉及大量输入和反馈循环。但总的来说是：
- 确定组织对其产品所遵循的战略。如果您的组织尚未确定战略，请努力确保其确定。首先，它不需要完全充实，但它需要提供选择产品功能的基础。
- 识别特征域。特征宇宙是可以定义的所有可能特征的集合。这并不是说一切都会好起来，也不是说一切都会实施。这可以来自许多不同的来源。市场和客户是最明显的，但它也可以来自审查竞争对手的产品、非竞争对手的产品，以及软件开发人员等内部资源，他们确定了不同数据源之间的协同作用，可用于为客户带来价值.必要时，还将对特征进行分类。类别可以由受众或角色、子系统、地理或其他定义创建。可以定义多个类别，为每个类别生成路线图或具有动态视图。
- 将功能与策略对齐。这可能是最困难的部分，尤其是在策略没有明确定义的情况下。查看每个功能，看看它在策略中的位置。它提供价值吗？它有助于实现战略目标吗？如果没有，则丢弃该功能——这并不是说该功能不会在以后重新引入，但最初它不会推动组织向前发展。由于合规性或法规或业务合作伙伴的需要，还可能存在强制功能。这些通常具有必须交付的特定日期，因此对于维持您自己或您的业务合作伙伴的运营至关重要。
- 确定功能的工作量。这是您确定该功能需要多长时间和多少资源的部分。这更像是一种猜测或 SWAG（Scientific Wild-A** Guess），并不意味着 100% 正确，只是一个近似值，以了解这如何适合日程安排。大型功能可能会被分解成更小的块，以便更早地推出部分功能 - 例如，报告功能最初可能会从一些预制报告开始，然后随着时间的推移引入自定义功能。后者将依赖于前者。
- 识别依赖关系。如步骤 4 所述，当一个特征被分解成更小的特征时，特征之间可能存在依赖关系。但可能还有其他对功能的依赖——例如，提供对某些屏幕的访问或共享数据的功能可能依赖于 OAuth2 和 OpenID。提供特定矩阵视图的功能可能依赖于允许用户在应用程序中创建和编辑特定记录的功能。这些依赖关系将指定至少一些功能的开发或准备推出的顺序。
- 布局产品路线图。这就是我们将这一切结合在一起的地方。布局和安排优先功能，了解每个功能所需的工作量以及开发功能的时间长度。根据功能的可用性，必须做出一些努力来了解如何设置功能的时间线。一个特性可以被挤压或拉伸到某个点，但这种弹性不一定是线性的（即，在一个特性上投入更多资源并不能保证它会在更短的时间内完成）。依赖映射将确保依赖链中较早的功能首先完成。
- 冲洗，起泡，重复（Rinse, lather, repeat. ）。好吧，实际上这是一个不断更新或按计划更新或两者兼而有之的问题。产品路线图应该至少每季度更新一次，但在这个瞬息万变的世界中，也许每月一次更合适。每季度进行一次实时调整是一种很好的中间方法。在这种情况下，季度审查将包括更全面的审查，实时调整的范围将受到限制。实时调整将反映来自生产团队、IT 或其他内部服务提供商的反馈循环，以及市场或战略的重大变化。例如，如果您有一个卖方房地产应用程序并且市场转向买方提供更多机会的地方，那么所有这些卖方功能可能会被搁置。制作团队的反馈可能会调整时间表。如果开发人员无法准备好 UI，这将推动功能和任何依赖项的路线图时间表。同样，如果 IT 组织在实施第三方 SaaS 集成时遇到问题，这也可能会延迟某个功能和相关性。如上所述，规划和更新路线图的时间范围取决于您企业的情况。
上面的图 1 提供了使用 LucidChart 开发和修改的产品路线图的表示。Lucid 的模板有颜色代码作为开发的进展情况（完成、等待、迟到）。我发现这在敏捷世界中相当无用，在这个世界中，迟到并不是什么大事，除了在 sprint 方面——它对于看板来说更不重要。另外，为什么要更新图表以表明它已经晚了，而新的修订版本更好地代表了调整后的计划？我更喜欢用它来定义重要性，因为这为开发团队提供了更大的沟通价值。颜色编码还可用于指示其他关键要素，例如成本、产品领域、领域或团队。
产品路线图既是一份活的文件，也是一份未来计划的快照。因此，出于历史目的，应定期存档。有许多专门用于路线图和产品路线图的工具。质量更好的工具将是数据驱动的，并将更新路线图以反映变化。并非所有更改都可以由数据驱动，很有可能。开发团队的输出等数据可能保存在未集成的不同系统中。战略和市场细节通常也不能用于集成。
总之，产品路线图是一个看似简单的过程，但实际上相当复杂。它涉及许多不同的组织利益相关者，是一个平衡多个关注点的过程。然而，它是推出产品的重要组成部分，有助于调整战略和执行。请继续关注我关于路线图的最后一篇文章——技术路线图——大约一周后会发布。
