项目时间的估算对项目的成败至关重要。项目时间管理包括了项目按时完成所需的各个过程。但是,在实际项目中,经常出现项目延期,估算严重不准确的现象。
一个我曾经共事过的很有经验的项目经理曾宣称说,他会拿程序员估计出的时间乘以π值,然后再提高一个数量级,这样得出的才是正确的开发所需要的时间。1天时间经过变换后是3.14周。他经过惨痛的教训才认识到程序员预估的时间都是不靠谱的。为了能更精确的对程序员估计的时间进行换算,我创建了一个时间换算表,重点说明究竟是什么地方出了问题。
估计时间程序员的思考程序员忽略的事情真正所
预估时间本身就很难。每个程序员的估计都会跟真正需要的时间有些差距。估计时间短了说明有些事情被忽略了(编译,测试,提交代码)。估计时间超了说明任务太大,难以理解。
对于资历较浅的程序员,这种估计误差是混乱的,他们经常会轻视一些任务,同时又对一些稍微有难度的任务过分高估。我认为,对一个有经验的程序员,一个任务的时间应该在半小时到24小时之间,超出24小时的任务都需要拆分。程序员在脑中想一想可能会认为要60小时,但实际上即使是很有经验的程序员也需要将任务分成可控的模块再来分析做决定。
还有一个很重要的需要认识到的一点是,编程上的经验并不等同于时间估计上的经验。一个从没有做过工期估计的程序员不会擅长估计时间。如果不去拿真正需要的时间和估计出的时间进行比较,你不可能从其它反馈信息之得到正确估计时间的经验。
每个程序员都会用到评估技巧。为了提高你的这项技能,你可以在你从事的每个任务上进行锻炼。在任务开始时先预估开发所需时间,拿它跟你最终真正用掉的时间进行对比。这样,你不仅在对任务细节的理解上有提高,同时也提高了你对时间预估的技能。
项目时间估算其实是有章可循的
总结起来我觉得,对时间的预估与风险的控制关联非常密切,预估时间长短根据风险进行评估;比如,项目实现技术复杂度,人员状态,人员到位情况,资源到位情况等。当然预估时间还要考虑其他很多因素,比如成本,质量等因素。
预估完时间后在实际项目推进过程中,项目经理充当的更应该是一个实时监控、纠偏的角色,根据掌握的项目进度情况,提前预知风险,并采取必要的措施,使项目按计划平稳的向前推进。
简单总结下。抛个问题,项目管理过程中,由于技术复杂度评估不足或者需求变更导致项目延期,你作为PM会怎么去处理这种情况呢?