2010年我受邀参与一个团队的交付过程，看看是否能够帮上忙，做出一些改进。进入的时候大概是2月，当时团队士气还不错，在长达6个月以上的开发之后，3月份很快团队就面临第一次上线了。然而技术上仍然存在若干问题，客户方的IT技术设施似乎也没有准备好。第一次上线毫无疑问的延期了。夏天到了，计划中的第二次发布由于技术上遇到难以想象的挑战，又延期了。秋天到了，情况没有变得更好一些，由于发现技术上的挑战，测试遇到了传说中Bug不收敛的情况，QA完全没有信心发布版本。冬天的时候似乎看见了曙光，技术负责人也放了狠话，说如果发布不了我就不干了。第二年春天，终于上线了；技术负责人也不干了，先后还有五六个团队成员也离开了。

作为软件项目而言，出现延期的原因可能千变万化。计划不合理固然是其中一方面，但一旦发布日期固定，那么剩下的事情就应该是全力以赴面对这个目标。一鼓作气，再而衰，三而竭。战场尚且如此，极端依赖智力劳动者全心投入的软件开发行业更是如此。虽然团队中有许多的方式能够增加凝聚力，但最能够激励的，莫过于自己写的代码能够被使用。处于某种原因延期，带来的不仅仅后推的日程，还有开始懈怠的斗志。

如同病毒一样，延期会传染。一旦接受了延期的理由，同样的理由可能不被继续使用，但其他的理由会突然冒出来，目的只有一个，无法在目标日期完成。09年我参与了一个超级复杂的电信电子商务网站，也经历了延期。第一次是因为服务器通过海运需要28天……第二次是单点登录集成花费了远超想象的时候。到第三次的时候，无论如何都应该上线了，结果商务上出现了别的问题没有上线。

这些真的是阻止上线的原因吗？除了服务器原因之外，现在想来，单点登录真的并非是非要不可的特性。通过改善之后的网站吸引流量，重拾用户信心，似乎更重要一些。然而，真实情况是，一旦延期成为一个可以接受的理由——也许所有人并不承认这一点——那么其他的原因，会被以各种合理的方式加进来，造成一次又一次的延期。于是，延期就像不曾变缓的滑坡，交付就像轮子，越来越快的，滑向无法交付的深渊。

在开发行易产品的时候，我设定了一个时间：7月15日，也就是下周一。越靠近这个日子，想要在这个日子发布越发显得越艰难。我们甚至在本周一，也就是上线的前一周决定将整个网站设计全部改掉。设计师在嘀咕，程序员们也在嘀咕，我自己也在嘀咕：7月15号上线，可能吗？

然而却看到了设定明确日期的情况下，做决策显得更加的注重实效。我们清楚的知道上线并非意味着结束，只是开始。那么哪些特性应该包含在这个发布中，哪些可在稍后调整？当你只有几天时间剩下的时候，答案往往是不言而喻的。

离7月15日还有两天。我们真的能发布吗？我自己也想知道答案。