将您的特性积压工作转化为一个可操作的优先计划矩阵。为了最大限度地利用团队有限的时间和资源，您需要掌握有效地划分优先级的艺术。当然，返利平台有哪些，说起来容易做起来难。当你有大量的机会可供选择，而且有大量的利益相关者，他们都想要不同的东西时，从全局来看可能会很困难。矩阵是一个简单的工具，您可以使用它在您可以开发的所有其他潜在特性的上下文中可视化每个潜在特性。如果您已经在Airtable中管理功能请求和用户情景列表，Airtable Blocks平台最新添加的matrix block允许您根据现有信息自动创建优先级矩阵。有许多不同种类的优先级矩阵，每一种都针对不同的目的进行了优化。今天，我们将集中讨论几种最流行的产品计划优先级矩阵类型：价值复杂性矩阵、价值风险矩阵和敏捷用户故事映射。价值复杂性矩阵确定产品路线图优先级的最直观和最直接的方法之一是根据预期的业务价值和实现复杂性对潜在的新功能进行分类。"业务价值"可以包括许多不同概念中的任何一个，这取决于公司的总体战略目标：给定功能对客户、员工或供应商的有用程度；新功能产生更多收入、流量或宣传的能力；或者新功能可能对产品的性能、安全性和可靠性产生的积极影响。""实现复杂性"是一个类似的大类，包括实现一个特性需要多长时间，实现该特性在技术上有多大的挑战性，以及开发该特性所需的成本（仅举几个例子）。最简单的价值复杂性矩阵是2x2的象限网格：给定项目的值可以是低值也可以是高值，而给定项目的复杂度可以是低值也可以是高值。要为您自己的团队制作这种矩阵，请从特性请求表或潜在的新特性表开始，并为值和复杂性创建两个单独的选择字段。如果您还没有产品规划基础，可以从我们这里的模板开始。接下来，将矩阵块添加到基部。选择适当的表和视图后，选择Value字段定义行，选择Complexity字段定义列。如果您的任何记录在Value或Complexity字段中缺少值，它们将映射到具有空值的记录的单独单元格中。这对于在矩阵中移动卡片非常有用，如果你还不确定一个给定的特征落在哪里。你的产品路线图绝对可以被认为是低复杂度的产品。然而，一个常见的陷阱是只对这些特性进行优先排序，而牺牲了高价值、高复杂性的特性。高价值、高复杂度的项目通常是更大的战略计划，需要大量的努力和时间，但最终将是值得的，从长远来看会产生巨大的回报。处理这些特性的一种方法可能是考虑是否可以将它们分解为更简单、更不复杂的任务。低价值、低复杂性的项目最终可能不值得您花费时间，但绝对不应该优先考虑高价值功能。您可以在以后的开发周期中重新访问这些特性，或者考虑其他可能使它们具有更高价值的方法。低价值、高复杂性的项目应该被取消优先权或重新考虑。价值风险矩阵价值风险矩阵是价值复杂性矩阵的另一种选择，价值复杂性矩阵也按预期的业务价值对潜在项目进行分类，但（正如你所预期的那样）它按项目实施的风险程度而不是实施的复杂程度对其进行分类。风险是产品开发中固有的：您对完成一个特性所需的时间或成本的估计可能存在不确定性，您的团队执行该功能的能力存在不确定性，或者不确定项目可能获得多少执行支持。当你对自己的基本假设不太确定时，价值风险矩阵尤其有用，双线服务器租用，这意味着当你开发全新的产品或计划时，它是一个特别有用的框架。最简单的价值风险矩阵是2x2的象限网格：给定项目的价值可以是低或高，而给定项目的风险可以是低或高。要为您自己的团队制作这种矩阵，企业管理应用，请从潜在的新特性、产品、机会或计划表开始，并为价值和风险选择两个单独的字段。你也可以在这里复制我们的风险价值矩阵模板。接下来，将矩阵块添加到基部。选择适当的表和视图后，选择Value字段定义行，选择Risk字段定义列。如果您的任何记录在Value或Risk字段中缺少值，它们将映射到具有空值的记录的单独单元格中。如果您还不确定某个特性的价值或风险有多大，这对于在矩阵中移动卡片非常有用。一般来说，高价值、低风险的项目应该优先考虑。在投入时间和精力之前，应仔细考虑高价值、高风险的项目，但同时，根据团队的情况和风险承受能力，您可能希望将其中一些项目放在高价值、低风险项目之上。通常情况下，高价值、高风险的项目对整个产品的影响要比高价值、低风险的项目大得多。完全避免高风险的项目可能会导致这样一种情况：在最终撞到墙之前，你已经构建了产品的很大一部分。另一方面，追求高风险的东西会导致你浪费大量的时间去开发一个你永远不会用到的特性。在这里使用你最仔细的判断：你应该在什么时候和多久去追求高价值、高风险的项目取决于你的产品的性质和你的团队的风险承受能力。低价值、低风险的项目最终可能值得您花费时间，但应优先考虑任何高价值功能。低价值、高风险的项目不能很好地利用团队的时间和精力，应该避免。用户情景映射前两种技术在很大程度上是面向产品开发团队的需求的。然而，有时您可能希望在分析中显式地预测客户体验。产品管理顾问Jeff Patton在2005年开发了用户故事映射，它是一种优先级排序技术，可以帮助您和您的团队了解每个潜在的新功能如何与客户的产品体验相匹配。如果你已经是一个敏捷团队的一员，并且习惯于用"用户故事"和"史诗"来思考你的产品开发，那么这种技术应该感觉相当直观。故事图是一个可以用来组织用户故事的矩阵，大数据需要学什么，其中X轴是用户在与产品交互时所采取的按时间顺序排列的动作，Y轴是对每个用户故事对用户整体体验的重要性的评估。（如果您不熟悉用户情景的概念，它们基本上是对用户需求的简短、高层描述。）要为自己制作一个用户情景图，请从用户情景表开始。如果你还没有一个包含用户故事的敏捷产品计划库，你可以从我们这里的模板开始。然后，创建一个名为Usage Sequence的选择字段，该字段为Usage Sequence中的每个步骤提供下拉选项。例如，如果您的产品是一个在线店面，那么您的使用序列中的活动可能包括"搜索产品"、"产品页面"和"结帐屏幕"。此字段将是矩阵的X轴，即您用来定义矩阵列的那个。接下来，创建另一个名为"必要性"的选择字段，您可以使用该字段来评估每个用户情景的关键任务。按照莫斯科方法，您可以创建一个带有下拉选项的选择字段"必须拥有"、"应该拥有"、"可以拥有"和"不会拥有"，或者可以使用一个简单的评级字段。不管怎样，必要性字段都是矩阵的Y轴，也就是用来定义矩阵行的那个。一旦你做了这些，添加一个矩阵块到你的基地。选择适当的表和视图后，用"必要性"字段定义行，用"使用顺序"字段定义列。根据需要随意移动用户故事记录，构建完整的用户故事地图。一旦您完全规划了用户的旅程，并定义了不同级别的重要需求，您就可以开始通过在行之间移动故事来划分优先级。最上面一行中必须拥有的所有内容都代表了创建一个最小可行产品所需的功能，该产品将允许用户成功地完成整个使用序列。一般来说，一个好的经验法则是，您的发行版应该包含使用序列中每个阶段的大致均匀分布的故事。您可以通过实际定义哪些特性将为哪些版本完成而进一步。尝试制作一个发布表，然后使用链接的记录字段将功能链接到发布。（一般来说，物联网智库，必须具备的特性应该出现在早期版本中，之后才是应该和可能的特性。）然后，您可以创建一个单独的计划矩阵，其中的行是由不同的发行版具体定义的，而不是根据它们本身的必要性来定义的。一系列不同的方法这三个例子只不过是草草而已