如何将敏捷开发推销给（瀑布式）客户

我们的开发部门确实希望执行更多的敏捷项目，但是在吸引客户方面存在问题。许多客户想要预算和截止日期。当我们的竞争对手提出基于瀑布的固定期限和固定价格时，很难在敏捷项目上出售客户。我们知道他们的固定号码不好，但是客户不知道。因此，我们最终对客户不利，因为我们无法确定价格或期限，但我们的竞争对手可以。

因此，如何使您的销售人员成功销售使用敏捷开发方法的项目或使用此类方法开发的产品？我发现的所有信息似乎都集中在项目管理和开发人员上。

做到这一点的关键是通过使用支持合同。

基本上，当您第一次出售客户时，您是根据自己的专业知识来出售他们的，然后做瀑布式的。这意味着确定范围和确定期限的合同。这就是客户想要的。客户或多或少知道范围。在固定和定义范围的环境中，Waterfall效果很好，我想说在这种环境下，瀑布效果比敏捷更好。在这种情况下，由于以前从未与您合作过，因此容易感到紧张时，它会给客户带来一定程度的舒适感。没关系，敏捷并不总是比瀑布更好。

因此，您具有X范围的固定价格合同。然后，您告诉客户“ 您看，您将要进行更改，并且您将需要我们来支持您的后期制作，让我们为您的这些事情留出20％的预算，以便在需要时使用这些内容。支持合同的方式。”

如果在项目过程中发生更改，只需将其推迟到支持联系人的手中进行处理。（假设此更改会严重破坏项目）

支持联系人的条款如下：“ 应客户要求，每小时进行的工作可用于变更请求或常规系统支持和维护。” BAM！您处于敏捷状态。

然后，您可以继续扩展支持联系人，只需将支持联系人用作运行新项目的方法即可。此外，如果购买了这些时间并支付了预付款，我们通常会为客户提供15％的折扣。这是双赢。

敏捷并不排除最后期限和预算。如果我是客户，我去了一家开发商，他们告诉我他们不能给我限期或估算费用，我会质疑他们的理智。告诉他们他们只是不了解是行不通的：他们需要能够预算和计划。

他们不需要知道您的开发过程。他们需要知道开发功能将花费多长时间以及其花费多少。根据（虚假的）假设为他们提供一个数字，即他们的要求是100％准确的，并且当他们的要求发生变化时，请更改您的估算值。

这样可以为他们提供所需的预算订单项和部署日期，并且当事情发生变化时，您的流程就可以让您看起来灵活而适应。

听起来您的销售人员正在您的开发团队和客户之间造成一层误解。如果他们很长一段时间没有在IT市场上销售产品，他们可能会认为自己的角色是“移动产品”，这意味着“无论需要什么”都可以在合同上签名。简而言之，不管他们的前途如何，他们都有动力关闭。在这种情况下，他们将尽可能跟踪客户的语言。

我引用了一个破记录，但是这是行得通的：您在手术台上，正要走到外科医生的指导下，“我们将按时在预算范围内让您离开这里”。大。我会活着吗？

如果您在从事企业的内部机构工作，您会在某个任意点停下来吗？通常，应用程序不受您或您的客户控制的力量的影响-法规，业务环境，竞争对手的行为，某些新范例的出现等。如果您简单地说“我们将为'价格y'做'x'，客户将在三个月后回来并说-'好吧...'。通常，这意味着当您同意瀑布项目时，他们知道一些他们不知道的东西。

在这种情况下可能有用的方法是向您自己的销售人员演示穿越峡谷的驱动力。到处都有惊喜。不可能看到超过三个月的时间，因此，如果客户要求一个为期18个月的项目，那么在您接近完成时，将无法识别该项目。因此，您的销售代表需要首先找到项目的财务收益。这会增加1000万美元的销售额吗？如果是这样，那么值得投资200万美元来增加这1000万美元吗？如果客户和销售代表正在达成$ 500,000的承诺，那么可能出事了，没人能说出它是什么-这就是感觉不对。“感觉不对”是对做某事的承诺，这有可能会变得无用。

