***期限是每个项目经理都绕不过去的坎儿。
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或改进需求，项目组进行预估并提交估算文档，客户批准文档后确定***期限，项目组必须按期发布。项目组倾向于估算得较长，这样可以多收钱，当然也要通过客户审核才行。偶尔出现需求不清，估算太短的情况就只能打落牙往肚里吞了。
项目组有无数的规范，并倾向于制定更多。项目组中问责文化流行，相互责任推脱更成为家常便饭，无论是员工还是客户都疲惫不堪。
原文链接：http://www.cnblogs.com/davidzhang33/archive/2011/05/10/2042151.html
【编辑推荐】
