如何向(瀑布)客户销售敏捷开发

Question

我们的开发车间很想做更多的敏捷项目，但是我们在客户的参与上遇到了问题。许多客户想要一个预算和最后期限。当我们的竞争对手提出了基于瀑布的固定期限和固定价格时，很难在敏捷项目上销售客户。我们知道他们的固定号码不好，但客户不知道。因此，我们最终在客户看来很糟糕，因为我们不能确定价格或截止日期，但我们的竞争对手可以。

那么，如何让您的销售团队成功地销售使用敏捷开发方法的项目，或者使用这些方法开发的产品？我发现的所有信息似乎都集中在项目管理和开发人员身上。

Answer 1

做得好的关键是使用支持合同.

基本上，当你第一次卖给客户的时候，你根据你的专业知识卖给他们，然后你就会做瀑布。这意味着一份确定范围和一条死胡同的合同。这就是客户想要的。客户端或多或少知道范围。瀑布运行得很好，在固定和定义的作用域环境中，我认为它比敏捷在这样的环境中工作得更好。在这种情况下，当客户出现紧张的倾向时，它会给客户一定程度的安慰，因为他以前从未和你共事过。没关系，敏捷并不总是比瀑布更好。

所以你有一份固定价格的X范围合同。然后你告诉客户“看，你会想要做些改变，你需要我们支持你的后期制作，让我们留出你预算的20%，在需要的基础上，通过一个支持合同来使用这些东西。”

如果在项目期间出现更改，只需将其推迟到支持联系人下处理。(假设这一变化会对项目造成严重干扰)

支持联系人的条款如下：“按客户要求，每小时完成的工作可用于更改请求或一般系统支持和维护。”哈哈！你在敏捷里。

然后，您可以继续扩展支持联系人，只需使用支持联系人作为运行新项目的手段。此外，如果这些时间是购买和支付的前期，我们通常给予客户15%的折扣。这是双赢。

Answer 2

敏捷并不排除最后期限和预算。如果我是一个客户，我去找了一个开发人员，他们告诉我，他们不能给我一个截止日期或估计成本，我会质疑他们的理智。告诉他们他们只是不明白是行不通的:他们需要能够预算和计划。

他们不需要知道你的开发过程。他们需要知道开发功能需要多长时间，以及要花多少钱。根据(虚假的)假设给他们一个数字，即他们的需求是100%准确的，当他们的需求发生变化时，然后改变你的估计。

这为他们提供了他们想要的预算项目和部署日期，而且当事情发生变化时，您的流程可以让您看起来灵活和通融。

Answer 3

在软件开发之外实现敏捷-Scrum好处的主要障碍是将它与现有的控制机制集成起来。这些控制机制是由于各种组织先决条件而规定的，通常采用线性瀑布方法和方法来实现。

以下描述了这些典型的组织先决条件中的四个：

• 大型全球公司-在这些等级矩阵组织，自上而下的投资组合控制是一天的规则。自由精神的敏捷方法很难适应严格的控制。具体来说，固有的敏捷计划无关的概念，使敏捷-Scrum组织难以吞服。
• 高度管制的行业-一些行业被合规和治理机构要求有严格的约束控制机制。这些部门可以是医疗设备、飞机、药品研究和产品开发业务部门。虽然单个团队可能操作敏捷-Scrum，但是开发过程必须遵循严格的线性瀑布方法来跟踪和治理。
• 复杂的预定义产品-一些综合的产品，包括硬件，软件，嵌入和更多，是作为一个合同与最终客户在一套预先定义的要求。在这些情况下，需求灵活性的程度很小，尽管比最初预期的要大。在这些情况下，完全灵活的敏捷-Scrum的概念受到了很大的影响。
• 通用IT部门-在维护驱动的IT部门中，大部分的日常和每周活动都是临时性的。每天的日程安排都有很多变化，而且是即时的。团队工作中的持续干扰是一种常态。在这种情况下，时间装箱和无干扰的概念是很难维持的。

很自然--很多时候，上面详细描述的四个离散类别实际上是混合在一起的；因此，在一个全球大公司中发现一个复杂的产品是很常见的，它需要遵守公司的规定。

根据实际经验，解决这些场景和其他情况的推荐方法是授权敏捷PMO充当新兴敏捷-Scrum团队和线性瀑布元素之间的推动者、驱动者和翻译器。

有关具体准则，请参阅下表

来源- 线性瀑布与敏捷方法的接口，迈克尔·尼尔