当项目管理遇上最后期限，我们可以做些什么？

2017-06-05 21:40:00

老大说，我们要做个新功能。还没定下来到底做成啥样，就已经定了个上线时间，还是个不可能的最后期限。所以，直接倒退时间就得了，还做啥估算啊，然并卵啊。这场景好熟啊！不过，办法总比问题多。当项目管理遇上最后期限时，我们可以做些什么？与您分享时间管理的百宝箱。

时间管理百宝箱

在拿出工具宝贝之前，咱们先讲个基础项目管理概念，那就是项目管理铁三角：时间——范围——质量。最后交付的产品，由这三个方面组合决定。而这三个方面，本身又是此消彼长的关系，比如，削减项目时间，势必带来产品范围的削减或者质量的下降。

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

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

百宝工具0. 真的是最后期限吗？

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

百宝工具1. 负荷度

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

我们曾经提过 “透明” 的力量。

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

除此之外，用白板和每日站会，并且每天在popo群上贴出燃尽图来展示进度偏差。看到大家会因为进度落后而纷纷喊着“好紧张啊”，看到大家会因为赶上进度而感慨“执行力爆棚”，你就会觉得大家的士气被无形中调动起来了。

在“透明”的执行方式下，直接的作用就是团队负荷度提高了。在紧急项目A中，启动之前团队的负荷度在90%-100%之间，而两个迭代下来，团队负荷度一直是超饱和的，分别达到了112%和117%。当然，超饱和的工作负荷是特殊时期的短期状态，也是应对特殊项目情况下不得已而为之。

百宝工具2. 计划缓冲

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

大家对缓冲容易有几个误区：

因为有缓冲，所以开发是否认真估算就不重要了，大不了用缓冲！
项目时间压力太大，太紧张了，没余地留缓冲！
上次的缓冲我们没怎么用，这次我们也不用留了！

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

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

在紧急项目A中，我们在计划里做了两层的缓冲设置。首先将整个产品一期开发分成了7个迭代，平均每个迭代5-10个工作日。第一层缓冲留在了各个迭代内部，比例是20%-30%，主要目的用途在于承载需求蔓延以及全新系统的联调风险；第二层缓冲留在了第四个迭代之后，设置了一个缓冲迭代（见下图），用以承载可能的系统优化需求。这主要是因为产品是全新系统，在前期风险识别时，认为对全新系统的需求分析和策划交互很难一步到位，需要留有调整优化的空间。这其实本身就是一项风险应对的措施。

不要因为本身时间就不够了而忽略缓冲，这并不是在解决问题，而是在回避真正的风险。

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

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

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

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

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

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

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

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

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

面对这些百宝工具，您有没有下述疑问？

问：质量可以被缩减吗？

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

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

问：你怎么不说加人？

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

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

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

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

过程同步：是为了让重要干系人了解项目进展以及团队有效的工作。大家在同样的进度信息面前，讨论问题有了同样的前提，也更容易让干系人或者合作方和团队能够站在同样的战壕里共同应对问题。
风险预告：我们并不需要粉饰太平，尤其在挑战性项目面前。相反的，干系人或合作方的心里同样有风险的问号，及早把风险预告出来，可以建立大家类似的心理预期，也为未来的紧急预案实施做好了准备铺垫。
及时坦诚：风险监控显示风险即将显现时，不妨及时、坦诚地和干系人或合作方沟通。当然，必须有前两步的铺垫和沟通，这时坦然启动紧急预案即可，即使是延期的预案，大家也是有预期的和可接受的了。

压箱宝贝

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

对于“时间”这个问题来讲，项目经理事实上是团队的依靠所在。而只要项目经理做好了上一节所说的“ 过程同步——风险预告——及时坦诚 ”，那么，天其实是塌不下来的，也没有什么坎是无法逾越的。因此，项目经理必须有一个“稳”的心态，让团队相信，有你在，没问题！

在“稳”的基本心态之上，项目经理要具备：以“悲”观的心态看风险，以“乐”观的心态对团队。时间管理的问题，归根到底是风险的问题，项目经理应该是谨慎的全面的风险识别者和监控者，并为之尽早制定各种预案；同时，对团队所承受的压力应该有所把握控制，在展示风险“施压”的同时，善于观察团队状态，及时给出舒缓，确保团队乐观前行。

压箱宝贝，说到底是项目经理的修炼所在，及时观察分析能力，又是经验判断，更是平衡把握，实属不易。