『圣旨到。』
『吾皇万岁万万岁。』
『奉天承运，皇帝诏曰，本项目应在三个月后准时完成，若有违背者…杀无赦！钦此。』
『臣谢主隆恩。』
宣读圣旨的公公前脚才一离开，只见项目经理满脸铁青，面对满门老小，不禁仰天长叹，继之以涕泪纵横：『唉，想不到老夫一世英名，今日眼看着就要葬送在这个项目上。三个月…这怎么可能呢？连测试的时间都不够啊，眼见着这就是个抄家灭族的欺君大罪了，这可该如何是好啊…』
很多时候，我们所遇到的项目，schedule总是依据某个神奇的因素而订定下来，可能是客户跟他的老板赌咒发誓一定会deliver的期限，也可能是高阶主管为了绩效硬着头皮喊出来的时间。不管schedule怎么订出来，对于project team来说，感觉上总是觉得远远地不足。对大多数没有机会参与project planning的team member来说，每次接到这种案子，听到这样的schedule，心里面总是凉了半截：『怎么会有这么离谱的schedule？』接着就会如丧考妣，好象接到太监公公所宣读的圣旨一般。只要你一做不好，deadline一到，马上就要被诛九族。
这让我想起我的某位客户：『你所提出来的schedule，就代表了你们公司对于我们的承诺，一旦你给了我们承诺，不管你们要付出多少代价，都应该要誓死完成任务。为什么你们每次给了我一个schedule，就会一延再延？你们的纪律在哪里？你们的决心又是什么？软件开发哪有那么困难？这是因为你们都没有决心，没有纪律。根本就没有认真地对待你们所做出来的promise…』事实上很多客户都有同样的观点。
对于大多数的客户来说，project的schedule是一件很重要的事情。这可能会影响到下列几个很重要的事情：
Ÿ 我什么时候可以叫大头来看demo？
Ÿ 什么时候系统可以上线？
Ÿ 今年我的考绩会是什么？可以多领多少股票？
Ÿ 你们完蛋了，居然又delay了！
对负责报价的sales来说，schedule则代表了不同的意义：
Ÿ 平均人数 * schedule * 平均薪资 = 报价总金额。Schedule不可以太短，不然会没钱赚。
Ÿ Schedule又不可以太长，太长客户不会把案子包给我们做。而且很有可能抢不赢竞争对手。
Ÿ Schedule比客户预定的时间略长一点，这样双方讨价还价时，就会落到一个比较可以接受的范围。乘以人数跟平均薪资以后，要让总金额落在客户的预算内，并且比对手的略低即可。嗯，我真是个英名神武的超强sales。
对工程师来说，schedule则是基于对于事实的了解，以及以往的经验，所做出来对于未来的一种估计。正因为软件开发的难度甚高，所以这个估计不准的机会也蛮大的。更不要提大多数时候，项目的schedule常常都跟项目经理或是sales丢骰子、或是射飞镖的结果有关，跟工程师内心对于schedule的定义或想法完全无关。所以对于大多数的工程师来说，Schedule delay，并不是世界末日的来临。Well, it’s just another ordinary day。有位朋友，给的答案最为经典：『schedule本来就是订来要被delay用的，要不然干嘛订schedule？』
对于schedule delay，客户觉得是一种万恶不赦的罪行，工程师则是觉得这好象是到拉斯维加斯试手气，又小输了一把，这是生命的常态，你要学着去接受它，如此而已。对于schedule的认知截然不同，这就造成了『只要有项目delay，双方就会吵得人仰马翻』的戏码不断地上演。
Delay好象是软件业界的常态，对很多人来说，做项目没有不delay的。在写这章的同时，我非常努力地开始回想：『我是否曾经做过哪个项目，能够在原先估计的时间内做完？』我用力地想，大力地想，把我家祖宗十八代都找出来问一问，得到的答案是『没有。』
这或许是因为我做过的案子太少，才会这么不幸，每个project都delay。不过我仔细地访谈过亲朋好友，街坊邻居，还跑去灵犬莱西的饭桌上问卜，得到的结果一点也不让人意外。
大多数的project其实都逃不出delay的魔咒。原本要做一年的，结果做了六年；要做半年的做了一年半，预计要做一个月的拖了三个月。每个案子都有属于它自己的原因，只是结果通通都是一样：『没有办法在预计的时间内，交出原本预期应该交件的成品。』
很多专家学者写了很多本书跟论文来探讨这个问题，提出各式各样的做法，希望能够铲除这个软件业界的陋规。有些人认为是估计的方法有问题，有些人认为是项目管理的方法出问题…每个人的说法，看起来都很像是那么一回事，我没有一一验证过，这是属于专家学者做的事情，有兴趣的人自己去买本教科书来看。
※作者注：对这个主题有兴趣的人，可以去参考有关function point，或是其它讲software metrics的书籍，我个人蛮喜欢Tom DeMarco的Controlling Software Projects(这本书有一点年纪了喔)。想要找找非信息界的观点的话，我推荐高德拉特所写的Critical Chain，这是从他的限制理论(TOC, theory of constraint)来看项目管理的一本小说，要找TOC详细的理论或是实行手册的话，去Amazon上search一下theory of constraint吧。
在这一章里面，我想谈谈一旦项目有了delay的迹象，跟这个项目有关的人，会采取什么样的对策，以及我自己对于这些典型对策的看法。
一般遇到项目开始有了delay的征兆时，通常我们会采取的做法不外乎下列数种：
Ÿ 逃避问题
Ÿ 逃命
Ÿ 交相指责
Ÿ 敷衍了事
Ÿ 追求银子弹
Ÿ 增加status report的频率
Ÿ 增加人手以及焚膏继晷
Ÿ 更换项目经理
Ÿ 专注在解决方案上，而非责任归属
Ÿ 缩小scope
Ÿ 重新订定出合理的schedule，并配合适度的项目评估措施
逃避问题
逃避问题其实不是什么高招，不过在项目delay还不太严重的初期，问题还没有十分彰显时，常常会受到项目经理的青睐。逃避问题通常可以拖过一段时间，直到问题自然恶化到没办法逃时，才需要采取其它的方法。
虽然有句俗话说：『逃的了一时，逃不了一世。』不过最少在逃避的过程中，所有项目的成员，都可以拥有喘息的机会，并且换得一时的平静生活。所以逃避问题还是十分popular。一般来说，如果可以躲得过，没有人会往火坑里跳，况且常看好莱坞电影的人，总会期待上天会眷顾好人，每每到了千钧一发之际，就会天降甘霖来个完美大结局，帅哥美女从此可以恩恩爱爱过着幸福的日子。所以只要撑过这一时，达成这个milestone，事情应该就会渐入佳境。就是在这种自我催眠的情境下，我们学会了逃避问题。通常我们会采取下面几种逃法：
Ÿ 解盘，并且用各式各样的借口去延schedule
Ÿ 这个phase丧失的时间，会从下个phase中加班补回来。
Ÿ 拒绝任何明确的承诺
解盘，并且用各式各样的借口去延schedule
看过股市分析师解盘吗？『受到美国Nasdaq指数的激励，大盘从开盘后就开高走高，现在加权指数来到了四千七百五十八点，成交量目前已经到了九百八十亿…』
有些项目经理，一旦看到了delay的征兆，就会开始尝试着如同股市分析师解盘一般，每天预测项目到底何时会结束，然后每天更新预测。今天会猜三个月，明天会猜四个月，后天还是维持三个月。
乔安娜：你觉得再多久可以上线？
布鲁斯：从我手上经过整理break down到每支程序的结果可以看出来，我们还有一百二十支程序，目前已经有30支完成百分之二十，50支完成百分之八十…(下略，他讲了十分钟)所以一切顺利的话，再三个月。
过了三个月…
乔安娜：你觉得再多久可以上线？
布鲁斯：根据我手上最新的统计数字显示…(下略，他讲了二十分钟)，因为…(下略，他讲了二十分钟)，所以时间超出我们原本的预估。如果一切顺利的话，再三个月。
又过了一年…
乔安娜：你觉得再多久可以上线？
布鲁斯：根据… (下略，他讲了三十分钟)，因为…(下略，他讲了二十分钟)，所以时间超出我们原本的预估。如果一切顺利的话，再三个月。
解盘法的奥妙，在于他每次都得要提出一种看起来合理的说法，让你觉得这次的delay是合理的，并且这次的项目delay，都是因为不可预期的因素所造成的，而这一次的估计应该会比较接近最后的结果。接着要找出各式各样的理由，来把schedule往后延。例如：
Ÿ 因为美国遭受到911恐怖份子攻击，所以没有consultant愿意在这么危险的时候，飞到台湾来做案子，所以我们原本预估好的人力出了状况，所以要延schedule。我想应该会延后一个月左右。(看起来无懈可击)
Ÿ 因为海珊向哈利波特(Harry Potter)借了隐形斗篷，把伊拉克的大规模毁灭武器都藏起来了，所以我们需要找到疯眼穆敌 (Mad-Eye Moody)，透过他的魔眼，才能找到伊拉克的大规模毁灭武器。所以我想找到伊拉克大规模毁灭武器证据的schedule，应该会延三个月左右。(应该也足够让特勤人员制造一些证据出来了。)
(作者注：对于哈利波特不了解的人，请参阅J.K. Rowling的著作。Mad-Eye Moody可以参考『Harry Potter and the goblet of fire.』)
如果连哈利波特都要搬出来，你就知道这是一件多辛苦的事情。每次都要想出这么多看起来合理的理由，并不是一件容易的事。还好大部分时候，都可以推托到项目成员遇到史上前所未有的困难，以至于造成了预测与实情有显著落差身上。我个人推荐下面的标准说辞：
一直到现在，我们才完全体会到这个系统的business rule有多么tricky，它的复杂程度，远远超出我们一开始的预期，你们的domain knowledge真的是非常地高深，对于系统应有的feature，考虑的真的非常非常地周全。我做过这么多系统，从来没有做过考虑这么周延完善的系统。所以我们在设计相关的程序时，一直希望可以在功能上符合你们的预期，可是另一方面，我们又希望系统可以保有足够的弹性，因此这个module设计的非常非常地复杂。虽然它很复杂，可是我们的程序设计师不断地努力，一直加班想要赶上进度，所以在先前我所提供的status report上面，一直没有把这项功能可能会delay这个issue highlight出来，因为我想我们应该还有meet既有schedule的可能。不过很可惜，虽然我们再三的努力，它还是剩下一些小bug，没有通过我们内部测试人员的测试。品质不好的产品，我们是不敢deliver给客户的，因为品质是最重要的。如果草率上线，资料一旦错乱了，造成的困扰一定是无以复加。为了提供最好的品质，我想我们会需要一点时间。照目前的状况判断，我们需要再往后delay三个月的时间。
重点提示：
一、东西很难。你们真厉害，搞得懂这么复杂的东西。
二、东西很复杂，所以要做很久。
三、这点最重要，我们的人已经不断地加班了。先前没提出来这个会delay，是因为想要赶赶看来得及来不及。
四、不管东西写好多少，都要告诉客户，现在已经在测试了，只剩下一些小bug。天晓得这个模块到底写好多少？
五、我们要delay。
解过几次盘以后，麻烦就开始来了。你必须要提出够多的猜测，来逼近实际发生的状况。运气好的话，总有几次猜的比较接近一点，这时就可以声称自己是多么地有先见之明。这就跟股市老师在报明牌一样，用够多无用的理论，以及各式各样的专业图表，堆砌起无数的废话，然后每天提出一种不同的答案。对于猜测不准的部分，他会轻松带过；对于比较接近的部分，他会努力地宣传他惊人的预测与执行能力。
这种方法其实有很不好的副作用，就是会丧失信用。每次提出来的数据都不一样时，会被人质疑你管理项目的能力。就跟股市老师们，如果明牌报不准，就会收不到会员是一样的。不过对于某些主管来说，这叫做『随时依据最新的状况，调整预估的结果，以便让我们掌握最新的动态。』用投资界的说法是，这就是『随时依据市场上最新的情势，调整投资的策略。』
解盘其实还算是认真的，最少你会去找借口。菜鸟经理们通常会很频繁地尝试去解读所有征兆，做出最新的预测。只是做的太频繁了，就会随着各种预言的失败，而丧失信用。有经验的人告诉我们，schedule除非遭受重大变故，不然不要太频繁地变动。以免接收到讯息的人，感到太过混淆。可是也不要拖太久，例如每次都到要miss某个milestone时，才面有难色地延schedule，这样一定会被愤怒的客户狠狠地打到吐血。一般如果project在半年之内，两个礼拜左右review一次schedule的状况是很合理的。如果时间更长，大概一个月review一次则是蛮合理的。
当然，有些自视甚高的人，就不用这么麻烦地解盘了。他们根本就不用观察真正的schedule到底delay了多少，他们采取的方法是：
这个阶段丧失的时间，会从下个阶段中加班补回来。
在某次的project review meeting上。
乔安娜：布鲁斯，依你的专业，你觉得目前项目的状况如何？
布鲁斯：我想我们在分析这个phase，比原先的预期晚了一个月。
乔安娜：那你有什么补救措施？你知道这个项目对我们来说很重要。
布鲁斯想，我还没做过那种对于客户来说不重要的案子哩：我想我们会在后续的设计阶段加班，看看是否可以赶上现在的进度。
乔安娜：那就拜托你了。
到了design phase的milestone逼近时的project review meeting。
乔安娜：布鲁斯，依你的专业，你觉得目前项目的状况如何？
布鲁斯：我想我们在设计这个phase，应该没有办法超前进度一个月。事实上，我想我们应该只能照原有的进度完成。
乔安娜：那你现在打算怎么办？
布鲁斯想，早知道你会问这个，老子早就准备好答案了：我想我会请programmer现在就开始coding。虽然我们的design还没有完成，不过主体架构都已经差不多了，只剩下一些很细微的地方需要修改。我们采取pipeline的做法，应该可以争取一点时间。我想我们原先分析阶段delay的时间，应该可以在coding时赶上。我会请我们大陆office也多支持三个人力。
乔安娜：那就拜托你了。
结果Design不但delay，太早进入coding，又面对无数次的design change，看来project应该会delay半年。在这次的project review meeting上。
乔安娜：布鲁斯，现在project到底会delay多久啊？是不是你们公司的resource有问题啊？
布鲁斯：没有没有，绝对没有resource不够的问题。
乔安娜：你该不会告诉我你们coding delay的部分，可以在测试阶段赶上吧？
布鲁斯：我想我们要很专业的来看这个问题。依照目前的状况来说，应该会delay九个月…(既然要喊delay了，总要抓一点buffer…)
乔安娜：什么！！！
布鲁斯：关于这个问题，我觉得很抱歉…
通常自以为厉害的程序设计师，或是心存侥幸的项目经理，都会抱持着美丽的梦想：『目前delay的进度，应该可以在下个阶段迎头赶上。』通常能力越强的人，越容易犯上这个毛病。很多人会想：『我只要如何如何，再加上谁也怎样怎样，咱们来个双剑合璧，应该就可以顺利赶上原有的进度。』
是啦，如果真能双剑合璧，应该有机会可以达成啦。不过大多数的状况下，『双剑合璧』都变成了『双累何必』。透过神奇的发电机，可以让项目突然的急加速，接着让你的项目按照时间准时deliver。这种跟上帝借时间的事情通常并不会发生，就跟男生跟女生接吻不会因此而怀孕一样。
(作者注：对于双剑合璧不了解的人，请参阅金庸先生所着的『神雕侠侣』。)
当然，天有不测风云。感谢圣母玛莉亚，这个世界上总是会有美好的意外。有些礼物还是会很罕见地从天上掉下来。处女遭受到天主的眷顾，还是可以怀孕。这世上总会有几个经历了成员不眠不休，小组通力合作以后，结果可以顺利地达成任务的神话。可是在光鲜亮丽的背后，通常都要付出相当惨痛不为人知的代价。最常见的代价，就是把事情做完的人，一把事情做完以后就走人。
以我个人的经验来说，那种『这个阶段的delay，可以在下个phase中加班赶上』的神话，从来都没有发生过。或许这是跟我的运气不好，买乐透都不会中头奖也有关系。不过大多数人，买彩券到最后也都是在做功德，资助那些需要帮忙的人。根据我的观察，会采取这种掩耳盗铃的手段的人，出发点多半也不是为了要骗人，主要的原因应该是怕别人失望，所以会想办法讲一些『善意的谎言』，或是『不够完整的事实』。接着就会想办法要十分努力去符合别人的期望。这种倾向在那种学校成绩特别好的学生上特别明显。『我怎么可以让老师失望呢？这次考不好，我下回一定要加倍努力，交出漂亮的成绩单。』
问题是做项目不是在参加考试，这是个团队合作的成果。没有良好的规划与沟通协调，光靠认真，很难把流失的进度追回来。Project会delay，其实有可能的因素非常多。很多在学校表现优异的学生，只要一被老师责骂，就会仓皇失措，如果错不在己，多半就会变得愤世嫉俗，心存怨怼，到最后终日怨天尤人。
这里就看出功课不好的人的优势了，如果你考零分已经习以为常，在你掏出一份delay得超级离谱的schedule之前，你其实已经做过千百次的实战训练。客户无情的炮轰，其实跟小时候考零分被爸妈发现，准备吊起来毒打一顿，是差不多的事情。任何拥有这种经验的人，应该会比功课优异的天才儿童，更适合担任软件业的项目经理。这可能也解释了白痴为什么可以当上主管的原因。
(作者注：如果你对于白痴当上主管这句话，没有任何感觉的话，可以参考一本很棒的书：『呆伯特法则』。)
如果你认为客户没有办法接受真实的状况，所以会想要说些『被修饰过的真相』，以免他们失望。很有可能唯一没有办法接受事情真相的人，就只有你自己而已。有道是『轻诺者必寡信』，不愿意接受事实，只想轻易许诺的人，不用太久就会被客户看穿。
如果你想要不做任何改变，只靠超人加班就可以赶上schedule，要不要考虑花点钱去买乐透？只要你中了头奖，应该就不用工作了，这样不是就不用烦恼delay的问题了吗？
愿意承诺下个phase就可以赶上的人，如果不是全然地敷衍的话，最少还会想想怎么赶上进度。有些人会采取截然不同的角度，他们努力地想，用力地想，可是就是没有结论。到最后就会采取下面的这个做法：拒绝任何明确的承诺。
