决策时间：决策规则如何帮助您做出更好的产品决策-CSDN博客

作为产品经理和产品所有者，我们做出了无数的决定-从制定产品策略，确定产品路线图到确定产品的详细功能。但是，我们是否可以有效地做出所有这些决定？我们是否始终确保获得必要的买入？这篇文章可以帮助您做出更好的决定。它讨论了五个常见的决策规则，并说明了何时应用它们。

决定，决定

“每个人都可以改变Q3的发布目标吗？”产品经理Julie问。沉默了几秒钟后，假设利益相关者同意，朱莉转到下一个主题。但是大多数人仍在思考或反对这个想法。而且，没有人真正知道谁做出最终决定。是产品经理，在场人员还是管理赞助商？

如果不清楚如何做出决定以及需要谁的意见，人们将不确定是否确实做出了决定以及是否应该采取行动。有些人将开始执行该决定，而其他人则将其忽略而不是继续执行。

如果您希望人们朝着同一个方向前进，则需要明确指示他们是否已做出决定：您应清楚说明如何做出决定以及需要谁的意见。换句话说，您应该应用正确的决策规则。

决策规则

下图显示了五种常见的决策规则，我从Sam Kaner等人的“ 参与性决策的主持人指南 ”一书中改编而成。等请注意，在图片中，我使用产品经理一词来指代产品负责人。当然，这确实包括产品所有者。

上图中的每个决策规则都有其优点和缺点。 没有单一的方法总是合适的 。要选择正确的决策规则，请考虑要解决的问题以及必须多长时间才能做出决策，如下所述。

确保让正确的人参与决策。根据经验，与参与者（对您的产品感兴趣并影响其成功的能力的利益相关者）互动，尤其是当风险很高时。

共识

达成共识意味着每个需要做出决定的人都同意所提议的解决方案或想法。基于共识的决策会产生强大的认同感和共享所有权，并且会利用在场人员的集体创造力和知识—每个参与其中的人都为决策做出了贡献。当风险很高并且您做出战略性产品决策时，这特别有用，例如，如果您应该进行调整，创建产品变体以解决新的市场细分，或者更改产品路线图上的下一个主要版本的目标。

这种方法的缺点是，在小组内达成共识可能需要较长的时间，因为它需要发展相互理解并评估相互竞争的想法。您甚至可能必须安排几次会议才能得出结论，特别是如果您在过程中测试不同的想法时，尤其如此。

请注意，基于共识的方法不会退化为委员会的决策，因为人们会就最小的共同点达成共识，并促成弱小的妥协。这不太可能达成可持续的协议并转化为成功的产品。俗话说，“骆驼是委员会设计的一匹马。” 相反，共识意味着每个人都对该决定感到满意，并全心全意地支持它。

在应用此决策规则时，您将受益于经验丰富的协调员，该指导员将指导所有人完成决策过程并帮助人们达成协议。您的ScrumMaster或敏捷教练可能会帮助您。

产品经理

此决策规则要求您与合适的人讨论想法或解决方案，并征询他们的意见以及支持他们的所有数据。一旦进行了足够的讨论或时间到了，您就可以决定。一个很好的例子是决定如何发展产品积压。您可以要求利益相关者和开发团队提供他们的意见，但是在进行了一些讨论之后，您可以决定是否添加新故事，以及如何确定它们的优先级。

这种方法的好处是它可以使人们参与决策过程，但是您可以保留对决策的控制权。它还可以通过限制寻找包容性决策所花费的时间来加快流程。但是决策规则的缺点是人们可能不同意并支持您的决策，或者更糟的是，由于他们的建议没有被采纳，他们可能会感到沮丧。如果最终决定是错误的，那么人们可能会将其视为您的错误和问题。因此，他们可能不愿意为您提供帮助。该规则还要求您有权做出决定，而对于影响收入和其他业务目标的影响较大的决定而言，情况可能并非如此。

当您需要让开发团队和利益相关者从他们的知识中受益或使他们感到有价值时，请应用此规则，但与此同时，您必须做出决定而不是让团队达成共识。当关键的利益相关者不具备达成有意义的共识的知识或意愿，或者在例如在危机中，速度比达成可持续的协议并产生强大的支持更为重要时，可能会出现这种情况。

代表团

如果其他人更有资格做出决定，或者是否不需要您的输入，则委派决定。作为产品负责人，您通常希望开发团队负责所有技术决策。但是，如果人们对用户，产品以及如何创建新的故事有足够的了解，您还可以将有关如何完善一些用户故事的决定委托给团队。

委派有助于确保最有资格的人员做出决定，这可以释放您的时间：您不会花费过多的时间进行决策。如果正确应用，它还会向任命的决策者发出积极信号：表明您信任他们并重视他们的专业知识。

但是不要使用规则来避免困难的决定。委派您不想负责的决定可能太容易了。并且不要试图影响做出决定的小组，例如说：“您当然可以决定，但是我认为我们应该把故事做得太小了”，因为这表示不信任。如果您需要参与决策，则不要将决策委托给其他人。

多数票

顾名思义，多数表决意味着大多数需要做出决定的人都同意所提议的解决方案或想法。应用此规则很简单并且相对较快。但是，这造成了双赢的局面，使少数派感到沮丧并且不愿意支持这一决定。

因此，我建议您仅在风险不高的情况下才将此规则用于产品决策。让主要利益相关者对一项重大的战略变更进行投票可能是不合适的，您最好使用共识或产品经理在讨论后做出决定。

但是，如果您无法在Scrum团队内部达成共识，例如在下一个Sprint中是否应解决技术风险或与用户相关的风险，那么您可能想请人们投票。这样可以加快决策过程，并在分配的时间范围内完成冲刺计划。这是可以接受的，因为该决定的影响可能会受到限制：如果您解决了错误的风险，则会在下一个冲刺结束时发现。

产品经理决定

作为产品负责人，您当然不必让其他人参与所有决策：您可以并且应该自己做出许多影响较小的决策。例如，在下次冲刺审核会议中是否需要销售代表，您是否应该邀请个人？您应该开始分解积压的产品中的一些较大的史诗，还是推迟其他冲刺？随着产品稳定，您是否应该从每月战略和路线图审查过渡到季度审查？

但是请注意，该决策规则仅在您具有正确的决策知识并且不需要其他人的支持时才对您有所帮助。从上面的最后一个示例中，您决定更改产品策略审核的频率。如果您确定利益相关者会同意您的决定，并且不需要他们的意见或建议，则只需做出决定。但是如果有疑问，请使用共识或产品经理在讨论后决定 。而且，如果您将这种方法用于对他人有重大影响的重要决策，那么人们可能会将您视为独裁的领导者，从而破坏或反对您的决策。