『圣旨到。』
『吾皇万岁万万岁。』
『奉天承运，皇帝诏曰，本项目应在三个月后准时完成，若有违背者…杀无赦！钦此。』
『臣谢主隆恩。』
宣读圣旨的公公前脚才一离开，只见项目经理满脸铁青，面对满门老小，不禁仰天长叹，继之以涕泪纵横：『唉，想不到老夫一世英名，今日眼看着就要葬送在这个项目上。三个月…这怎么可能呢？连测试的时间都不够啊，眼见着这就是个抄家灭族的欺君大罪了，这可该如何是好啊…』
很多时候，我们所遇到的项目，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就可以赶上的人，如果不是全然地敷衍的话，最少还会想想怎么赶上进度。有些人会采取截然不同的角度，他们努力地想，用力地想，可是就是没有结论。到最后就会采取下面的这个做法：拒绝任何明确的承诺。
拒绝任何明确的承诺
在某次的project review meeting上。
乔安娜：布鲁斯，你觉得我们什么时候可以上线？
布鲁斯：关于这个问题，我需要跟我们team member仔细评估讨论之后，才可以回答你。
下次的project review meeting。
乔安娜：布鲁斯，你跟你的小组讨论过了吗？你觉得我们什么时候可以上线？
布鲁斯：关于这个问题，我目前还在做work breakdown。
乔安娜：那什么时候你才会给我答案？
布鲁斯：下次开会告诉你。
下次的project review meeting。
乔安娜：布鲁斯，你觉得我们什么时候可以上线？
布鲁斯：如果一切进行顺利的话…
乔安娜打断：什么叫做『一切进行顺利的话』？你到底确不确定你要提出来的schedule？
布鲁斯：这里面变量很多，有很多不可预知的risk…
乔安娜打断：那你把你的risk都列出来。
布鲁斯：我不知道耶，如果这样的话，我想我还需要跟开发团队讨论过以后，才有办法提供risk list。况且即使我把所有的risk列出来，还有一些我们原先没有预期的risk可能会发生？
乔安娜快气死了：那你到底什么时候可以告诉我们最新的schedule？
布鲁斯：下次开会告诉你。
乔安娜想，神啊，救救我吧。…
这种策略其实很简单。每一句话都是由『If then else』组成。千万不要给任何承诺，或是确定的意见。回答得越虚无缥缈，高深莫测，别人越难抓你语病。如果问你的意见，不是要回家请问专家学者，就是要组成委员会，经过审慎评估研究之后，才可以回答。你完全没有个人的看法。这个做法我们在政坛上常常看到。例如：
记者气喘如牛地说：市长，市长，我们的摄影记者背着摄影机有点跟不上你健步如飞的轻盈步伐，这样会没办法捕捉你穿著运动短裤以及性感小背心跑步的英姿。你可不可以跑慢一点？
市长：关于这个问题呢，我目前保持着开放的心理，没有什么特定的想法。我想邀集几位专家学者，组成一个跑步速度特别委员会，经过他们从各个角度，仔细小心地审慎评估，多方面地全盘考量以后，一定会给大家一个周延的答复。
记者还在喘，心想，不会吧，你就跑慢一点，干嘛还要搞个委员会？让我再问一次：市长，那以你现在的心情来说，你到底会不会跑慢一点？
市长：我想如果他们的结论一出来，我一定会参考他们的意见，做出最有利于我们市民大众的决定。
记者还在喘，因为还是追不上：可不可以有更明确的答案？我们已经快要追不上了。
市长：如果大家对于这个问题有这么高度的兴趣，我想我一定会在最短的时间内，给大家一个满意的答案，不然就会辜负大家对于我的爱护。谢谢大家。
接着市长就咻地一下子就跑掉了。留下不知道在哪里的专家学者委员会，以及快要缺氧的记者朋友。
说话的艺术很重要。当你不确定什么时候可以完成，也没有办法确定该到的资源都可以support时，就只好装死，给一些看起来虚无缥缈的承诺。以及空洞的场面话。只要你的官位够大，硬撑到底，其实客户是拿你一点办法都没有。下面是一个模板，请参酌使用。
我们公司非常重视这个问题，CEO已经指示要尽我们最大的努力，来展示我们的诚意。为了表示我们的慎重，我们已经组成了一个特别委员会，由我本人亲自主持，我们会daily来review我们的进度，并且会努力在最短的时间内，实时地update给诸位。我想我们一定会通力合作，在最短的时间内，发挥最大的可能。务必要让已经落后的进度，可以顺利地赶上，甚至是超前。如果有帮助的话，我想我还会运用我们大陆地区的人力，来加速这个案子的开发。
好吧，场面话讲个几次还行。用多了，容易被轰出来。所以一定要配合其它的方法来进行。不过偶尔说个几次场面话来拖个几个礼拜，其实还蛮管用的。
会采取这种步骤的人呢，我们可以说他们是从不轻诺，因为他们根本就不打算许下任何承诺。事实上还有人会称呼他们『重然诺，讲信用。』我个人则是认为，这只是在换个方向来躲避问题而已。我总觉得逃避问题，只是假装问题不存在，并没有办法让整个项目获得什么实质上的改善。对于整个project的schedule来说，也没有什么正面的效益。唯一可以达成的效果，就是延缓真相爆发的时间点。
逃命
逃命其实是逃避问题的极致表现。对很多人来说，当他发现项目已经病入膏肓时，此时与其和项目一起向下沉沦，过着暗无天日的加班生活，不如不管这个项目的死活，赶快找好下一个工作，等到事情快要爆发，找个机会跟主管起冲突，接着双手一撒，就可以拍拍屁股走人。
如果你平日就是个温良恭俭让的翩翩君子，对于怎么跟主管起冲突，觉得十分棘手，或许你可以参考下面的例子。
在超级市场里头，有个小男孩倒在地上不停地哭喊，双手双脚则是不断地胡乱挥舞，他的爸爸则只能够在旁边尴尬地陪着笑脸，一边闪躲旁人异样的眼光。走近一听，小男孩嘴中大声哭喊的是：『我不管，我不管，我就是要买这台玩具汽车啦…』
二十年后，这个小男孩当了项目经理。为了让你比较容易理解他的性格，我就借用一个典型的人物。我们就姑且叫他韦小宝吧。
话说小宝混了很久，他已经有很长的时间没有去理他手头上的项目了。眼见着此时，最大客户神龙集团的四十二章经全文检索系统，已经要delay了。在某次内部的project status report meeting上，他发难了。
小宝：下个礼拜一就已经是这个project implementation phase的deadline。我刚刚才听说，我们现在落后的进度，大概要再一个月才赶得上。
吉娜：什么？！小宝，那你之前为什么都没有提出来？
小宝：我也不知道。我原本以为是来得及的。你也知道，胖头陀那个家伙一向独来独往，又沉默寡言，我哪知道会有这么大的问题？
吉娜快气死了，那我养你干嘛？现在不急着发火，先耐住性子：那你有什么backup plan？
小宝：归根究底，这都是因为本来打算进来一起coding的瘦头陀没有进来，才会变成这样。要不就是让瘦头陀一起进来，两个人一起拼拼看。我想瘦头陀如果可以一整个礼拜都进来，他们两个师兄弟联手一定所向无敌。我们应该有机会可以赶上落后的进度。
吉娜：可是瘦头陀现在还陷在东珠公司的项目里啊。这件事情早就跟你讲过啦，不然瘦头陀怎么不会去帮你忙？
小宝：那我就没有办法了，这是你自己要问我的backup plan是什么，我唯一的plan就是这样，你要负责support我，我没有办法manage这么多变量。如果你也没有办法，那我不管了，你自己去跟洪总裁解释吧。
吉娜只好无可奈何的说：好吧。我来想办法。
过了一个礼拜。
小宝：看来公司一点都不在乎神龙集团这个案子。
吉娜对于这样的指控，感到十分的震惊：哪有这回事？我不是已经把瘦头陀调过去了吗？
小宝：他上个礼拜五还跑去东珠公司开会。就是因为这样子，神龙集团的这个案子才会delay。
吉娜解释：我临时调他过去，已经被东珠公司的毛总经理给骂到臭头了，有事情一定要瘦头陀出席，不过就是去开个会嘛。
小宝大声说：那是你的事情，我管不到也不敢管，我们这个案子已经这么紧急了，我都说过一定要瘦头陀整整支持一个礼拜了，居然还抽他去别的公司开会。我们最需要resource的时候，还让他分心去做别的案子？分明公司就是不想让我们可以准时deliver。既然公司这么不重视这个案子，我也不想管了。我要辞职。
吉娜忍住脾气：小宝，怎么可以说公司不支持你呢？我已经这样全心全意地支持你，为了这个案子，我都一直被CEO点名起来罚站了，你怎么可以在这个时候抽手不管。喂，你不能这样子，做事情虎头蛇尾，这样传出去对你的名声不好听啊。
小宝：那是我的问题，不用你管。这样吧，我就做到这个礼拜五，赶快找人来跟我交接吧。
(作者注：如果你不认识韦小宝，你该看看金庸先生所着的『鹿鼎记』。)
要吵架其实蛮简单的，先要一些要不到的资源，例如『我们这个案子现在这么紧急，需要超人二十四小时陪着加班。』或是尝试违背物理定律：『从现在开始，每一天都要有加倍的生产量，工作一天就应该要有四十八个小时的生产量。』提出太夸张的request，resource当然是要不到啦。接着就找个开会的机会大喊大叫：『都是因为你们没有团队精神，不愿意牺牲奉献，又不愿意提供足够的协助，所以这个案子才会delay。』然后加一句：『既然公司都不愿意支持这个案子，我也不想管了。』桌子一拍，就可以顺利拂袖而去。
这个策略最重要的重点在于讲话务必大声，即使主管已经把门关起来，还是要让整个公司的人都听到你的咆哮、不满以及委屈，这样才能达到如雷贯耳的效果。不了解的人，还会以为你个性刚正不阿，做事情颇具原则。
一旦有人祭出这种撒手锏，这时候就会看到所有可能接手的人，个个不是告老托病，就是谦称资质驽钝。如果你企图用权势威逼就范，通常就会被人以离职相胁。
小宝离职后，公司头一次召开部门会议。
吉娜：大家都知道，神龙集团的四十二章经项目现在需要有一个新的PM。有没有谁自告奋勇的？
会场上一片静默。
吉娜：布鲁斯？
布鲁斯：你们都知道，正文集团的案子，我现在正在忙着UAT。怎么有可能可以支持神龙集团的案子？
吉娜：马龙，你呢？
马龙：这应该留给年轻人去表现。我年纪大了，老骨头恐怕顶不住这票年轻人。
吉娜：哎呀，大家都知道你是老当益壮，一定没问题的。这样吧，就麻烦你了。
马龙：唉，如果真要我接的话，就只好告老还乡了。我也差不多到了该退休的年纪了。
强森：咦！我听说RD部门，下个礼拜不是会有一个叫做艾尔的新人吗？我听说他以前做过PM。
马龙就好象溺水的人，忽然看到一块大木头：是啊，听说他是台大毕业的高材生喔，年纪轻，体力一定很好。
布鲁斯：我看这种有为的青年，一定要让他好好地磨炼一下。多接受一些挑战，一定会对他的将来很有帮助。
吉娜心想，这真是一语惊醒梦中人。有个菜鸟可以当替死鬼，我干嘛还要来这边求爷爷告奶奶的：这个建议很好。我会跟RD部门的乔丹商量借将。
吉娜跟乔丹商量了很久，终于说动乔丹，让他愿意放人。
一周后，艾尔on board了，吉娜把他叫进她的办公室：艾尔，我看过你的履历了，你以前的表现非常地优异。
艾尔谦虚地说：您过奖了。
吉娜：没有，绝对没有。这么优秀的人才到了我们公司，绝对是公司之福。
艾尔：哪里哪里。
吉娜：我想你是个很优秀的人才，不过公司里面的其它人，可能还没有办法了解这一点。现在有个机会，让你可以在我们公司里面可以建立起属于你自己的credit。我也希望可以让你在工作上，有所成长而提升。
艾尔：是什么样的机会呢？
吉娜：我想让你有个当PM的机会。你现在是senior engineer，看过你的履历以后，我想你应该具备担任PM的实力。接下来就看你有没有勇气接受这样的挑战了…
于是乎，经过了吉娜吹捧之后，艾尔被灌了不少迷汤。于是乎，有点飘飘然，又非常具有企图心跟责任感的艾尔到了神龙集团，这才发现目前整个project team都on site。他心想，应该先跟team member聊聊天。结果刚好让他发现一个站在engineer后头看人写程序的人。
艾尔：我是新来的PM。你是我们公司的员工吗？啊，你是神龙集团的经理喔。抱歉抱歉，新人上任还要请你多多指教…
几番角力加上众人装死的结果，通常不是找个菜鸟经理，就是找个好好先生，再不就是从项目团队里面找一个替死鬼。真的找不到其它的人，高阶主管就只好勉为其难，自己下海。除非运气好，刚好遇到一个真命天子，功力远胜过前任项目经理，否则这种临危受命的事情一旦发生，毕竟新人上任对于项目各种繁杂的事情，短时间内一定没有办法好好掌握，一个原本已经delay的project，就会每况愈下。
交相指责
项目会delay，其实多半双方都有责任，很难完全归咎于其中的一方。所以一旦delay时，很多人的重点都会放在『谁应该负责』这个一定会引发争议的问题上。如果你没吵过，请仔细注意下列关键词：『负责』与『责任』。
乔安娜：布鲁斯，你觉得我们的project为什么会delay？
布鲁斯：还不是因为你们user的requirement不停地change。
乔安娜：话怎么能这么说。要不是因为你们的SA太没有经验，根本就听不懂我们的需求，怎么会有这种事情。况且很多根本就不是requirement change。我觉得现在会陷入这样的困境，SA要负最大的责任。
布鲁斯：怎么说不是requirement change？你可以去翻翻会议记录。都已经是什么时候了，还在改business rule。
乔安娜：你可以去翻翻我们提供的原始文件。哪一个需求不是我们一开始就提出来的？你们自己不认真去读文件，还怪我们requirement change？根本就不负责任！
布鲁斯：你们提出来的文件跟山一样高，当然会需要你们的帮忙确认啊。SA告诉我，有很多需求，其实开会时你们讲的，跟文件上写的，根本就不一样。我们跟你们confirm，你们还跟我们说是文件写错了。这明明就是你们的问题，怎么可以叫我们负责？
乔安娜：哪有这种事情？喔，你是说我们新来的承办人雪丽喔。她也是新人啊，自己也没有完全进入状况啊，你们怎么可以抓着他的语病，就一路追杀到底？
布鲁斯：我们哪有。可是明明user讲的就是跟文件不一样嘛。
乔安娜：那你应该反映在会议记录里啊。
布鲁斯：每次访谈，讲的东西那么多，怎么可能全部纪录下来？
乔安娜：记下来不一致的地方，要求澄清，这不是SA应该做的事情吗？不然难道要我来写会议记录吗？你连下面的SA这么不专业都没管好，你PM是怎么当的？你到底有没有责任感啊？我们的项目delay这么久，你们一点都不紧张，每天晚上九点不到就全部回家了。因为项目delay，让我们公司的资源在那里虚耗，所造成的损失是要谁来负责？
布鲁斯：你讲话一点理性都没有，简直就莫名其妙。我不要跟你吵架了！再见…
我们小时候都听过，开会时要对事不对人。不过我们的课堂里，从来都没有教导过，当跟你开会的对象，开起会来是对事又对人，没事干就指着你的鼻子骂人时，你该怎么办？
基本上，当有人不遵照游戏规则时，有些人就会依据直觉来反击。你凶，我就比你更凶；你狠，我就比你更狠。所以会议一开，双方就火力全开，开始交相指责。你骂我办事不力，我就骂你没有全力配合；你骂我领导无方，我就骂你将帅无能，累倒三军。凡是delay的很严重的project，通常双方的领导都多少有些问题。互揭疮疤的结果，通常是两败俱伤，搞到最后，关系恶化，常常会拒绝与对方开会。Project如果做到这样，下场就不言可喻了。
除了互相攻诘以外，文件常常又是另一个争吵的来源。言语确实是一种非常不精确的沟通工具，不过这不代表使用文件进行沟通，就不会有任何问题。我刚从学校毕业时，就觉得文件应该越多越好，越详尽越好。
后来工作得越久，就越不是这样子想。过多的文件，绝对是效率的杀手。你如果有与大公司做案子的经验的话，你或许可以体会到我为什么会这样子思考。很多时候，你做一个大案子，可以拿到的文件，可能洋洋洒洒数百页，甚至上千页，往来的会议记录可能是以数百次来计算的。面对这么多的信息，你还得要去把其中的历史演进给搞清楚，还要把个中互相不一致的地方给挑出来，这绝对是个苦差事。难怪Rational还会专门设计一个管理requirement的tool。
遇到这种被文件淹没的时候，如果requirement的management出了问题，到了后期，双方争吵的重点，通常就是：『这个系统，为什么会做成这样？』例如这个系统现在的功能，可能是依据1/8的会议记录修改的，可是1/22时的会议记录，老早就把1/8的一部份给推翻了。你以为照1/22的改完就ok了？不对。1/29的会议记录，可能又把1/22的会议记录再做了一个minor的修订。等到你按照1/29的做出来以后，有可能主其事者也换了一个人，他可能就会坚称，原始的需求文件才是对的。
当一个change request来临时，到底impact到多少东西？有多少文件要改？有多少程序要改？老实说，要是你没有一套很好的工具，也没有一套很好的process，这些问题根本就答不出来。当然，这跟requirement management还有change management的process有关。不过再怎么良好的process，还是没有办法解决人的问题。
这怎么说呢？就算你有很好的工具，你也采用了一套不错的process，人的印象，还是很难改变的。当一个人把1/8时的设计，仔细研究，慢慢思考，终于深深地印在脑海里面之后，这时他看到了1/22的会议记录，于是乎他想了一下，深深地叹了一口气，在脑子里面更改了一下原始的设计，接着开始进行修改。可是当他看到1/29的会议记录时，他的印象搞不好还停留在1/8时的状态。好吧，这下子搞不好就已经是一团乱了。问题就来了，现在的系统到底会做成什么样子呢？不一定，可能保有一部份1/22的精神，也有可能保有一部份1/29的request。更不要提，designer在看了1/29的会议记录，其实有几段看不太懂，在design时，就别出心裁地做了一些小修改。这一改，很有可能又制造出不少潜在的bug，留给后世的人景仰。
咦，好象离题很远了。Anyway，互相争吵对于项目其实一点帮助也没有。除非你打算打官司，或是只是单纯不想让对方的日子好过，否则厘清责任其实没有什么帮助。因为重点不应该放在谁该负责，而是在于问题该怎么解决。你可能可以舌战群雄，技惊全场，让客户承认他们该负责。好吧，那又怎么样呢？该你deliver的东西，还是要你去做啊？把客户惹毛了，项目会做的比较顺利吗？我可不这么认为。
敷衍了事
大多数的项目，都有个共同的特点，就是『Deadline将届之日，才是大家各显神通之时。』这跟考试之前大家都会熬夜念书临时抱佛脚是相通的道理。每每到了期限快到时，每个人都会想出各式各样的方法，来想办法meet schedule。面对超高的压力，以及项目经理殷切的期盼，所投注出来的关爱的眼神，engineer常常会在这样的状况下，走一些前所未有的快捷方式。我最常看到的现象，就是『随便做一做，做一个长的很像的东西交差了事。』
难做的功能，如果有些小问题，多半也不容易在第一时间内测试出来。就算是测出来了，那也不过就是个bug。真要来不及的时候，没鱼虾也好。先求有，再求好。所以engineer常常会在时间压力下，做个看起来是对的，骨子里全然不是那么一回事的东西来交差。有责任感一点的，内心还会想说，如果度过了这一关，我回头再来把它做到好，虽然大多数人，根本就不会有这个再来把它改到好的机会。不过最少这些人还算是有良心。有些人根本交完差以后，就愉快地去过他的生活了。
这种状况在于那种完全采用WBS(Work Breakdown Structure)来进行项目管理下的project最明显。如果你没听过WBS，我在此做个简单的说明。WBS就是把你所要做的工作呢，不断地细切，切到每个工作都是一个很小很小，可以管理的单元为止。项目经理要做的事情呢，就是先把工作切一切，割一割，再发下去给engineer一个一个完成。这种approach，原则上符合所谓的divide and conquer(各个击破)的道理。我记得在学校写作业时，常常就是你写第一题，我写第二题，他写第三题，接下来大家抄来抄去，抄完以后，每个人作业也就都写完了。
因为这跟很多人的生活经验相符合，所以对这些人(尤其是客户)来说，这样的做法很好，这样就有一个量化的指针可以遵循。例如：这个项目总共有一百支程序要写，现在已经写了70支了，所以coding就已经完成百分之七十。
一旦编出一个量化的指针之后，大家的重点，就会放在这个数字到底完成了多少，对于实际上的进度是否可以用这样的一个数字来代替，那就是另外一个问题了。这样一来，除了大家在压力之下会倾向于虚报进度，以及实际上项目真正的进度很难具体量化以外，最大的问题就在于这些程序可能在进行单元测试(unit test)时，都可以顺利运作，一旦整合起来，就状况百出。当你进一步去探究这个问题的根源时，你会发现，很多程序设计师，会在时间紧迫的状况下，走很多快捷方式。
走快捷方式本身不见得会有问题，可是如果其中的一个选择是做一个看起来很像的东西，那问题就很大了。也有些时候，programmer不是刻意地去抄快捷方式，而是对于design或是requirement不够清楚，所以自己会自做主张地做了一个假设。接下来一忙，就把这件事情完全地忘掉了。没有关系，不管是刻意的，还是无心之过，这两者造成的结果是相同的。
例如在某个人的程序里面，可能写了这样的statement。
//lfTaxBasicRate这个变量应该去读税率设定文件里面的数据。
//来不及了，用现在政府的税率顶着先。Demo过后再来改。
lfTaxBasicRate = 0.05
他信心满满地想着，等到我有空时，我再来改。Tester测试时，因为没有更改税率设定文件的资料，也就没有发现这个问题。接下来一忙，他自己就把这件事情给忘了。一直到了UAT，user觉得很奇怪，怎么改过税率以后，这个功能还是不work，是不是计算应纳税额的模块出了问题？还是税率文件的资料出了问题？还是…。于是就把问题踢回给development team的tester。development team的tester会先想：『哪有这种事？我测的时候就没有问题？是不是你操作程序有问题？是不是version control有问题？』接着就在测试环境整个重新确认过一次，发现：『啊！该死！真的会有问题。』最后就又把问题丢回去给原作者—如果他还在这个team里面的话。
你要找出这种问题，要付的代价很高。首先你要浪费测试人员的时间来找出这个问题，这可能需要透过很多测试个案的排列组合才有办法找到。接下来你可能还要花很多后续的时间，在程序代码中不断地寻找，才可以找出这个问题。
咦，如果这个是刻意的遗漏，当事人应该可以很快地找出问题啊。或许你会说，自己埋下的炸弹，自己怎么会忘记呢？怎么还要花很多时间呢？没错，即使是我们自己，都有可能要花很多时间才会找得到自己在写程序时，为了赶时间，所做的故意的省略。这就跟花心的男人，跟女朋友吵架时，会下意识忘记昨天晚上十点时，他没有打电话给她时，到底在做什么是一样的道理。有时候是即使记得清清楚楚，也不可以坦白招供。老实招认那时在酒店花天酒地，会得到比较多的谅解吗？
更何况有很多时候，即使是当事人，即使是每行程序都有批注，也不见得可以在第一时间内找到他自己在先前赶工时，偷工减料的部分。这完全取决于找到这个bug的时间，与他抄快捷方式的时间点距离多远有关。如果他走快捷方式的年代已经十分久远，他可能要花不少时间找一找，才找得到他自己埋下来的地雷，更不要提如果已经换成另外一个人来修改的话，会有多大的麻烦。最后要付出的代价，就是还要把程序改成是对的逻辑。
当然，这个问题可以透过code review，或是pair programming等等方法来加以避免。找些人帮你看看，最少在抄快捷方式时，会比较收敛一些。不过对于大多数的软件公司来说，code review是什么东西？又该怎么做呢？
另外一种敷衍，则是在流程上的敷衍。最常见到的现象就是，design没做好就直接coding，unit test没完全就直接来integration test，integration test也没做好就卯起来进user acceptance test。基本上的想法呢，就是既然已经怀胎十月，不管是畸形儿，还是连体婴，该出娘胎时，还是要出来看看他的老子。这时候最常听到的几句话就是：
? 丑媳妇总是要见公婆。
? 伸头也是一刀，缩头也是一刀。
? 早死早超生。
很多人到了快要miss原先所订下来的milestone时，选择面对压力的方法就是宣称这件工作已经如期完成了，接着再想尽办法来圆这个谎。这在测试阶段特别容易发生。反正所有的东西是否有完整地经过测试人员测试，光看测试人员的脸是否面有难色，其实是很难看出来的。有经验的人会去看看defect的时间曲线是否收敛。不过大多数team member的想法，到这个节骨眼就会倾向快刀斩乱麻，这个时候就会努力说服自己：『我们写出来的软件品质不好，客户一直还不是那么清楚，如果他们到最后一刻才发现这个问题，这样子其实不是很好。不如早点给客户知道真实的状况，这样他们才有心理准备。好吧，我们就开始UAT吧。』
每次我看到了为了赶milestone，决定要让user提早开始UAT的项目，就会感到无比的惋惜。赶上了schedule，丧失了品质，与双方的信任，这样又获得了什么呢？
另外一种常见的流程省略，就是该做的review没有做，风险评估也好，项目评估也好，不是直接从时间表上勾掉，就是三两下草草了事。依据我个人的经验来说，很多必要的工作，一旦省略，或是做的不确实，短期内所带来的缩短时程，其实要付出数十倍的长期代价。为了meet一时的milestone，做出许多不利于整个project schedule的事情，其实是非常不智的行为。
追求银子弹
人类一直在追求科技上的进步，新发明，新创见，新的生产方式，新的开发技术，一直都带领着我们不断地往前走。然而project一旦开始delay，很多人，尤其是高阶主管们，在没有更好的解决方案下，多少总会期盼科技的创新，可以带来立即而有效的效果。
某一次status review meeting中。
吉娜：布鲁斯，从你的status report看来，目前项目的进度已经落后了百分之六十。你有没有什么对策？
布鲁斯：看来目前的项目已经再次上轨道了。可是如果想要赶上进度，老实说，还是比较困难。
吉娜：现在的状况的确是比以前要来的好。不过我们不可以就这样自满，况且，这个案子已经严重地超支了，我们做这个案子，已经是亏本在做。要是可以的话，当然要尽量超前原有的进度。对了，前一阵子我去参加seminar，我听说现在有一种叫做extreme programming的方法，要不要试试看？
布鲁斯叹了一口气：我会找时间去survey看看。看看有没有什么可以用在我们这个案子上的。
吉娜：好极了，我就知道你最有冒险犯难，勇于创新的精神。
对大多数的人来说，大胆的创新与愚蠢的不自量力之间的分野，其实是挺模糊的。老实说，即使采用相同的开发方法，应用在不同的团队身上，就会有截然不同的效果。对于一个只懂得用COBOL写Main frame上面程序的团队来说，要他们在一夕之间，改成用J2EE连Oracle数据库，写web application，还外加采用OOAD加上RUP混合着extreme programming的做法，光用听的，就觉得这票人根本就是自掘坟墓，想要来个出师未捷身先死。
新科技、新工法的引进，其实最好是能够用渐进的方法比较恰当。除非你打造的是全新的团队，否则太过激烈的变革，会很容易造成消化不良。这就跟吃到饱餐厅一样，有很多人只考虑到要尽可能的吃掉最多的美食，却没有考虑到自己的消化器官，有没有办法经得起这样的折腾。于是乎吃完之后，马上往厕所报到。
是因为美食不新鲜吗？大多数的状况都是因为你的身体没办法负荷这么多的食物。引进新的科技也是一样。除非你打造了一个全新的团队，而这个团队的大多数成员，都拥有所需要的经验。否则，在同一个项目采用太多的新工法，新技术，除了team member本身的抗拒心理需要克服之外，对于项目其实都是负面的影响远远多过于正面的效应。
我个人比较建议如果有新的领域要尝试的话，除非这个项目的成败，你完全不在乎，否则，一次不要尝试超过一个新技术；反过来说，如果你做的只是个pilot project，这个project本来就是拿来练兵用的，Well, have fun. You could try as many as you want.
银子弹存在吗？我想答案是肯定的。不过对于已经delay的project通常是无效的。因为project会delay，多半都是管理上的问题，与技术全然无关。管理上的问题，又多半不是引进一个管理上的新思维，或是引进一种技术上的创新，就可以解决的。任何管理上的新想法，通常需要经历过组织的学习，以及在实际工作上不断的练习与修正，才有办法顺利落实。这个过程通常要花很长的一段时间，所以根本就来不及解救眼前delay 的project。
更何况大多数时候，经理人们想引进的，都是新的工程技术，而不是什么革命性的管理观念。新技术，遇上旧思维，原本存在的问题依然存在，而有限的时间与精力又拿去花在尝试这些新的技术上，这些因素加起来的结果，通常会让已经delay的project，delay的更严重。所以每次我听到高阶主管要在已经快要灭顶的项目中来个大革命，心中总是会默念阿弥陀佛，愿真主保佑你们，阿门。
增加status report的频率
在某次的project review meeting上。
乔安娜：布鲁斯，依你的专业，你觉得这一次，schedule还会再delay多少？
布鲁斯：根据我跟我们team member的讨论，我认为需要最少再给我们五个月的时间，才能顺利上线。
乔安娜：五个月？这怎么可能？这种schedule我根本没有办法接受！这个project原本预估是六个月就要结束了，现在已经过了十一个月，而你告诉我还要五个月？！你有没有搞错啊。你们公司前一任的那个史黛拉，还告诉我们上个月就可以结案了，结果她做了两个月就走了，你一开始接PM的时候，不是说再给你三个月吗？我想你那时候对状况不太了解，我可以接受你估的时间会比较不准确。可是上个月你不是说再给你四个月吗？这段期间，有发生什么突发状况吗？结果今天，你居然跟我说你们还需要五个月的时间！
乔安娜想，你们这些浑蛋。自从接了这个project以后就倒霉到家。看来今天我的考绩跟股票就这样子去了…于是乎，愤愤不平地继续说：我不管了，你们的项目管理不好，我就来帮你做。我要你整理出来，每个人每天应该要完成的工作，也就是说你要给我一份daily schedule。你每天要准备一份status report，我才有办法每天跟我们的senior management update最新的status。我们两个人每天最少要开会一次来review status。只要进度一落后，你们就立刻要提出action plan，说明怎么样可以追上落后的进度。我想不这样做，我们没有办法掌握你们的进度。不做daily review，这一次一定还是会delay。
接着气冲冲地走了出去，留下一脸无辜的布鲁斯。
当你摆在写报告的时间越多，可以拿来写程序的时间就越少。这好象不需要太高的智商，就可以推论出来。不过对于很多客户来说，他们会觉得delay的原因就是因为他们没有掌握最完整，最详细的信息，以至于他们没有办法针对最新的情势，做出最有利的处置。只要他们掌握了最丰富，最实时的信息，就可以顺利地透过他们非凡的才智，做出对于项目最有利的决策。只要他们做了这么完美的决策，整个项目的进度，就会跟不断转动的飞轮一样，迈向一个光明的未来。
好吧，类似的故事我在股票市场上常常听到。掌握最完整最丰富信息的人，跟对了老师，就可以拥有超高的获利。所以有很多人，日以继夜地收集信息。然后呢，急急忙忙就跟着他所收集到的信息去做反应。所以短线不断进出，杀进又杀出。一般来说，除非他们本身就是拥有内线消息，或是专门炒作股票的作手，否则这种人都很少赚到什么钱。
不过对于客户来说，他们不会这样思考。对他们来说，一定是因为有某些人在该做事情的时候偷懒，或是没有全力在为他们做事，项目才会delay。直接可以推导出来的结论就会是，『我们需要时时刻刻保有最新，最实时的status report，才可以做好项目管理。』如果这些人刚好又是WBS的信徒的话就更惨。他们通常会要求项目经理先把系统切成许多细小的program，然后要天天提供by program的status report。然后就张大眼睛在看着这每一个小小的program，是否每支都可以如期完成。
对这些人来说，项目管理是一件再简单也不过的事情了，你只要先把工作切割，然后交给team member，接着只要把team member的进度每天收集起来，经过复杂的数学公式运算以后，就可以得到一个简单的指针，例如『今天已经完成了整个项目的百分之八十七。』接下来的工作，就是每天盯着这个指针，一手拿着皮鞭，另一手拿着红箩卜，努力地鞭策着team member做事就好了。『喂，今天预定的进度是要完成百分之九十，没做到不准下班。』
我还真有过一个这样的客户。当然她必定会觉得我过于简化这个问题。不过对她来说，项目管理的博大精深之处最少应该还包含下列三点：
1. 要出钱买晚餐或是宵夜给team member吃。以犒赏他们加班的辛劳，因为他们一定要加班才可以赶上进度。
2. 要事先帮on site人员申请他们公司的通行证，以免警卫不让他们进去。
3. 要熟背本日进度，以免高阶主管临时垂询时，无法在一秒内立刻回复。
当status report的频率增高时，其实就是指你每天要花更多的时间，来说明目前自己现在的进展如何，遇到的困难是什么。以便于让管理阶层，可以更迅速地掌握动态，并且更迅速地解决你所面临的问题。
然而项目通常最大的困难就是时间不够，更多的status report，就表示要开更多的会议来报告进度，并且要开更多的会，来讨论怎么样追上落后的进度。这必然就会造成更少的工作时间，也表示要赶上进度得要加更多的班。
如果project manager被逼着要每天报告进度，那么他最典型的反应就是要属下也要每天做一次status report。这就跟大鱼吃小鱼，小鱼吃虾米，虾米就只好去写status report的道理是相通的。增加status report的频率，其实就是让整个开发的成本增高。Project manager要可以报出一个今日最新开发进度，后面当然会有一堆帮他收集资料的engineer。你让team member花越多时间来帮你准备各式各样的进度报告，他们能够投注在实际开发工作上的心力就一定会比较低。
当然，频率的高低其实并没有一定的标准。对于某些人来说，daily review进度是一件习以为常的事情；对于某些人来说，一个礼拜，或是几个礼拜才review一次进度，才是正常的状态。在不同的phase，也可能会有不同的标准。在开发阶段，可能两个礼拜才review一次进度；在UAT时，可能每一天就review一次进度。
任何与team member的习惯或是与他们预期所不同的频率调整，除了要花费比原来多的时间在做『非生产性的工作』以外，还得要考虑对于士气会造成多大的影响。任何要调整频率的措施，都应该要经过谨慎的思考与充分的沟通后，才付诸实现。
话说回来，每个礼拜知道一次进度，跟每天知道一个编造出来的进度，差别真的有那么大吗？自己营造紧张气氛来吓自己，又会有什么好处呢？当你花太多时间在做micro-management，你就不会有心思去做真正的management。
增加人手以及焚膏继晷
进度落后了？加班吧？人力有没有问题？要不要增加一些帮手？没错，这是project delay时，最典型的思维模式。增加人手，其实并不是always是坏事。对于那种人力严重不足的项目来说，这有可能会是一场及时雨。增加人手的确可以解决问题。
很多人听过man-month myth，就会有一种无论如何，都不应该加人的错觉。直接推论的结果，得到的结论就是：任何项目只能一个人从头做到尾。否则，增加任何一个人，都会延迟项目的schedule。
当然这不是一个正确的论点。所以大多数人还是会想要增加人手。只是如果对于一个人数充足，甚至原本就已经是过多的项目来说的话，增加人手会带来的负面效应，则会远大于正面效应。事实上，如果人数多到项目经理没有力气进行管理的话，要嘛就是要想办法再增加管理的层级，不然则应该是要减少项目成员才是正途。
有些时候，加入新的成员，可以大幅减轻现有成员的负担；有些时候，增加新的成员，反倒会大幅增加现有成员的负担。怎么做才比较好，个中巧妙，存乎一心。这倒是没有什么标准做法可以依循，每个案子都会有不同的状况要考虑。虽然我不是这个领域的专家，不过在此分享一下我通常会考虑的几个方向：
1. 现有成员的工作量是否已经超出他们所能够负荷的工作量？
如果每个人看起来就是一副心力交瘁的模样，那么不找人来帮忙，大概就要准备收辞呈了。
2. 新成员的加入，会需要多少既有成员的传承？要占掉多少时间？
如果找到的人，没有办法上手，反倒是需要人一直去教他，这时候我会请这 个人去做一些他可以胜任的工作。或者是干脆就请他离开这个team。除了怕主要成员花太多时间去教他以外，明显的劳逸不均更是要避免的情况。
艾佛森：布鲁斯，为什么那个布莱德可以担任资深工程师，而我只是个工程师？他到我们这个案子来，什么都不会，教他又听不懂。我们现在已经delay了，我没有办法自己去写程序就算了，还要照顾他。自己都已经累得半死了，还要一直花时间教他，最气人的是，他的职等还比我高，领的薪水还比我多，这是什么道理嘛？
布鲁斯：没办法。布莱德是名校毕业的博士，这刚好是吉娜的最爱。虽然他没有什么实际的工作经验，可是吉娜一直觉得以他的学识，假以时日，他一定会有所贡献。现在刚好是他学习的时候。
艾佛森：这一点道理也没有。我们已经delay的这么惨了，还要带个拖油瓶。
布鲁斯：话也不是这样说，你尽量看有什么可以让他做的。反正我们现在人手不足，不然你找些打杂的事情叫他做好了。他要觉得没兴趣，就会自己想要离开了。
艾佛森：不然以后我有那种要改message，还是改GUI的工作就交给他好了。即使出了什么状况，也不会造成太大的危害。
3. 现有成员短期内会不会有异动？会不会想要离职？转调？是否还有其它人熟悉他现在手头上的工作？
任何一个手头上绑着工作的人离职，都会对项目造成影响。所以任何时候只要听到有人想要离职，那表示跟他喝喝咖啡，谈谈是非的时候又到了。项目做久了，慢慢了解到生命的真实现象：『任何一个你觉得百分百可以配合，绝对没问题，会跟你一起奋战到底的人，都有可能会在一夕之间离开。』
有些人是出于主动的意愿，像是离职、转调；有些人则会是遭受意外的打击。像是家中遭遇变故，或是生了重病，突然之间发作出来。你对他的倚赖越深，失去他的打击就会越大。所以最少要有几个人可以相互backup，这样一来，只要不要911来袭时，刚好整个team都在世贸大楼，否则应该可以顺利从成员的流失中存活。不过在台湾，人力不足是家常便饭，要能让engineer互相backup，这简直是痴人说梦。
我在学校时，总是觉得，只要有了文件，万事都ok。只要离开的人，留下够多的文件，人员的更替就不会有问题。现在就明白自己年幼时，是多么地无知识浅。任何时候，走掉一个经验丰富的人，即使他留下再多的文件，都没有办法弥补这种损失。接手的人，常常光是要把文件看过一次都要很久的时间，更不要提如果你现在遇到一个状况，得要在很短的时间内找到正确的文件，这件事到底有多困难了。
文件并没有办法取代经验，当然，并不是所有资深的人，都拥有过人的经验与智能。不过有经验的人，在他离开的那一剎那，绝对是他人无法取代的。许多有智能的人，都是从实际的教训中，学到在困境中存活的智能与经验。这些人常常只要透过直觉来判断，就可以做出正确的决策。对于企业来说，唯一的困难应该是在于，一个人是否具有智能，并不会写在脸上。
一个人如果下定决心真要走，跟天要下雨，女儿长大要嫁人一样，是拦不住的。能够做的，旧是找人想办法去跟他办理交接。很多时候，我们都是在重要成员要