两种最新的喷气客机机型都有过瘫痪的历史。Healthcare.gov甚至不需要讨论。如果您可以找到有关客机的书籍或行业新闻报道，则可以提出如何进行某些假设的假设，这些假设被证明是乐观的，并且这些项目反复错过了最后期限。通常这是由于低估了复杂性。如果在开始编码之前无法真正弄清楚它的复杂性，则需要进行“初始回合”以更好地了解实际问题。预算削减应占额外利润总额（或某些情况下的收入）的一小部分，该数字必须超过任何人认为当前项目将要花费的金额。如果您可以说明如何在不超过“付款限额”的情况下通过最后一个里程碑，

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

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

• 大型跨国公司–在这些层次结构矩阵组织中，自上而下的资产组合控制已成为日常工作。自由奔放的敏捷方法很难适应严格的控制。特别是固有的无计划自由概念，使组织难以接受敏捷计划。

• 高度管制的行业–合规和治理机构要求某些行业具有严格的约束控制机制。这些可以是例如医疗设备，飞机，药品研究和产品开发业务部门。尽管各个团队可能会使用Agile-Scrum，但开发过程必须遵循严格的线性瀑布方法来实现可追溯性和治理。

• 复杂的预定义产品–根据预定义的一组要求，与最终客户签订合同来开发一些包括硬件，软件，嵌入式等在内的集成产品。在这些情况下，需求灵活性的程度很小，尽管比最初预期的要大。在这些情况下，Agile-Scrum的完全灵活积压的概念遭受了很大的损失。

• 通用IT部门–维护驱动的IT部门的日常和每周大部分活动都是临时性的。每天安排的更改很多而且是立即的。经常干扰团队工作是正常的。在这些情况下，难以维护时间拳击和无干扰的概念。

自然地，实际上是上述四个离散类别的许多次混合在一起；因此，通常需要在全球大公司中找到需要遵守公司法规的复杂产品。

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

请参阅下表以获取特定准则

来源-Michael Nir的线性瀑布与敏捷方法之间的接口

我们与潜在客户和我们的开发人员进行了2或3次估算会议，我们在此讨论手头的工作并设定了接受标准。开发人员在会议期间按故事点估算工作。

之后，我们向客户出售许多故事点。这是可能的，因为他对故事点的价值有很好的了解。我们告诉他，他有可能在项目期间微调他的积压/范围，由于使用了故事点，因此这很容易。我们还告诉他，将频繁提供工作软件，以便他可以监视进度并获得新见解。

通过就多个故事点达成共识，可以确保客户物有所值。如果他不更改积压的订单，他将拥有固定价格/固定范围项目，但是我的经验是他会做出更改。通过在潜在客户在场的情况下进行估算，我们尝试建立基于开放和信任的关系。

我们设法说服您所描述的客户“想要预算和截止日期”，他们很高兴我们想真正了解他们的需求，而不是使用文档。我们表明我们想投资这些项目。

在估算会议期间，我们估算了它们的全部积压。这给了x个故事点。对于那些尚不明确或未知的功能，我们建议增加25％。在合同中附有估计的积压订单后，他们可以放心，他们将获得固定预算的一切。

最初，竞标是时间和材料。由于他们希望有一个固定的价格出价，因此我们建议以我们给他们的价格工作，并使用25％的额外故事点来应急。如果一切顺利，那么25％的未用于弥补我们遇到的延迟的部分将用于为客户提供更多功能。

这在很多方面刺激了他们：首先，他们竭尽所能使我们的开发人员能够尽快工作，因为这显然符合他们的利益。我们再也不必等待问题的答案。其次，他们真正了解了故事要点的概念。在项目开始之前，他们已经删除了一些故事，并要求我们估算其他故事。为此，不需要复杂的合同谈判。

我们向他们通报了进展情况，并保持了非常开放的沟通。他们每两周收到一份进度报告：x％的故事点（按预计时间的y％）留下了z％的可用额外故事点。我们的开始有些困难，但是在项目结束时设法赶上了估计，这使得100％的额外故事点可用于额外开发。客户之所以高兴，是因为他得到了他真正需要的一切（这与他最初要求的功能有些不同，他删除了一些功能并添加了其他功能）。

