即使项目经理自己努力做好估算、规划和日程安排工作，你遇到的发起人、管理层和团队成员还是有可能视日程安排为儿戏。项目经理要把这些人带回现实，不过首先要学会识别这些日程安排游戏。

一、再短一点

所有的发起人和管理层都会逼你在日程安排上做出一些让步。即使你制定的项目日程已经相当合理了，他们还是会玩这样的游戏。不过他们抗拒的方式很容易识别，很少脱离几种固定的模式。项目经理只要能够识别出他们所玩的游戏，就可以更容易地掌控项目，得到理所应当的产出。

幕天成公司的项目经理姜柳丹与项目团队成员一起，用一周时间制订出了项目计划。她们完成了“哈德逊湾式启动[1] ”，并已经识别出了主要风险。她将计划安排发给发起人潘祥榕。

“你就不能再早点完成项目了吗？”潘祥榕的一句话将姜柳丹送回了团队，步履蹒跚。

姜柳丹与团队又花了一周时间修改时间表，得到另外一个日期。他走进潘祥榕的办公室：“如果你能为我们提供更多人手，我能提前一个月完成项目。”

“不行啊，上级领导和我都需要项目早点儿完成。”潘祥榕皱着眉头说。

“如果能确保客户不在需求上纠缠、公司上下都给予支持，一切顺利的话，可以再提前半个月!”

 “还不够！” 潘祥榕几乎没有思考。

“你到底想要什么？”姜柳丹爆发了！

“挤水分”（见图1），这就是潘祥榕玩的游戏。不管你制订出什么样的日程，你的发起人总是希望项目能更早完成。你只会发现：发起人不会认同你提出来的每一个截止日期——你的日期总是离他们的期望值很遥远。

图1 挤水分

当干系人希望项目能更快交付，但又不告诉项目经理何时需要或为什么时，就会玩“挤水分”游戏。如果他们告诉项目经理期望的截止日期，项目团队就可以确定届时能完成哪些工作

遇到“挤水分”的情况，讲求实效的项目经理不妨试试以下几种方式：

l  再确定项目进度计划之前，先澄清几个问题：项目的关键驱动因素是什么？项目资源能提供多少？减少项目范围少实现几个功能会如何？项目的成本有制约吗？

l  是什么促使干系人期望如此不现实的项目工期？项目成功的真正含义是什么？

l  为提供的项目计划说明置信度，在提供项目计划时要说明项目计划应具备的条件，让管理层明白压缩工期的风险。

l  使用更短的工作安排，让干系人看清项目进程。

l  制订项目工作优先级列表，提供管理层不同工期下可以完成工作的清单。让干系人更多了解项目进程，促使其不过多纠缠。

二、行百里路半九十

许许多多知识工作者，特别是技术人员，都未学过如何估算。就算是尝试过估算的人，他们也过于乐观，总是会过低估计一项任务需要的工作量。要么就是得不到任何对估算的反馈，所以他们不会知道自己的估算不准确；要么他们预测不到一个任务中会牵涉多少子任务，比如准备测试环境或是签入代码这样的任务。在任何情况下，当有团队成员以为自己完成了90%的任务，而实际上还有90%工作尚未完成的时候，“90%完成”状态就发生了。

程序员马凯在写一个数据库对话工具时，要把一种数据库格式转换成另一种。他认为其中的数据没问题，可实际并非如此。字段格式定义错误和对需求的理解不足导致Bug过多和频繁变更。项目的实际工作量大大超出马凯的估算。

项目经理应该想法避免“90%完成”，为此应该做好以下两点：

l  与团队成员定义粒度更细的工作任务。时常提问“要完成这项任务，需要多久？这周要处理的细分任务都有哪些？”

l  要让团队成员把自己的工作进度展示出来，每一次展示都是对工作的澄清，有助于识别项目中隐含的问题。

如果项目团队已陷入“90%完成”陷阱，项目经理也不应发出悲观论调或是冷嘲热讽，帮助团队成员看清真正的进度、回到现实。可以采取下面这些措施来管理信马由缰的乐观情绪。

l  收集数据并与项目团队成员讨论项目进展速度，探讨在项目过程中发生的“没想到”，分析发生的原因，争取后续工作走上正路。

l  有些表象会让人错以为自己一直在按进度计划，甚至超越了进度计划，要特别注意这些表象背后的不可见因素。

l  关注团队成员的工作状态，在任何情况下，如果同一时间分配给员工大量的工作任务，都会降低员工的工作效率！如果有人在为其他项目工作，或是承担其他影响项目进展的事项，马上与管理层讨论并想办法中止这种状况。

l  时刻提醒团队成员每个项目是独特的，在某种程度上都具有创新性的，因而它们充满不确定因素、都包含风险。在项目计划时，每个人都倾向于乐观，而实际过程却是曲折的（图2），必须识别和管理好项目中的不确定。

三、计划等于承诺

项目计划安排只是项目工作的估计，项目日程是对于团队何时到达哪个里程碑、何时完成项目的最佳推测，本质上是猜测的。发起人常将这个猜测视为承诺。

面对这个困境，可以问其如下两个问题：

l  是否关心团队交付的东西？

l  是否关心产品的质量如何？

要想让有关项目日程的谈话富有成效，就得讨论项目后面的驱动因素、约束；应该商量在截止日期之前，至少有哪些功能是必须要交付的，这些功能应该达到什么质量标准。如果相关人员还没有准备好讨论项目计划、功能集合和验收标准，那么任何关于日程应该作为承诺的讨论都显得为时过早。

当管理层要求得到承诺时，建议用信心水平与他们沟通：“我有90%的信心在8月30日交付，如果允许在10月30日交付，我有100%的信心。”当然，你应该告诉他们这两个信心日期之间必须要做的事情，自己也因此而深入理解了将日程作为承诺对项目团队而言意味着什么。

也可以尝试使用渐进交付法。“我可以告诉你，第二季度交付客户最关心的部门设备和功能，剩余的部分设备可以保证后续2个月交付，届时同时完善所有功能。”

如果干系人要项目经理承诺一个日期，那就考虑如何组织项目吧。试试用迭代或者尝试渐进交付法，要不就用带有日期估算的信心水平吧。但我还是敬告你，这简直就等于是为墨菲敞开大门了。你可以承诺一个日期，但是发生一些意外将很难避免。