客户，内部交付和信任

您的客户每年最多只能购买一次或两次以上的产品。 因为产品不需要离开建筑物，所以团队不会在内部发布。 团队也不会定期进行演示。 团队错过了对于敏捷方法至关重要的反馈循环 。 他们的敏捷转型崩溃了。

重新考虑您对客户的定义

如果我们扩大对“客户”的想法怎么办？ 如果我们将所有这些人都视为客户怎么办：

• 购买产品的各种人。 （您可能需要零售商或集成商才能将产品交付给使用产品的人员。）
• 使用产品的各种人。 （也称为“最终用户”。）
• 开发人员和测试人员以及产品或功能团队中的其他任何人。 有时，这些是程序中的其他功能团队。 （您对这些人有好名吗？同事？）
• 为产品或项目提供资金的人。 （也称为利益相关者。）
• 对项目或工作的进展感兴趣的人，这样他们就可以决定在哪里资助下一组功能，等等。（不同的利益相关者）。

当我们将所有这些不同的人都视为“客户”时，我们可能会避免以下问题：

1. 我们在项目后期发现了功能问题，因为团队没有花时间来自动化测试或更新他们的测试。
2. 我们发现产品问题-产品与“每个人”所期望的方式不一致-因为我们没有端到端地看待产品。 我们尚未发布它以查看我们的进度。
3. 我们发现发布问题，因为团队没有在内部练习发布。

这些问题我不怪任何人。 有时，这是产品所有者的特征。 有时，供应商会更改其交付环境，而不告诉团队。 有时，人们（尤其是利益相关者）对产品的看法有所不同，因为他们社交化了他们期望的变更，而没有人告诉团队。

我们不要讨论责备。 让我们考虑一下如何创建具有短反馈循环的敏捷项目，而不是看起来像瀑布的项目。

防止看起来像瀑布的敏捷项目

我的几个客户遇到了这些问题。

他们从功能问题开始。 他们决定修复和测试，然后修复并重新测试，因为他们并非总是在第一时间就获得正确的修复。 一位客户的FFR（ 故障反馈比率 ）在6周内接近25％，很长一段时间后才感到卡住。

一旦功能起作用，他们就可以解决产品问题，即整个产品如何工作。 之后是上面的测试/修复循环。

现在，该对释放进行一些操作了。 一位客户没有解决构建系统的速度慢的问题，花了几天时间和人工干预才能获得通过烟雾测试的干净构建。 他们花了一周时间清理了建造过程。

现在，每个客户都有几个小时的构建过程可以正常工作。 是时候提供更多东西了。

他们的首要目标是每月交付：

• 他们确认可以每月交付产品。 他们创建了一个可行的版本。
• 他们向所有利益相关者和其他团队内部展示了该产品。
• 他们要求反馈。

每个客户需要时间和大量工作来创建这些每月的可交付成果。 一个人只花了两个月。 其他两个需要三个月才能创建每月可交付成果。 但是，他们看到了以下结果：

• 产品管理人员现在可以看到需求。 在产品中，而不是在人们的头脑中。
• 对于集成产品，供应商还创建了更多的临时版本。 一个团队听到产品经理的话说：“您的最新变更破坏了我们的团队。 那不是合作伙伴所做的。 您需要每周至少一次向我们交付临时版本。”
• 高级经理要求较少的估计数，因为他们可以看到产品的进度。

每个人都从这些每月可交付成果中学到了东西。 最大的学习可能是他们的功能集非常庞大。 在他们减少功能集的大小之前，他们无法获得每周或更频繁的交付成果。

反馈循环帮助团队创建了较小的功能，从而使团队可以转移到每周的构建和演示。

现在，当团队说：“这是一个巨大的功能。 这周我们能提供什么？” 产品经理开始讨论MVP甚至MVE。

经常交付成果建立信任

这些客户开始利用内部可交付成果来创造文化变革，即使他们的客户无法接受也不想每周交付。

现在，要素团队彼此信任，因为他们可以看到彼此的进度。 产品人员信任团队交付的产品。 各种集成商通过更频繁的交付物来建立更多的信任。 认为自己需要估计的高级管理人员喜欢这些每周的交付成果。 他们可以看到团队定期交付。

请注意，它们始于行为更改（移至频繁发布），而不是流程更改。

他们之所以能够进行敏捷转型，是因为他们内部进行协作，并且内部发布的频率更高。

都是因为他们对客户的看法不同。

如果您的最终用户一年最多只能使用几次该产品，那么您仍然可以使用敏捷方法。 考虑更改您的客户定义。 尽可能在内部发布，看看会发生什么。

翻译自: https://www.javacodegeeks.com/2019/02/customers-internal-delivery-trust.html