给产品经理的提示：将产品待办事项与产品愿景联系起来

基于产品的敏捷开发团队面临的持续挑战之一是将他们“现在”正在做的事情映射到产品应该在 2-3 年后实现的目标。

这不是因为团队不知道他们在做什么，而是更多地是因为他们可能过于专注于他们的日常任务，总是会削弱他们“当前”工作在大局中影响的敏感性。 今天在执行过程中做出的决定或选择可能会对未来产生重大影响，尤其是在产品不断发展的时候。

让我们举一个现实生活中的例子。

我是敏捷团队的一员，该团队正试图为网站内容引入文本翻译服务。 做出了决定，并使用了第三方机器翻译工具。 然而，产品路线图最终提到，在未来，用户应该能够纠正并提供自己的上下文翻译，这意味着翻译能力应该具有人工智能，以便它可以根据反馈自行学习。
鉴于这种发展，做出的选择并不恰当，因此需要进行相当程度的返工，因为大局与敏捷团队在冲刺中的任务无关。

有人可能会争辩说，团队可以有意识地努力获取这些信息，但关键是为什么不能在现有的敏捷工具和仪表板中捕捉这些“长期”目标？

敏捷团队在开发周期中执行定义明确的特定任务，但这是否意味着它必须以对产品进化漠不关心为代价？ 不，我不这么认为。

据我所知，在敏捷团队的日常运作中，没有快速的工具或框架可以向敏捷团队提倡或推荐这些信息，但是这样的视图可以在现有视图中创建吗？ 值得一试？ 让我们看看我们该怎么做。

我们将从敏捷中最常见的工件——产品待办列表开始。
根据 SCRUM 研究所，产品 backlog 是项目中需要完成的事情的列表。 这些东西可以包括增强和/或错误。 除非团队知道项目的优先级结构是什么，否则编号列表没有帮助。 这就是产品负责人介入的地方，他全权负责与利益相关者合作以获得明确的需求，解决相互依赖关系，并获得产品待办事项项目的优先列表。

在这个过程中，一个更大的、依赖的工作项可能会被进一步分解成小部分，以便于团队开发。 这些产品待办事项被分解成更小的块，并在 2 到 4 周的 sprint 周期内执行，回答了产品开发的“如何”部分。

另一方面，产品积压项目也映射到产品的“正北” ，通常被称为产品愿景。 这是产品的理想状态，通常通过多个版本发布来实现，并与目标受众或客户的需求及其为他们带来的价值密切相关。

将敏捷团队与客户（包括产品待办事项和愿景）联系起来的这个元素链可以表示为：

敏捷团队与客户需求之间的遥远联系……

由于缺乏将 sprint 与产品愿景明确联系起来的观点，产品负责人往往会面临过度关注“如何”部分而忽视“什么”的更大和重要目标的风险，这可能会导致被误导的优先级。

我在这里讨论的方法是创建一个简单而强大的视图来链接这两个组件。 这被称为产品视觉矩阵（PVM）。 目标是将产品的愿景与细化的开发项目联系起来。 该矩阵成为分析团队在产品开发方面的进展的关键因素。 它还用作组织高级管理人员的产品仪表板，并让他们了解产品目标的可实现性。

顾名思义，PVM 是一个矩阵，其中的列代表正在捕获的维度（从微观到宏观）。 让我们借助一个食品订购应用程序来理解 PVM，其愿景是为用户提供食品体验，起点是食品订购。 示例矩阵如下所示：

产品愿景矩阵可以包含以下字段：

• 产品版本：这是正式发布里程碑的产品版本，通常是客户收到的。
• Big Rock Item：这也是某个功能所属的类别或主题。 这些项目也可以是产品愿景的长期产品需求领域。
• 功能：这是正在开发的产品功能。 该功能可以属于一个或多个主题（大摇滚项目）。
• Sprint ID：这是正在开发功能的 sprint 编号。
• 开发状态：该字段表示开发的进度（计划、设计完成、开发完成、测试和发布）。

请注意，矩阵的结构在这里是指示性的。 在确定可以捕捉产品愿景的列时，可以更有创意。

这种方法的优点是每个团队成员对整体产品目标的清晰可见性。 对于不断发展的产品，团队成员应该对大局有更好的理解。 这不仅使他们能够有效地做出贡献，而且使他们能够承担更多的责任。 结果是一个更加专注和适应能力更强的团队，始终关注客户的脉搏，并认识到他们的冲刺可以为产品的愿景和最终成功做出贡献。

从世界顶级大学在线学习产品管理课程。 获得硕士、Executive PGP 或高级证书课程以加快您的职业生涯。

为您推荐的特色课程：杜克 CE 的设计思维认证课程