首先讲一下项目管理铁三角：时间——范围——质量。最后交付的产品，由这三个方面组合决定。而这三个方面，本身又是此消彼长的关系，比如，削减项目时间，势必带来产品范围的削减或者质量的下降。

因此，首要的是明确对产品来说，这三个维度的重要性排序，也就是产品最看重的到底是按期交付、还是稳定的质量、还是确定的范围?这样，在遇到时间管理问题时，我们才能对工具做取舍，来选择最合适项目的工具。

我们以紧急项目A为例进行具体讨论。

百宝工具1.真的是最后期限吗?

　我们习惯于被给定一个命题，而不去质疑这个命题是否成立。无论是否能够改变命题，我们至少应该问一下“为什么”。并且可以尝试去做一些争取，了解所谓的“保守底线”和“真实底线”。大多数合作项目中，看起来需求方设定的交付时间是最后期限，但沟通具体的方案以及实际用途后，往往会发现是有余地的。不争取，你怎么知道那就是“最后”的期限呢?

百宝工具2.负荷度

在我们准备任何时间管理措施之前，我们需要先来看看团队目前的工作负荷。如果大家都处于相对宽松的工作负荷情况下，我们一上来就开始砍范围压质量，显然没有说服力。但是，要让大家开始齐心协力开始奋斗，也不是项目经理一两句话就能鼓捣起来的。

“透明”，就是从项目背景、目标，到项目计划、进度过程、风险问题等信息，都和团队共享。了解了项目的重要性和紧迫性，看到了具体的项目计划，实时了解了我们的进度位置以及和计划的偏差，很多东西就不用再多讲了，大家都懂的。先是把全体项目成员都喊来开了个项目启动会，项目总监从商务背景到价值意义，再到可能的影响和布局，都给大家做了介绍，也做了现场的问答解释;之后，向大家介绍了项目计划和执行方式。会后，你可能会发现，自己的具体计划还没发出邮件，大家已经纷纷行动起来开始准备了。这就是“透明”的力量!

百宝工具3.计划缓冲

项目经理做计划的时候，并不是简单的把大家的估算做个合计就可以了，必须根据产品和团队的实际情况，考虑项目风险状态，留下一定的缓冲。

大家对缓冲容易有几个误区：1)因为有缓冲，所以开发是否认真估算就不重要了，大不了用缓冲!2)项目时间压力太大，太紧张了，没余地留缓冲!3)上次的缓冲我们没怎么用，这次我们也不用留了!

缓冲究竟是用来干什么的?它既可以用来应对无预期的请假情况，也可以用来承载需求蔓延或需求变动引起的任务增加，也可以用来对冲因前期调研不足而导致工作量加大的任务等等。

缓冲的预留量因团队和产品各异，我们的一般经验值是20%-30%。

百宝工具4.范围缩减预案

在完成了上面两步基本计划的制定之后，才开始真正的考虑最后期限可行性问题。通过对业务、技术、后勤三方面风险的完整考察后，在规定时间内完成既定范围的风险被列为了项目A最高的三项风险之一。因此，必须为这项风险预留一定的紧急预案。

在时间被限定死的前提下，大家都很容易想到一个方案，那就是范围缩减。于是，分析了现有的产品需求，和策划讨论了分批实现的可能性。之后，在与合作方的需求确认会上，就提出了这一风险，以及建议制定应对风险的紧急预案：部分用户2个月之后才会用到的功能延后到二期实现。合作方欣然接受了在风险情况下启动预案的提议。

系统往往是越完整越好，但面对风险情况下的预案准备，往往会发现系统事实上是可以被分解的。那么计划的安排可以对应做些准备，预案中可能被缩减的模块，可以放到晚些的迭代来做，这样可以在前期更好地对风险状况做个判断，并为预案的启动留下了空间。

百宝工具5.需求简化预案

缩减了范围，但看上去还是做不完，怎么办?我们还有宝贝吗?

我们又仔细研究了需求，发现其中部分模块是系统运营所用，并非终端用户所用，也就意味着，功能是必须的，但是，方案可能是可以简化的。于是，和策划做了讨论，又追加了简化运营系统的紧急预案，同样在沟通后得到了合作方的理解。

所以，面对“范围”维度，我们能做的不仅仅是“砍”一个字，也许还有“化繁为简”的方案，原则是尽可能去挖掘那个真正的“最小集”。