迭代开发方法

       到目前为止，我们讨论的两种方法在于CRM实施时均存在一些限制。根据我们的经验，在实施过程中，最可能失败的地方是缺乏用户的认可。瀑布方法所面临的一个挑战是，这种方法必须完成一个阶段，才可进入下一个阶段，因此，项目团队需要编写出极为详细的设计文档。此类文档根据终端用户的信息编写，并在开发阶段之前进行审核。最后，用户群再次看到应用程序时就已经到了用户验收测试阶段，因此这种方法所做出的一些假设和权衡可能会令用户感到意外或失望。

       许多CRM实施会包含很多功能，与Scrum方法相关的简短设计和快速开发周期很难满足用户对初始实施的期望。即使是最小型的CRM实施也需要持续若干个星期，而较大型的实施周期则长达6到12个月，甚至更长。此外，Scrum项目的一个关键前提是对用户进行新功能的概况演示，而不是完整的用户培训周期。对于大多数初始实施而言，安排大量时间向用户讲授应用程序的相关信息（包括它如何帮助用户更高效地完成工作）是至关重要的。

       由于很多方法都存在上述限制或其他的限制，因此，我们通常会在项目中使用迭代开发方法的派生方法。这类方法往往被称为迭代和增量开发方法。这种方法的理念是在更短的周期内（增量），通过重复（迭代）设计过程循环开发应用程序。形象地讲，这种方法与瀑布方法非常相似，但有两个关键的区别：

       应用迭代开发方法时，阶段之间会相互重叠。许多在某一阶段需要完成的工作，都可以在上一阶段结束前开始；

       在设计阶段，迭代方法为实施团队提供了一种机制，用以收集需求、构建或配置应用程序模块，然后再重复此过程。实施团队可以根据需要多次重复这些迭代过程，以便从用户收集到足够的反馈信息。

       阶段会互相重叠，因此在某一阶段尚未结束时，即可开始另一阶段的任务。由于迭代这种方法的设计阶段通常比其他方法更长。此外，一般来说，其纯粹的开发阶段也会更短，因为一些开发和配置是在设计阶段完成的。

       迭代流程应该快速让最终用户体验应用程序。这样可以确保实现以下目标。

       得到用户的认可：通过应用程序让用户参与进来，能促使他们为最终的结果进行更多的投入。此外，由于设计周期的扩展，项目的发展势头可以持续到最后。

       准确的需求捕获：使用迭代流程，用户和实施团队将有机会在确定需求前，进行多次审核和变更。这种方式不是创建一份设计文档，然后寄希望于文档能够准确捕获所有需求，而是在尚未完整定义最终结果之前，先让用户看到最终结果。

       保持设计与开发的一致性：让这两个阶段有很大部分的重叠，可以在整个开发过程中保持更多的一致性，并提供检查点。

       正如本节开头所述，许多公司在技术实施中都会有一种经常使用的方法。只有这种方法可以调整，使用户及早并经常看到应用程序，那么这种方法未尝不可。

       计算投资回报率（ROI）

       计算和衡量CRM项目的投资回报率是一项极具挑战性的任务。很少有公司能够成功评估如员工生产力或有效性等前期和后期指标。通常，缺乏评估这些指标的能力正是导致实施失败的一大原因。尽管如此，为了公司中领导层的利益，也为了向用户传递信息，应该确定几个指标在后续部署过程中进行跟踪和报告。

       为了确保没有遗漏，在部署之前，利用一些时间找出要跟踪的重视项，以便保证项目最终成功完成。