产品角色，第4部分：产品定位和项目角色

敏捷社区中的许多人都提倡产品导向而非项目导向。这是可能的，因为组织拥有产品或功能团队。直到您拥有的产品超过团队为止，这才可行。那时候您可能仍然需要项目来完成所有事情。如果将团队保持在一起，您仍然可以在面向产品的组织中使用项目。

比团队更多的工作

组织参与实验的次数越多，我们发现自己要做的工作比团队做工作的机会就多。那是因为我们看到了更多考虑因素的选择。回到产品角色，第1部分：产品经理，产品负责人，业务分析师，我建议产品人员问这个问题：

我们现在是否已经为该产品或服务做了足够的准备？

如果我们现在已经做得足够多，则可以移至下一个产品。
我看不到人们经常问这个问题。积压的值不足以进行。但是，由于我们拥有此产品并且我们希望专注于此产品，因此一个（或多个）团队对这个产品的持续时间过长。

如果您听到“我们需要全部”，那么即使积压的价值不足，您也可能陷入做更多事情的陷阱。

我们想要的是团队让这个产品暂停一下，然后转移到下一个产品。都是因为我们没有足够的团队来提供我们想要提供的所有产品和服务。

我们需要暂时停止使用此产品。启动另一个产品。

这意味着我们需要对工作进行排序。（是的，这也与管理项目组合有关。）

本产品之间的时间块？您可以在其中插入具有更多价值的其他产品。猜猜我需要再做一张图片。

滚动计划在团队级别进行。它也适用于组织中的每个级别。

我在以前的许多文章中都写过关于基于项目的滚动波计划的文章。

左图是您可能会想到的基于产品的滚动计划的一种方式：

定义产品策略：我们现在想要哪些客户/用户受到什么影响？这告诉我们我们想要的结果。我为此部分使用了一个影响图。
根据影响图，创建一个按月交付的年度计划。定义可交付成果是困难的部分。那是因为谈论工作很容易。从结果开始，我们要产生的影响要困难得多。
使用滚动波计划可以在接下来的几周内进行详细计划。在接下来的几周内，请少做一些详细的计划。您现在有一个两周到一个月的计划。每个星期之后，请重新计划新的“最后两个”星期。您有一个为期一个月的计划。（我认为步骤2和3是一个内部循环。）
询问有关我们每周是否做得足够的问题。我们是否已为想要的客户实现了想要的结果？我们是否需要重新审视我们想要的战略或结果？我们发现以产品水平交付。我们在策略级别也是如此。（我认为步骤1和4是外部循环。）

您现在可以从策略转向策略，然后再返回。

所有这些产品计划和重新计划都需要时间。定义小的可交付成果？对于许多采购订单和团队而言，这相当困难。创建影响图以实施我们想要的策略？对于产品经理和产品价值团队来说也很困难。

这就是为什么我推荐一个产品价值团队的原因。

所有这些计划和重新计划都是不平凡的。在某些方面，这种级别的计划更容易-您不必计划整年或18个月就知道自己错了。

在某些方面，这种计划和重新计划比为整个产品计划一次要困难得多。一个大计划是错误的，但是您只能尝试一次。相反，如果您每周重新计划，您将根据团队为实验，MVP，MMF和所有东西提供的东西进行微调整。

成功的重新计划意味着重新计划的人拥有访问实验结果和客户反馈所需的所有访问权限。一个人（一个PO）无法做到这一点。一个产品价值团队可以。

当团队停止开发“ 他们的”产品时，他们会做什么？任何其他产品。

在“ 管理您的项目组合”中，我说过要通过团队进行工作。有些团队会发现其他项目很容易过渡到。有些人需要研究和时间来习惯于代码和测试基础。尤其是如果代码和测试过时且笨拙。

我的建议：不要等待完美的团队出现。如果您将这种新产品作为挑战而不给团队施加压力，那么他们将胜过您能想象的任何事情。他们可能会抱怨，但他们会成功。只要您允许他们使用流效率。

流程效率甚至在基于项目的组织中也促进了产品导向。如果您有流程效率方面的心态，则不管您是产品还是项目方向。重要的是，您要了解整个组织的成果流，想要产生的影响：

我们仍然可以在面向产品的组织中进行项目吗？是。

项目是否会在任何类型的组织中强调各种产品角色？是。而且，即使我们考虑的是基于产品的组织，我们仍然存在相同或相似的问题。产品计划和交付的敏捷方法需要有才能的人做好工作。这不仅仅是一个人的角色。

下一篇文章是关于如何与组件团队一起思考流程效率的。

到目前为止的系列：

翻译自: https://www.javacodegeeks.com/2019/04/product-roles-product-orientation-role-projects.html