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

2017-05-23

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

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

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

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

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

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

  百宝工具1. 负荷度

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

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

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

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

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

  百宝工具2. 计划缓冲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  面对这些百宝工具,您有没有下述疑问?问:质量可以被缩减吗?

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

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