产品角色，第6部分：缩短反馈循环

我开始了本系列文章，讨论了敏捷组织中各种基于产品的角色的问题。 我建议建立一个产品价值团队，因为一个人会成为瓶颈。 一个人不太可能制定产品的战略和策略。 而且，将产品计划分批处理四分之一并不鼓励我们减少反馈循环的持续时间。 当我们针对缩短反馈循环进行优化时，我们可以创建更多实验并为产品提供更多选择。

您的客户可以成为您的产品所有者吗？

早在我们开始使用敏捷方法时，许多团队就直接与其客户合作。 如果您在IT组织中，而您的客户在大厅里（实际上是在大厅里），则可以将客户用作产品所有者。

我说可能是因为，根据我的经验，客户太忙于做他们的工作而不能成为您的产品所有者。

如果您可以将客户用作产品所有者（这是最初的想法），则可能是创建的最短反馈循环。

• 客户和团队一起定义下一个小批量工作。 （一点点，一点点，一点点，就像几天的工作一样。想想，一点点。）
• 团队一起工作，必要时与客户核对，以澄清，展示并通过示例进行验证，他们正在完成这一小部分工作。
• 客户有足够的机会说“是！” 或“不”，在这项工作的任何时候。
• 团队将工作交付给客户

如果您可以每天为您的客户量身打造，请每天向您的客户发布产品，继续做您正在做的事情。

但是，如果作为产品所有者的客户没有时间与团队共处，那么您的情况就是最糟糕的：拥有产品所有者头衔的人却没有这样做。 您的反馈循环会很长。

而且，如果您创建大众市场产品怎么办？ 您无法将我们所有人带入您的办公室。 你不想 我们不知道我们需要什么。 这就是产品价值团队将产品战略与公司战略联系起来的原因。

当团队看到他们的反馈循环时，当组织看到他们所做的一切的持续时间时，他们通常会重新思考他们管理产品所有者角色的方式。

可视化您当前的反馈回路

这是“ 看到最接近客户的难题”帖子的价值流图：

这个团队与产品负责人的距离不够。 产品负责人与产品经理的联系不够。 产品经理与销售人员的关系不够密切，过程会以另一种方式重复进行。

太多的人是瓶颈。 不知何故，这些人认为他们不需要协作来澄清需求并保持团队的前进。

这些人忙于“他们的”工作，他们完全失去了使用敏捷方法的原因。

敏捷方法邀请协作和频繁交付

让我们记住为什么我们使用敏捷方法：

• 我们希望作为一个团队进行协作，因此我们会在尽可能短的时间内完成工作。 （无交接，延迟或等待完成。）
• 我们希望与客户合作，以​​在合理的时间内交付价值。
• 基于我们的协作，我们可以更改最初计划做的事情，以做更有价值的事情。

当我们作为团队合作并与客户合作时，我们的反馈循环可能最短 。 然后，我们可以转到下一个有价值的可能性。

敏捷方法不是要“事半功倍”，也不是胡说八道。 当然，这就是管理者想要的，但这不是敏捷方法所提供的。

敏捷方法为我们提供：

• 的可能性没少做，有价值的工作。 我们不做一些工作来“节省”时间。
• 当我们合作时，我们通过减少等待他人的时间来“节省”时间。
• 有机会更快地更改更有价值的工作。

当我们将“产品人员”彼此分开时，我们将失去所有这些优势。 即使我们有跨职能的协作“产品”或“功能”团队，我们也会失去产品人员的帮助。

产品价值团队可以帮助缩短反馈循环

在上面的周期时间图中，我们可能需要一个拥有更多人员的产品价值团队：销售人员，产品经理，各种产品所有者。

您需要多少人回答您的产品问题？

如果仅需要产品所有者和产品经理，则需要一个小的产品价值团队。 但是，如果您需要两个以上的人，则可能需要不同的结构或不同的方式来处理不可避免的问题。

如何缩短提出产品问题和获得答案之间的反馈周期？ 这就是您的产品价值团队的结构。

该系列：

• 产品角色，第1部分：产品经理，产品所有者，业务分析师
• 产品角色，第2部分：产品价值团队
• 产品角色，第3部分：产品或功能团队
• 产品角色，第4部分：产品定位和项目角色
• 产品角色，第5部分：创建切片的组件团队
• 产品角色，第6部分：缩短反馈循环

翻译自: https://www.javacodegeeks.com/2019/05/product-roles-shorten-feedback-loops.html