htmlc:循环跳出循环_平衡创新，承诺和反馈循环：摘要

htmlc:循环跳出循环

是否有可能在我们需要的产品创新和反馈与管理层想要的承诺之间取得平衡？ 也许。 在本系列中，我尝试思考这些问题：

• 什么时候要求或提供估计和承诺？
• 什么时候要求更多反馈才有意义？
• 何时为产品创建较小或较大的估计值有意义？

让我们从对非常快速的产品反馈的需求开始。

高变化：您现在需要估算或反馈吗？

越频繁，你需要在你的产品，少估计和承诺你的需要， 现在的创新。 实际上，您不需要提供估计或承诺，因为您需要更多的产品反馈。 您可以显示出可能至少每周一次，甚至不是每周一次都可能要求您估计或做出承诺的人。

注意：在高度创新的工作中，团队可能需要每小时（至少每天一次）的反馈，不仅是产品负责人，还需要产品价值团队以及客户的反馈。

为了创造这种进步，产品人员和团队创建了非常小的故事。 产品人员对这些故事进行排名，因此团队可以从事最有价值的工作。 团队可能会合作，将其在制品限制在一个或两个项目之内，以确保他们完成工作以获取反馈。

您的团队甚至可以与客户坐在一起以获得更快的反馈。

适度的变化：一点估计，一些反馈

如果您只需要进行适度的更改（一次可以计划几个星期），则需要进行少量估算。 该估算是根据工作的可用时间进行的。 除非您能在几周内完成所有工作，否则规划整个功能集并对其进行估计并没有多大意义。

关于一次估算多个迭代的谨慎措施：

在适度变化的环境中，团队可能必须停止处理给定的功能集，然后转移到另一个功能集。 他们应该估计每个功能集的整体性吗？ 不适合我。 尤其是如果您有节奏或迭代以及小故事，请不要费心估计。 使故事很小，然后数数。

如果您可以在几周内完成功能集并确实完成，构建和测试自动化，以及所有用户文档或内部文档完成，该怎么办？ 我高五。 我很少见到这种情况经常发生，但是也许如果您的团队暴民并且您的功能集很小，那么您可以这样做。

在适度变化的环境中，团队仍然需要一些小故事。 团队仍然需要频繁的反馈。 您可能一天不需要几次反馈。 我的经验是，团队需要每天一次到每周几次的反馈。 这完全取决于您的产品。

在较小的时间内（接下来的几周）进行估算和投入是有意义的。 我还没有看到在适度变化的环境中基于季度或基于项目的估算和承诺是有意义的。

零钱变化：管理估算成本和时间

如果您没有太多的产品创新，则可以一次计划整个季度。 如果管理人员需要估算，请进行估算并向管理层解释您的假设。

（有关各种估算方法，请参见预测不可预测以及如何解释假设。有关如何使用周期时间来减少用于估算的时间，请参见创建成功的敏捷项目 。）

我在这里担心的是，产品所有者或产品价值团队没有花时间去思考功能集或完善故事。 团队花费时间进行细化和估算，然后每个月才进行一次季度更改。

如果您的团队必须将一个月或六个星期的工作更改为一个季度的估计或承诺，则产品反馈循环太长。 团队至少浪费了一些估计时间。

相反，请考虑使用基于流的映射 。 说明您四分之一的承诺，并显示下一步的选择。

产品反馈循环与项目反馈循环不同

我将本系列的重点放在产品反馈循环上，而不是项目反馈循环上。 有些项目，即使人们可以计划整个季度的产品价值，也需要经常进行改善或回顾性活动。 从事此工作的团队可能需要每天或每周的项目反馈循环。 产品反馈循环可能仅每季度一次。

每个产品都是不同的。 并且，不同的产品在不同的时间需要不同种类的创新。 这是我看到的一些组织在对高产品创新的需求与管理层对估计的期望之间取得平衡的方式：

备选方案1：首先与“高级”团队进行研究

我的一位客户使用研发工程团队在致力于该项目之前探索了几种架构可能性。

如果“高级”团队限制他们的时间来探索和定义最起码的决定，那就没关系了。 他们还需要与负责该工作的项目团队充分汇报。 我经常看到高级团队知道他们发现了所有陷阱。 然后，两周到两个月后，常规团队发现了Advance团队看不到的更多风险。 管理层常常责怪常规团队不了解。 （叽。）

备选方案2：首先与“常规”小组合作进行研究

另一个客户将前两周到一个月用作研究和学习的高峰。 该团队每天或每周几次突飞猛进，以了解风险以及在何处需要探索更多风险。 如果您认为需要先进行研究，则我更喜欢这种方法。

备选方案3：将研究和交付与频繁的项目组合重新计划相结合

（请注意，这是研究与交付，而不是研究与开发！）

我非常喜欢这种替代方法，因为要进行研究的团队还是从事这项工作的团队。 在这里，团队不仅进行探索，而且在进行过程中实现目标。 我已经在相对较新的产品或最小采用的功能集很小的产品上看到了这项工作。

当团队目前就此产品完成“足够”工作时，高级经理将重新计划项目组合，团队将转移到另一个产品。

考虑您的计划和估算选项

当我将产品反馈循环与项目反馈循环分开时，我了解到我可以进行不同的计划和估算。

确定您的位置。 如果您不喜欢我的连续体，请自己发展。 到目前为止，这个为我工作。

我的准则：

1. 在进行更改之前，不要计划过多的工作。
2. 在进行更改之前，不要估计比您可以做的更多的工作。
3. 请考虑如何创建精细的故事并查看功能集中的复杂性。 这样，您可以显示为什么您的估算值“这么长”。
4. 请考虑以团队学习的方式来管理风险并创建较短的反馈循环。

使用适合您的产品和项目的正确级别的计划和反馈循环。

整个系列：

• 当一切都需要试验和变更时： 平衡创新，承诺和反馈循环：第1部分：高创新产品
• 您可以计划一个月左右的时间： 平衡创新，承诺和反馈循环：第2部分：适度的创新产品
• 当您不更改计划，但仍需要交付时： 平衡创新，承诺和反馈循环：第3部分：低创新产品
• 摘要发布： 平衡创新，承诺和反馈循环：摘要

翻译自: https://www.javacodegeeks.com/2019/02/balance-innovation-feedback-loop.html

htmlc:循环跳出循环