我们都知道，日程安排只是估计而已，不过是大概猜测罢了。项目日程是对于团队何时到达哪个里程碑、何时完成项目的最佳推测。日程安排并不是预言，仅是猜测而已。但是有些项目经理的出资人会将这个猜测视为承诺。
如果面对上述困境，可以问问如下两个问题：
- 你是否关心团队交付的东西？
- 你是否关心产品的质量如何？
要想让有关项目日程的谈话富有成效，就得讨论项目后面的驱动因素、约束和浮动因素；应该商量在截止日期之前，至少有哪些功能是必须要交付的，这些功
能应该达到什么样的质量标准。如果相关人员还没有准备好讨论项目日程、功能集合和缺陷水平，那么任何关于日程应该作为承诺的讨论都显得为时过早。
当资深管理层希望得到承诺时，我喜欢用信心水平与他们沟通：“我有90%的信心在8月1日发布。如果允许在10月1日交付，我有100%的信心。”我会告诉他们这两个信心日期之间我们必须要做的事情，也因此而深入理解了将日程作为承诺对我来说意味着什么。
我还喜欢使用“逐步逼近的日期（date-for-a-date）”。“我可以告诉你，下半年发布没问题。现在我可以把时间限制在某个季度（给出一个日期），然后可以限制在某个月（另一个日期），接下来（给出另一个日期）就是我们要发布最终版本的日期。”
不过我最喜欢的技巧还是使用有时间盒限制的迭代（持续两到四周，不能更长了），同时使用按优先级排好顺序的待办事项列表。这样的话，就可以应对任何
时间的发布要求。项目经理明白，每个迭代的成果都可以投入正常使用。项目经理也知道，最重要的需求已经先实现了。如果管理层想发布，没有问题，因为产品已
经整装待发。开发人员不必再做出任何承诺，反而是项目经理需要从提供需求的人那里得到承诺，因为他们要说明哪个需求在何时需要。
如果有人要项目经理承诺一个日期，那就考虑如何组织项目吧。试试用迭代，或者尝试用“逐步逼近的日期”，要不就用带有日期估算的信心水平吧。但是不要只承诺一个日期。这简直就等于是为墨菲敞开大门了[1]。你可以承诺一个日期，但是总会发生一些意外，让你的承诺变为水月镜花。
[1] 作者此处是指墨菲定律（Murphy’s
Law）会发生作用。——译者注