软件项目经理新手上路(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或改进需求，项目组进行预估并提交估算文档，客户批准文档后确定最后期限，项目组必须按期发布。项目组倾向于估算得较长，这样可以多收钱，当然也要通过客户审核才行。偶尔出现需求不清，估算太短的情况就只能打落牙往肚里吞了。

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