客户也很高兴，因为一切都在预定的时间范围内交付了（他还尽一切可能帮助我们，例如购票，立即回答问题，让用户参加每周分析会议以及使他们参与功能测试）。

我的公司很高兴，因为我们按时按预算交付了产品。我公司也很高兴，因为该项目的成功为更多项目打开了大门。我们甚至在发送给全世界人们的客户月刊中也提到了这一点。

做好估算是项目中最困难的部分，但是提前进行估算会议有助于我们理解困难和风险。它使我们能够根据事实做出估计，并消除了许多未知数。

当客户不在时，在咨询/招标环境中尝试使用敏捷方法非常困难。

如果它们习惯了瀑布式风格，“这是我们的要求，需要多少时间？类型项目，并进行招标，实际上没有任何时间可以说服他们敏捷或其他方法更好。

敏捷有其优势（当然也有劣势），但是坦率地说，客户经常不了解或不在乎背后的细节。

他们想要两件事-成本和时间尺度。一旦您告诉他们，他们便会希望它更便宜，更早。你知道吗，我们想要这一切。所有要求。没有人可以等待或被斩断。

尽管我在各行各业都不喜欢推销员，但不要对推销员太苛刻。那是艰巨的工作。

他们不构建软件，他们大多不知道流行语如何运作。

然而，他们必须根据一些苛刻的要求来提出时间尺度和成本。也许他们有一些技术专家来统治他们，但他们需要进行销售以保持发展。

因此，如何使您的销售人员成功销售使用敏捷开发方法的项目或使用此类方法开发的产品？

通过让您的销售人员将客户带到办公室。敏捷的全部目的是从客户那里获得即时反馈，以便您可以产生他们想要的（不再需要）。带他们进去，问他们想要什么。两周后，将它们带入并向他们展示演示/原型。通过互动将他们出售。向他们展示进度，并说明您想做的这种迭代，以便他们得到他们想要的。

给出所需工作量的估算（毕竟这就是预算），但让他们有权力（阅读：责任）将他们想要的预算纳入预算。

我认为答案是，在大多数情况下，您可能不会。我会尝试将其最初视为您业务的一小部分-可能占20％，而其余部分则采用传统模式。随着时间的流逝，我会尝试将重点更多地放在敏捷产品和客户上，并尝试使这一部分增长更多。

解决此问题的另一部分可能是尝试使用两种方法。与高级管理人员和合同谈判人员一起使用瀑布式方法。例如，“一个允许客户使用基于浏览器的设备和移动电话设备（Apple和Android）维护投资组合并做出投资决策的系统”。或类似的东西。然后将Agile用于开发团队的更详细功能的开发，例如，创建主页，创建登录页面，创建Portolio管理历史记录，创建移动登录等。

另一个想法是让敏捷成为您的与众不同。我知道，即使不是大多数大型组织，许多组织也没有采取敏捷措施。但是大多数（根据我的经验，绝大多数）小公司都是。我认为敏捷正在迅速发展，并且这种趋势将持续下去。这条路线的优点是，您可以将最想做的事情介绍给已经认识到它的客户。随着时间的流逝，这种方法将需要一些工作，并且不能保证成功。

如果您的客户喜欢测试，您可能还会发现一些吸引力。拥有经过良好测试的产品可以更容易地出售给某些客户。我发现在这方面有用的一本书是Adison Wesley Press的“敏捷测试”。

您还可以使用当前事件来支持您的案例。例如，当前（于2012年10月撰写）的医疗保健站点很好地说明了如何不处理上线前两周所需的更改。同样，显然可以通过更敏捷的方法更好地解决明显的工程过度。

联系对您的工作满意的以前的客户。特别是如果它们是瀑布式转换为敏捷转换。至少，不是您的客户的转化者。

他们的推荐（作为客户）将胜过您想说的一切。他们可以比以往更多地解决新客户的担忧和恐惧。

从管理的角度来看，预算和截止日期是项目的业务需求。您需要确保满足这些需求，并且如果您查看企业关于转换的证明，您会注意到这直接出现了。如果您查看开发人员关于切换的感言，您会发现经常没有。