敏捷开发中的客户关系

我的管理层刚刚问了我在组织中（公认的简短）历史中前所未有的问题：“我们能为您提供什么帮助？”

同时，我们正在为一个相当新的客户开展几个大型项目，这些客户能够将需求推向项目中间是传奇。为这些人发展就像在流沙上踢踏舞。

似乎是向更敏捷方法转变的绝好机会。我知道我将要被问到的，而且我对此一无所知的是如何为此类项目报价/出价/开票。你每小时去一次吗？您会出价范围吗？冲刺收费吗？

更广泛地讲，敏捷宣言中写着“我们重视客户协作而不是合同谈判”的方面正在吓到我的管理层。您如何看待现实世界中渴望大量消费的客户？

我们公司也有同样的问题。有固定价格，固定时间表的项目，我们的客户通常不是很进步。

关于没有前期承诺的开发，我听说很多原教旨主义者都说：“我知道这很困难，但是您只需要推动收益”，或者，“他们可能会持怀疑态度，但他们会看到效果如何”去了，下次再见。” 也许在某些行业。在我们这里，这真是一堆废话。我看不到我们的任何客户同意只让我们在范围或价格上不承担任何责任地做我们的事情。

我们发现，并非总是有必要更改您为敏捷项目报价/出价/开帐单的方式。如果管理得当，您可以在遵守报价的同时保持敏捷过程。

引用通常的方式（带有填充），并在项目范围内设置一些边界。从那时起，请遵循您的敏捷方法：

• 与客户优先进行工作-首先开发重要的东西
• 小迭代开发，显示您的进度
• 与客户合作，确保您确实在开发他们想要的东西
• 在编写软件时提高规格

但更重要的是：

• 如果某个功能比最初要求的功能复杂，请立即告知客户，并确保他们知道这会影响时间表和/或价格。
• 将主要（甚至次要）更改视为应付费更改请求。

您仍在内部使用Agile并获得收益，但是客户看到的是更熟悉的固定价格，固定时间线，固定范围的项目。任何更改都会花费金钱并浪费时间。

最困难的部分是预先设置边界。这绝对不是一件可以这样做只是你的销售员，BA，或项目经理。您需要在这些会议中有经验的开发人员。您需要确定可能导致问题的区域并确定期望。

一个客户想要付出很少的钱并不会付出更多，因为您写下了大量需求并让他们签订合同。他们将永远回来并希望更改而无需付费。他们会声称他们误解了规范，或者更好，但是您误解了。他们将要求您知道您不会后退的变化。这是一种不好的关系，您不想继续下去。

如果您分解了一个大型项目，并让他们随手付款，那么您很容易看到这笔开发费用要花这笔钱。下一个组件将花费相同的数量，并花费相同的时间来构建。当在一个大型项目中一起使用时，他们将希望获得某种“批量”折扣。

我雇了一个人在我家里做工。从一个小项目开始。也许我可以通过捆绑一堆工作来谈判出更好的价格，但是当他处于3个项目的中间，做得不好并且花的时间比预期的长时，我该怎么办？我看到了他工作的质量和及时性。让他从事其他工作感到非常自在，我不必监视他。您可以与客户建立更好的关系。他们可能会要求更多，因为他们可能会觉得您正在利用它们。

试试这表明贵公司洽谈保持架的合同，然后采取你的敏捷方法服务于客户的需求。您每月从您的团队获得Y小时数的$ X报酬。因为客户在驱动优先事项，所以没人会掏腰包。固定器的优点在于，无论您为它们做什么，它们都可以让您节省时间，并且他们基本上可以改变主意，而不会杀了您。客户将可以用他们的钱更快地获得价值，并且由于敏捷的方法论，该模型支持在开发过程中将变化纳入组合。

如果合同不可转让，则无论如何都要尝试敏捷模型，但是您必须努力确保自己获得应得的报酬。