又一次情绪激动、气氛高度紧张的会议，这一次是商议如何让目前这个重要项目“重回正轨”——计划的完工日期早已超了几个星期。所有的这些场景听起来都很耳熟吗？我想说的是，项目超期在任何行业里都是常见的事情。然而，软件行业里看起来更容易出现这种情况。

我们怎么会走到这种地步的？这还要从我们梦开始的地方说起。所有的开始都是精神抖擞、干劲十足。一个漂亮的创意，这次我们发誓绝不会重蹈上次的覆辙，不会犯上次的错误。这次我们告诉自己，这次的计划将会“正确”的执行，不会图省事，也不会中途变更。经常有时候我们会感觉梦想正朝正确的方向前进，设计很成功，每个人都很乐观，外界评论也很好。然后，噩梦开始降临，因为各种打击开始出现。

系统中最容易的部分却耗用了大家全部的时间。一个微小的疏忽就可能意味着当初一系列简单的假设都不再成立。错误的假设产生连锁效应，导致系统设计陷入死局。需要对设计进行修改来纠正这些问题。希望仍然存在，只要付出足够不眠之夜和周末加班，我们仍然能让项目“重回正轨”。

具有里程碑意义的原型终于诞生了，所有人都充满信心，因为原型表现的非常好。外人不知道这是多少个通宵达旦的努力换来的。很快，“小需求”开始出现。通常的说辞都是从“这有什么难的？”或“这真的很简单！”开始，更经典的话是“如果我们能够…那将会太神奇了”。通过交换意见发现，这些新增的小的功能特征不仅看起来“简单”，而且实际可做。当然，你是不会说不的，然而，历史的悲剧即将重演。

现在，你和你的团队终于回到了现实世界，再次查看这些新增需求。在经过了近距离的观察这些看起来“非常简单的功能特征”后，突然意识到它们并不像起初听起来的那样简单。但为时已晚，你已经答应了这些新修改。

“呯！”你的邮箱通知你有了一封新邮件，真是火上浇油，销售已经向客户许诺。销售向客户谈到了这些“简单”的新功能，而客户提出来更多他们想要的“更简单”的新功能。销售照单全收，因为这些新需求听起来比起初那些更简单。


停，不能这么干
在80年代和90年代期间有一个非常流行的运动口号： “Just Say No”，是用来宣传让孩子们远离毒品。不管你是否还记得这场运动，它表达的信息是非常有力的。相似的，我们应该使用同样的语气来面对我们遇到的问题。

当然，我并不是在怂恿抵制任何的需求变更。从我的角度，任何需要编码开发的新增内容我都会用红线划分开。但诸如界面或前端内容的修改不包括在内。

任何新增需求在接受前一定要确定相应的充裕的追加时间。内心里对新需求的缺省反应应该是“just say no”。当然，并不需要从表面上暴露这种反应，可以用适当的外交手段达到这种效果。在项目开始之日，任何一个最初没有规划的“需求变更”都要谨慎斟酌。任何后来新增的功能特征都要坚持这个原则。有了这个原则你很容易说出“不”。因为这是一个标尺，所有人都明白，后加的新功能会耗费额外的时间。把这种压力放在客户和老板的身上，要么延缓完工日期，要么放弃另外一个功能做替换。

结论
有各种各样的原因会导致一个软件项目不能按时完工。项目进展缓慢，程序员持续在高强度压力下工作，这使项目开发时间的预估变得更加困难。程序员应该有心理准备，新增需求的情况肯定会出现。把“just say no”记在心里，多少能预防你张嘴就说“行”的习惯。玩枪很危险，给枪加上保险装置，至少能防止伤了自己的脚。?N篘剉齹汻lQ鳶_NO郪dk譙蕍0<