别不拿里程碑当石头---------IT项目管理之项目计划(转)

如果说做项目不需要计划,恐怕没人会认同。是否每个项目计划都起到了作用呢?却不尽然。知道要做计划,但不知道为什么做计划,如何做计划的还是大有人在。所以很多计划沦为依样画葫芦,成了摆设。

IT项目计划的用意其实非常明确。因为我们无法事先知道系统最终会长什么样,和用户想象当中的是否一致,和用户的需求是否匹配,我们就需要通过一个计划,从需求,到设计,到测试最后做出来。每前进一步,都要保证不再返工回前一个阶段。如果一个计划不能起到应有的作用,项目都会在原地逗圈子。而这点绝不是靠某个天才的系统就能解决的。因为一个IT系统在完成之前,没人知道它到底长什么样,大家就不得不借助一些想象。即便有一些原型或者样板,也只是窥一斑而想象全貌。而群众的想象力是无限的。

其实乔布斯给人们的苹果,并不是人们想象中想要的东西,也不是超出你想象的东西。他给的是一个载体,一个窗口。通过它找到各自想象的东西。从而满足了人们的多样性需求。IT系统里也存在这样的系统,即工具层面的东西,随便你怎么用,但不要提要求。对于面向特定需求的系统,我们所做的就是先找到一个大体适用的方向,然后一起奔着这个方向走,且要不逗圈子或少逗圈子。

曾经遇到一个项目,每次项目回顾会上,都有一堆问题。很多问题都说不清楚需要花多少时间解决。还有一些问题,有了解决方案,也有了实施计划。但是,每每问起对整个项目进展有何影响时,项目经理都信心满满地说“没影响”。一次两次也就算了,后来明明某个任务推迟的不像话了,怎么还说不影响项目上线呢?让项目经理把里程碑计划展示一下,这才发现,这些有问题的任务都不和里程碑节点相关(所谓不在关键路径上),以至于都推迟到后一阶段,后后阶段了,还是不用调整里程碑计划。

---那确实需要推到上线时间点以后的问题呢?有这种事情吗?

---有!

---那如何不影响项目上线?

---放到上线后完善阶段了

做了十多年IT项目的我,一时间没听懂,上线后完善是个什么玩意。 只见过上线后支持,哪里又出来个上线后完善呢? 

后来才明白,这个项目计划,除了里程碑时间节点不变,其他都在变。凡是不能按时间完成的任务,都推迟、推迟,等推倒上线节点也兜不住了,就上线后再去完善了。

听懂之后,真有种想骂人的冲动。这是做项目吗?这不就是脚踩西瓜皮吗? 整个一个不拿里程碑(milestone) 当石头。当它不存在,透明的,一概穿越。 最后完全是以任务节点构成的网络结构图在管项目进度,而没有了项目阶段的概念。

也许是为了心里安慰,因为有任务被推迟,项目经理又把能早安排的事情就提前安排了做。问题是,很多事情如果不是在里程碑节点上有个清楚的交代,那些提早做的事情完全有可能返工重做。比如开发还没结束,就安排一部分用户做试运行(pilot)。 如果开发完成后,有些地方又调整过,那么pilot小股部队就被牺牲掉了,成pioneer先驱了。 

至于那些所谓上线后完善的事情更是后患无穷。等到项目都剪彩、放鞭炮庆祝成功上线了,谁还会管完善不完善的事情呢。比这更糟的结果是,这“完善”最后成了没完没了的终生事业。那也就不叫项目了。

其实,项目里程碑节点就意味着质量门。在某些情况下确实会让步放行。但让步的时间和内容都是有底线。这个底线就是,让步放行的东西我是可以不要的。到总体验收的时候,确定无法完善了,也就认了。没有这个共识,就不可以让步放行。

IT项目其实就是从粗到细的设计,从细到粗执行。制定计划时,先做里程碑计划,明确大阶段目标。而明细计划只要做到当前阶段,所谓的“渐进明细”。不要急着把最后一天做什么都想好。但一定要从第一天就知道最后一个阶段的目标。

等到计划执行起来则从细到粗。在最细节操作层面的事情,需要反馈到最上层的里程碑计划中,以确定里程碑是否需要调整。在上文的案例中,常常是某件具体的事情都有计划了,比如项目上线时的数据迁移(通常是指未完成的业务操作,例如未关闭的采购订单等)计划。但这是一个个孤立的任务计划,和里程碑计划的关系完全忽略。而作为一个项目,因为其独特性,非常有必要把网络化的任务关系分派到各个大阶段上,然后在里程碑节点上进行“前进还是后退”的评估。里程碑是项目进程中真正的基石,打下桩,就可以继续向前,不再回头看。

上一篇:UBUNTU 16.04 编译 OPENJDK8


下一篇:sql server 查询表的创建时间