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

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

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

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

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

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

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

还有个血泪教训，永远别忘了那些被你砍掉或者简化了的功能。我们经常会在达到最后期限之后，就只记得继续前行，而不记得去捡起那些为了赶工而牺牲了的功能或者体验，结果就是打造了一个满是伤疤的不完美不精致的产品。所以，要在范围缩减时，及时做好被缩减掉范围的需求管理，制定计划把它们补上！

面对这些百宝工具，您有没有下述疑问？问：质量可以被缩减吗？

前面的工具里，既有“时间”缩减的工具，也有“范围”缩减的工具，那么，“质量”可以同样被缩减吗？

这个问题的答案并不是一语概之的。一般来说，互联网产品的终端用户就是千万网民，所以，并不存在可以妥协的产品质量。因而“质量”往往是我们最谨慎去碰触的缩减维度。但这个问题并不是绝对和毫无商量余地的。比如，针对运营后台，因为用户是运营管理员，用户数有限且是内部可控的，我们可能可以只覆盖主路径测试即可。在项目经理的百宝箱里，有一些宝贝是带着“邪恶”力量的，它们的使用可能会造成比较严重的负面效果，质量相关的工具就属于这类，轻易不用。

问：你怎么不说加人？

不可否认，不少项目是靠加人来赶进度的，但这并不是一种可以推广的方法。少量加熟练工，确实可以缓解部分进度压力。但单纯希望靠增加人数来缩短工期，无疑是个焦油坑，我们的项目曾经就遇到过短时间内加了两倍人，但生产率反而降低的情况。而附加带来的归属感、团队文化、沟通问题，更是让项目根本无法前行。

问：如果还是赶不上进度呢？

即使机器猫本领万千，康夫依然可能通不过考试。同样的，即使项目经理使出浑身解数，即使团队很拼命，可能项目延期依然难以避免。那是不是项目延期就意味着失败呢？我们是不是依然有办法让项目“成功”起来呢？我们是不是依然有办法让合作方满意呢？

其实有一套方法是万变不离其宗的有效工具，无论延期能否避免，我们都能够让路走得更顺一些。那，就是，过程同步——风险预告——及时坦诚。这是伴随着时间管理的很重要的沟通管理。

过程同步：是为了让重要干系人了解项目进展以及团队有效的工作。大家在同样的进度信息面前，讨论问题有了同样的前提，也更容易让干系人或者合作方和团队能够站在同样的战壕里共同应对问题。

风险预告：我们并不需要粉饰太平，尤其在挑战性项目面前。相反的，干系人或合作方的心里同样有风险的问号，及早把风险预告出来，可以建立大家类似的心理预期，也为未来的紧急预案实施做好了准备铺垫。

及时坦诚：风险监控显示风险即将显现时，不妨及时、坦诚地和干系人或合作方沟通。当然，必须有前两步的铺垫和沟通，这时坦然启动紧急预案即可，即使是延期的预案，大家也是有预期的和可接受的了。

压箱宝贝

接下来，压箱底的宝贝来啦！就是三个字：稳！悲！乐！