分阶段赢得时间却暗藏灾难

　　如果我们换一个做法，在系统实施阶段，按照模块的二次开发工作量的大小、需求的重要紧急程度等因素来划分阶段，把领导重视的、二次开发工作量小的模块放在前面实施，领导次要重视的、二次开发工作量大的模块放在后面阶段实施，可能会收到更好的效果。

　　因为领导重视程度与二次开发工作量大小两个维度没有必然相关，既可能领导重视、二次开发工作量大，也可能领导重视、二次开发工作量小，因此具体划分阶段时，必须根据企业的实际情况权衡。

　　现在假设一个项目有5个模块，把模块1、2这种领导最关注的并且几乎没有二次开发工作量的模块实施作为第一阶段，把模块3、4这种操作层关注、做少量二次开发就可以应用的模块实施作为第二阶段，把操作层很关注、但因与现有业务模式完全不同而需大量二次开发的模块实施作为第三阶段。如下图所示：

　　从图示中可以看出，每个阶段的末期都会有用户测试，这样整个实施过程中，用户始终是参与在项目当中的。一个阶段开发完成后，用户即可开始测试，用户最长的松弛时间是10月20～11月12日，22天，比起不分阶段60天的松弛时间，少了近2/3的记忆衰退期。

　　如果用户测试的过程中，供应商有足够的人力进行下一阶段的开发，那么时间示意图还可以成为这样：

　　从图示中可以看出，赢得了松动时间10天。

　　所有的方法都有正面和负面的效果，分阶段实施也不例外。它最大的问题就在于系统重复构架。因为客户试用后提出的需求是分阶段被描述的，后期提出的需求对前期的构架很可能有比较大的影响，这就存在一个反复构架、反复衡量影响已有模块的风险。

　　规避这种风险，要求供应商在合同之前的，就能对企业的业务深入理解，考虑到可能发生的变更，并有高水平的构架工程师一起设计出有足够柔性的框架，避免后期需求变更对框架的影响。一旦构架不够柔性或者需求变更大且多，分阶段实施的弊端就会给项目带来灾难性的影响。

　　因此，选择是否分阶段实施，需要事先有足够详细的规划和风险评估，请读者慎重选择。