硬着陆与软着陆-从glide path说开去

发布前30天,一切看上去风平浪静,我不清楚其他人在干些什么,似乎设计稿还在改,测试好像还没介入。。

发布前10天,deadline快到了,大家开始有些紧张起来,测试的bug一下子多了很多,头大!

发布前5天,铺天盖地没日没夜的赶工,工作看起来似乎越做越多,发布越来越渺茫。

发布前1天,一天时间内打了3个版本给测试,快!再帮我看看!这下可以发了不?

发布日,凌晨3点,在众人经历了极端的毅力与体能的双重考验后:同志们,我们如期发布了!!

好吧,我只能说,这是一个奇迹

像这样加班加点赶发布的情况,在我周围还真不少见。项目进行过程中,各种问题各种状况都在一个黑盒子里发酵着,没有人注意到这一切,直到发布前,在进度的压力下所有大大小小的问题终于爆发了,结果很有可能造成整个项目的失控。

 

硬着陆与软着陆

如果我们把项目中里程碑开始到结束的全过程比作一次飞行,上面的场景无异于一场惊险万分的紧急迫降。一次两次猛冲或许还撑得住,久了,不残废也得“内伤”。这样的状况,我们称之为“硬着陆”。

好的着陆,会让飞机处于容易再次起飞的状态,例如,机翼还在,起落架正常,还有最重要的,机上乘客都还活着:)

 

如何实现软着陆?

飞机在降落之前,会由无线电波束标出飞机下降航道(称之为glide path),即一条由跑道指向空中的虚拟路径,用来引导飞行员着陆。Glide path帮助飞机沿正确方向飞向跑道并且平稳下降高度,最终实现安全着陆。

项目里程碑的发布也是一样,要实现“软着陆”,你可以分三步走:

第一步,你需要一条glide path(也称burndown chart燃尽图)来引导着陆过程。我所在的项目中,我们会根据里程碑中的计划来确定这条基线。项目成员按照计划设置任务的预期完成时间,系统会帮你自动生成这条基线。一般来讲,抛物线会更符合实际。如果缺乏相关信息,可以用直线来简化代替。

 

第二步,你需要个灵敏的仪表盘(dashboard),能敏锐捕捉到过程中任何微小的偏差,并直观地显示出来。相对于我们预期的glide path,实际情况到底比预期要糟?还是变得更好了?

我所在的项目中,我们使用QA平台来作为这个仪表盘,里程碑中每天的实际任务走势会自动显示出来。

下图是一张真实的任务走势图,信息直观透明,且对所有人公开。其中,“实际任务走势”与“计划任务走势”的对比,可以衡量出计划与实际的偏差。绿色的“新增任务走势”表示新引入的工作量,此部分变量有可能是导致偏差的原因,可作为参考。

  

第三步,周期健康检查,并及时调整轨迹。

优秀的飞行员知道,当飞机变得不稳定时,任何控制与调整,都可能会引发这个复杂系统中各种力量的相互作用,造成不可预期的结果,使情况更加困难而危险。因此,降落前飞行员与塔台调度员会不断check飞机的各项信息,第一时间识别那些可能的风险,确保一切在可控范围内。

优秀的项目管理,要事事领先一步,在开始时就尽可能避开这些情况,将风险扼杀在摇篮里。要做到这一点,需要不断check项目各项指标。对于那些健康检查中发现的偏差,去问那些每天在一线工作的人,怎么做才能预防或避免风险的发生,砍掉一些功能?理清一些目标?少一些干扰?多一些资源?多一些时间?还有什么?努力寻找答案,并付诸实施。

评论

© 蓓蓓—PM的修炼 | Powered by LOFTER