场景再现
=====================
BOSS：这么巧，你也在这儿喝咖啡。
小   王：是呀，您这是刚刚开完会？
BOSS：嗯，刚刚送走了客户，忙里偷闲，来这喝杯咖啡。
            对了，你手头那个项目结束没？好像延期两次了，没问题吧？
小   王：没问题，就是发生了一些变更，导致了两次延期。
           您放心，所有的式样变更都遵守着CCB（变更控制委员会）制定的流程办事，都是客户签字认可的，同时也会追加相应的成本。
BOSS：延期两次，客户没有什么意见吧？
小   王：没有，因为所有事都是通过流程、程序办的。推迟截止日期都是得到客户最终认可的，客户那边没有什么意见。
BOSS：那就好。

{说罢，BOSS转过身去，皱了一下眉头，渐渐的走去.......... }
=====================  

场景中的亮点，并不是{小王}如何管理突如其来的式样变更，而是BOSS转过身去，隐隐约约感觉到一种潜在危机而皱了一下眉头。

IT界的朋友对“式样变更”一词并不陌生。
如果哪位朋友站出来说 “我经历一个没有式样变更的项目”。
我只能回复到 “这是一个不完美的项目”。

有很多管理者，每一天在纠缠着各种各样的式样变更中，这些突如其来的式样变更会使原有的计划变得“千疮百孔”。有规模的组织会成立CCB，来管理每一次变更请求。CCB负责评估那些被提交上来的变更请求，针对这些变更的目的、要求、项目要素（成本、范围、时间、质量等）和影响来决策是否实施这次变更请求。

正如场景那样，客户答应你所提出的各种要求（项目需要延期、项目需要追加成本），想必多数管理者会像{小王}一样，调整计划、实施计划、监控计划，最后保证项目保质保量的Release就OK了。（我也是多数中的一员）

有一次我接手一个项目，前期做调研时候，我发现客户在业务上对截止日期的要求不是很严格，很模糊，我只是大概知道一个时间范围。
调研结束后，后续的工作就陆续展开，项目起始周期也就定格在这个时间范围内，同时也得到了客户认可。

项目开发到中后期，客户陆陆续续看到了成果物，随之想法越来越多，迫于做出近似于完美的系统，新需求、式样变更便接踵而至。项目组也是严格按照变更管理流程做事。因变更导致的项目延期、成本追加，客户都同意了。我还能说什么 ，“有钱能使鬼推磨” 你懂的。

这种现象在管理学中有一个词 ----- 范围蔓延。
导致这一现象可能有两种情况：
→ 客户在业务上对截止日期的要求几乎没有，同时能给你足够的时间和钱，换回他想要的。
→ 客户已经不再关注这个项目。

当我第一次接触这个词的时候，我很费解。有活做，有钱赚，有何不可。
经历这次项目之后，我才发现 “我是错的。”  

古代有一个典故 “一鼓作气，再而衰，三而竭” 想必大家都知道。
一个清晰的截止日期能给项目成员带来一定的紧迫感，帮助他们明白按时完成各自工作的重要性，只有这样整个项目就能够按时完成。
如果截止日期一而再、再而三地被式样变更所更改，看似无奈，其实团队内部已经渐渐无视项目截止日期了，无论是团队士气还是信任，都是非常糟糕的。后期的任何计划调整都形同虚设，因为他们根本就不相信计划。

无论项目多么复杂、难缠，无论客户多么无知、是否有无业务上的截止日期，我们都要帮组他们做出项目截止日期的估算。
如果错过了一次截止日期，就不要在错过第二次了，因为项目成员没有人会相信你的第三次。

其实我们有很多方法是可以防止 范围蔓延的，比方说，不一定所有的变更、新需求都要必须立刻对应，可以把项目分为一期、二期、三期。最起码，让团队内部知道变更项目截止日期是一个很严肃的问题，一旦失控，失去的不仅是团队士气和信任，还有项目本身。

读到此，场景中“BOSS转过身去，皱了一下眉头，渐渐的走去.......... ”也就不足为奇了。