软件项目经理新手上路(8) - 最后期限的迷局

最后期限是每个项目经理都绕不过去的坎儿。

1. 小故事

张莉是新鲜出炉的项目经理。在二月底春节后,张莉开始了C项目,C项目是一个大项目的组成部分。三月初,领导确定大项目的交付期限是4月中旬。张莉愁坏了,项目的流程、人员、技术等等都是全新的,她完全没有把握保证项目的交付。导师张三给她出主意,不妨先接受领导4月中旬交付的目标,但是将目标进行分解,每半个月检查一下能否达成目标。张莉每半个月向领导汇报实际的进度和遇到的障碍。4月中旬,C项目也没能如期完成,整个大项目没有如期完成。领导提出了新的最后期限,5月中旬,转眼5月中旬就要到来,但是C项目又被卡住了,最后期限无法达成。

2. 常规想法

最后期限让我想起了一个经典的问题。如果你是项目经理,现在项目组没有能力在最后期限前完成工作,你是:

1. 优先确保项目,牺牲人

2. 优先确保人,牺牲项目

3. 项目与人两者兼顾

对大多数项目经理而言,项目是他服务的主要对象,当然是优先确保最后期限的达成了,加班就成了一种常见的手段。当然,这也是很多老板们的最爱,尤其是在不用付加班工资的时候。于是项目紧迫,加班不断成了IT业的常态。

3. 继续思考

的确存在最后期限,把加班作为一种有效的备选,偶尔用用是合适的。但是把项目与人对立的想法其实是可笑的。所谓项目和最后期限,无非是客户、老板或者市场人员的期望而已,依然是人的问题。

不合理的最后期限往往体现成一种问责文化,最终会导致局部优化。项目中的成员只对自己的范围负责,完成了自己的工作就安全了,整个项目没有完成也是别人的问题了。在最后阶段出现问题的时候相互推诿,害怕承担责任。最终会损害项目完成的质量,并且导致团队士气低迷。

不合理的最后期限还导致沟通的减少。人们倾向于使用文档来明确范围和责任,从而导致更多的文档工作。而利用文档作为主要沟通工具将导致大量的误会,从而造就大量的浪费。所以结果是项目越来越慢。怎么办呢?简单,领导为了改变这种情况,会提出新的最后期限给项目团队加压,从而导致更多的加班。上述的C项目中,领导试图制定最后期限加速产品的开发,最后并未能达成目标。

4. 参考案例

4.1 参考案例1

这是我创业时真正意义的第一个项目。新技术、新产品、第一次项目实施等诸多新情况导致上线时,整个进销存系统仅有出库单可以工作,而且内部的账务数据还是错误的。怎么办?最后期限已经来临,只有硬着头皮上线。我们整个团队驻扎在客户现场,有时甚至通过手工修改数据的方式来保证客户业务单据(仅一张出库单)可以使用。好不容易熬到下班,团队还必须加班处理整个过程中暴露的问题,并且准备客户将要使用的新功能。客户的中层和基层人员抱怨连天,好在领导还在坚持(领导后来说,当时也是麻起胆子)。整整一个月时间,加班加点,经常通宵,项目终于能够正常运转(从外部看不出什么问题,内部的数据还有很多问题)。

这个客户后来成为了公司最坚定的客户,在维护和升级过程中合作良好。当然最后期限不能达成失败例子更多,这里不一一列举。

4.2 参考案例2

C项目采用Scrum方法学进行开发,早早的确定了第一次发布的最后期限和需发布的主要功能。随着时间一天天的临近,项目组的开发进度不如预期。产品负责人和团队商量,原有主要功能不变,但是功能的实现方式尽量简化,以减少工作量。即便如此,第一次发布前项目团队依然加了两次班,并且减少了平时的交流,专注于功能实现和Bug修复。终于产品还是顺利发布了。发布后,项目组改回了正常的工作方式,并且花了一些时间清理因为要尽快发布而导致的技术负债。

4.3 参考案例3

R项目是一个持续了很多年的项目,本质上是在一个大的系统上修修补补,优点是客户按照工作时间来付钱。其工作方式是客户提出Bug或改进需求,项目组进行预估并提交估算文档,客户批准文档后确定最后期限,项目组必须按期发布。项目组倾向于估算得较长,这样可以多收钱,当然也要通过客户审核才行。偶尔出现需求不清,估算太短的情况就只能打落牙往肚里吞了。

项目组有无数的规范,并倾向于制定更多。项目组中问责文化流行,相互责任推脱更成为家常便饭,无论是员工还是客户都疲惫不堪。

posted on 2011-05-10 14:53  大卫张  阅读(4035)  评论(17编辑  收藏  举报

导航