本文主要是介绍Delayed 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。只要离开的人，留下够多的文件，人员的更替就不会有问题。现在就明白自己年幼时，是多么地无知识浅。任何时候，走掉一个经验丰富的人，即使他留下再多的文件，都没有办法弥补这种损失。接手的人，常常光是要把文件看过一次都要很久的时间，更不要提如果你现在遇到一个状况，得要在很短的时间内找到正确的文件，这件事到底有多困难了。
文件并没有办法取代经验，当然，并不是所有资深的人，都拥有过人的经验与智能。不过有经验的人，在他离开的那一剎那，绝对是他人无法取代的。许多有智能的人，都是从实际的教训中，学到在困境中存活的智能与经验。这些人常常只要透过直觉来判断，就可以做出正确的决策。对于企业来说，唯一的困难应该是在于，一个人是否具有智能，并不会写在脸上。
一个人如果下定决心真要走，跟天要下雨，女儿长大要嫁人一样，是拦不住的。能够做的，旧是找人想办法去跟他办理交接。很多时候，我们都是在重要成员要离职时，才努力地思考怎么交接。然而再怎么交接，其实效果都有限。还不如平时就多想想，要怎么做才能让这些人愿意留下来一起奋斗。
4. 目前处于项目的哪个阶段？如果已经是处于项目的末期了，有没有必要加入一个新的面孔？
有些时候，高阶主管会因为现在有个人头多出来没事做，就询问项目经理要不要让这个人加入一个项目。老实说，有些事情，过了那个时间点，其实就不是那么重要了。每次看到这种到了最后一刻才想到该加入的人，就像是看到这样的场景：
男女双方，在经历了一场床上大战后，开始在床上抽烟谈天，此时男方忽然悠悠地冒出了一句：『什么，今天不是安全期喔，那我刚刚是不是应该戴上套子啊？』
这就跟已经过了UAT，才指派了一个SA加入这个团队一样：『你现在才讲这个，会不会太晚了一点啊？』
就项目而言，晚来的support，有时候还不如干脆就没有support。做很多事情，时机是非常重要的。一个人如果没有在适当的时间，加入这个项目，那就真的要好好考虑，还有没有让这个人join的必要了。即使他的能力再强都一样。
5. 新人的加入，会不会造成组织的政治关系产生变化？会不会加入一个人以后，反倒是衍生出很多问题要我去处理？例如韦君与绍洋正在热恋，韦君已经在team里面的话，我就会避免把绍洋也找进来，不然小俩口整天打情骂俏情话绵绵，让大家鸡皮疙瘩掉满地，这可受不了。如果韦君跟佑威怎么样都处不好，三天一小吵，五天一大吵，我一定也会避免把佑威找进来。
除了增加人手以外，最常看到的就是加班。偶一为之的加班，可能会对生产力有帮助，太过频繁的加班，对于士气与实际生产力，则都会有负面的影响。我并不建议在任何delay的项目中，都把加班当作是一个有效的赶上进度的方法。如果只需要偶一为之，短期的加班方案，或许还可一试。
目前为止，我所提出来的解决方案，都没什么实际上的功效，拿来当笑话看看就好了。不过接下来的这几个方法，则是我觉得实务上真的可以发生一些效用的方案。
更换项目经理
对于一个已经delay的项目来说，其实换人做做看，不见得是一件坏事。只是要下这种决定，需要非常非常谨慎的思考。当事人的意愿尤其重要。遇到那种异常艰辛的项目，其实有许多项目经理是巴不得可以赶快抽腿。对于继任的人来说，则是要接下一个烫手山芋，所以对于要交接的双方，都需要仔细的思考。如果你有好几个项目要伤神，我建议你优先考虑那种长期处于资源不足的项目。
对于很多项目经理来说，人手不足，时间不够，是家常便饭。可是在普遍都很惨的状况下，总有一些项目经理的日子，过得就是比别人都来得艰辛。所以相对地，这些人内心的不满，也就会比别人来得深刻。这跟这个人的EQ高低，其实只有间接的关系。直接关联的就会是这个案子资源短缺的情况，到底有多么地严重。当一个人感到孤立无援的时候，内心的怨怼与不满，常常会对于项目采取相当负面的态度。一旦到了这个时候，就该考虑更换PM了。
我个人建议在下列的情况下，可以考虑更换项目经理：
1. 与客户的关系已经势如水火
2. 项目经理已经开始失去理智，无法心平气和的处理事情，而是采取非常激进暴躁的手段来进行管理
3. 项目经理明显无法负荷，已经没有办法针对现有项目进行适当的管理措施
4. 项目经理明显怠职
5. 大多数团队成员提出离职或是转调部门的申请
更换项目经理，不管是在任何一个时间点来说，都绝对是着险棋，有可能会让项目浴火重生，也有可能让项目万劫不复。任何一个新任PM，都会有适应上的问题。如果他跟大多数的team member，没以共事过的经验，那也会有工作默契上的问题。如果随着他的到来，空降了很多国王的人马，那潜在的问题可能会更多。因为更换PM的结果很难预料，如果可以不换的话，最好还是原班人马，一路到底比较妥当。可是如果项目经理的存在，已经没有办法对于团队有任何正面的效益的话，那么及时更换项目经理，就是一个必要的措施。否则问题会持续蔓延下去，到最后要收拾就很困难了。
专注在解决方案上，而非责任归属
某次的project review meeting，乔安娜的老板麦克与吉娜都列席参加。
麦克：布鲁斯，你能不能告诉我，我们现在会delay的ROOT CAUSE是什么？
布鲁斯很紧张地说：目前我们会delay的root cause，都是因为requirement不清楚所造成的。User在开发的过程中，提出太多的requirement，完全没有节制。
乔安娜：这种说法一点也不公平。都是因为你们的SA换人的关系…
布鲁斯说：我们SA都有进行完整的交接啊。我觉得最大的问题，还是因为使用者的需求一直没办法确定下来…
麦克打断布鲁斯跟乔安娜的话：没关系，你们先不要激动。如果这就是root cause，布鲁斯，你有没有什么相对应的SOLUTION？
布鲁斯：当然有。我想最好的方法就是用我们现在的prototype跟user重新进行访谈。然后再请我们的SA把use case仔细地写下来，跟user好好沟通。
麦克再次打断布鲁斯的话：没有关系。既然你已经有了solution，我想你得要跟乔安娜好好讨论你们的ACTION PLAN，包含整个resource上的重新规划、schedule重新拟定。我想下个礼拜，就可以看到你们完整的plan。不知道吉娜，你有没有什么看法？
吉娜：今天我来，是抱着一个学习的心理来列席的。很抱歉我们这个案子会造成大家这么大的困扰。我们当然是抱持着戒慎恐惧的心理来做这个案子，也很谢谢麦克能够给我们一个将功赎罪的机会。我想布鲁斯跟乔安娜都这么优秀，一定可以把这个项目顺利告一段落…(好吧，她继续打了十分钟的官腔，因为官很大，所以大家都只好列席点头不已。)
<商用英语教学>请问在上述的对话中，听到哪些企业主管常用英文字汇呢？
<正确答案>所有的关键词都用大写标明出来了，就是Root cause, solution, and action plan。你猜对了吗？
如果你手头上有个已经delay的案子，客户的高阶主管要你针对这个案子的状况进行报告，那么很有可能，你就会听到这几个字眼：『Root cause, solution, and action plan』简单的说，就是为什么你的案子，会变成今天这个田地？有没有什么根本的问题？面对这个问题，你有没有答案？如果有的话，你打算怎么去解决这个问题？有没有详细的计划？
我自己开过不少次这种会议，当然，双方如果关系不甚融洽，可能在讨论目前的项目为什么会这么惨时，就开始交相指责，开始对骂。所以光是root cause的讨论，就会是一片刀光血影。
开这种会的重点，不是要找谁该负责，而是要找问题在哪里。一直要到大家把讨论的重心放在怎么找出问题，并且要如何解决问题时，项目的情况才会获得改善。对于不懂IT的高阶主管来说，其实他们在乎的，不是责任的归属，而是现在的状况是什么？你们建议的solution是什么？有没有什么潜在的问题？目前又打算做些什么？
老实说，这是比较正面的看法。通常只有这样子做，项目才可以从濒临死亡中复活。当双方都一直争论到底责任应该归属在哪一方时，如果没有诉讼的可能性的话，我建议你可以试试认错的方式。不管错在哪一方，通通假设是错在我们身上，先把推过诿责的循环打破。
<推过诿责的循环>
客户：这都是你们的错。
PM：哪有这种事情，明明就是因为你们的错而引起的。
客户：我们怎么可能会有错？我们就是因为不会，才要花钱请你们过来。请你们来了以后，哎呀呀，居然都是我们的错，真是花钱找骂挨。这分明都是因为你们的人太差才会变成现在这副德性。
PM：你讲话很不客观喔，这是直接的人身攻击喔…
客户：我哪有？
PM：你就是。
客户：我哪有？
PM：你就是…
好吧，小学生吵架差不多也是这副德性。当你批评别人讲话不客观的时候，你算不算在进行人身攻击呢？不过在吵的不可开交天昏地暗的过程里，通常我们不会顾虑到这一点。
<打破推过诿责的循环>
客户：这都是你们的错。
PM：既然我们公司接下了这个项目，我想关于这个案子的成败，我们确实要负全部的责任。不过我们比较在乎的是怎么样可以解决目前现有的问题。
客户：你们要是早一点发现问题就好了。对于我们公司形象上的损失，这是多么严重的一件事情？真要负责，你们可以负什么责？
PM：我想问题这么严重，我们确实也没有办法给你们一个满意的交代。不过我希望我们现在可以先把重心，放在怎么解决问题，让大家都得到一个满意的结果上。至于我们该怎么补救，该做的，我们一定会做。
客户：你有什么建议？
当你承认错都在你时，其实这个互相指责的争论就可以告一段落了。很多时候，就只有在这样的状况底下，双方才有办法往前继续迈进。如果讨论的重点，不在于应该要谁来为现在的场面负责，而是在于要怎么样才可以改善我们现在的处境，那么要找出双方都可以同意的solution，应该就指日可待了。
缩小scope
对于一个delay的project来说，还有什么真正有效的solution呢？釜底抽薪来说，把要deliver的东西变少，应该就有机会可以赶上schedule。当然这里可能会牵涉到合约，或是其它双方对于scope以及schedule的协议，需要重新订定。
在这里唯一要注意的就是，把scope缩小，应该是把整个项目的scope缩小，而不是把这个phase的scope缩小，另外多增加几个phase，或是把现在这个phase的功能，移到下个phase去。
如果你做的是把这个phase的scope缩小，那么对于整个项目来说，其实你只是把一部份的工作给延后了。会衍生的问题，通常就会是开发经费会大幅飙高。整个project的开发时间，有可能不会提前而会往后延。好处当然是可以符合使用者的需要，让他们提早用到他们想用的功能。不过一个原本要分两个phase作完的案子，如果多切了一个phase出来的话，直接的影响是什么？
答案是整个project的schedule跟开发经费都会无法避免地升高。很多人其实没有警觉过，增加phase对于项目到底会有什么影响。增加一个phase，表示又多一个版本需要control，又多一个独立的版本需要跟其它不同phase的系统进行整合，也表示需要独立的测试人员进行独立的测试。无形之中，也增加change发生的可能性。因此到后来，可能整个project的schedule跟经费都会往上延伸。
所以如果以整个project来看的话，把scope往后推到不同的phase中deliver，并不见得是好事。只有把整个项目的scope给缩小，才会有真正的帮助。不过对于台湾的项目来说，这个机率其实是蛮小的。因为大多数的项目，都有一定的商业上策略的考量。这个时候为什么需要推出这些功能，除了一般人员的业绩以外，高阶主管多半都会有一些自己的想法与策略，希望能够搭配这个schedule以及这样的scope来进行。所以任何schedule与scope上面的异动，都有可能会冲击到这些人内心既有的想法，而这个才是最难解的部分。软件项目的开发，问题多半是在管理与政治面。真正技术上的难题好解，政治的问题才是真正棘手的部分。
况且大多数时候，scope其实是明确地记载在双方的合约中，要变更的话，就更加困难了。所以在大多数的状况下，修改scope只能拿来当成备案之一，而无法当成是主要的解决方案。
重新订定出合理的schedule，并配合适度的项目评估措施
从事软件项目开发，事情不如预期的可能性通常都很高。自欺欺人应该不是什么高明的策略，尽管你可能是抱持着蛮崇高的理由才会说一些『善意的谎言』，不过这种策略通常会有很多负面的效应。我个人认为绝对的诚实会比较恰当，把所有的问题跟真相摊在阳光下，才是最好的解决方法。
估schedule，其实跟在竞标商品一样。你想用100块去标，有人喊了101，你会不会想要再往上加一点？每次要不要往上加码，其实都是一个判断的机会。这两者除了schedule越估越久，跟标价会越喊越高很像以外；要随时依据市场上的状况，提出最新的标价，其实也是很相似的。项目经理其实随时都应该要依据现在的状况，评估整个schedule会不会受到什么影响，接着做出应有的决策。如果你只是很简单地把现在这个phase的delay，推到下一个phase去的话，除了会丧失再次练习做评估与预测的机会之外，也丧失了随着事情的发展调整你的策略的可能性。
所以在项目进行的过程里面，其实需要在适当的时机，持续地进行项目的评估。与解盘法最大的不同，其实主要是在于心态上面。不断地评估项目情势并不是为了要找借口，也不是在预测项目结束的落点，而是在找目前还有什么问题是应该要获得解决，以及各个resource应该要在什么时候投入项目的开发。
当项目经理开始认真地评估项目进行的状态时，这时候解决方案的核心，就会在于该如何才能与客户敲出一个双方都可以接受的schedule。大多数时候，基于利害考量下的妥协，双方多半都只能商量出一些对于短期有利，可是对于长期有害的solution。例如最常见的方法就是，我们增加一个phase，先把user比较急迫的功能，在这个phase中deliver。在已经delay的项目中，双赢的方案几乎是不存在的。
最好的结果，当然是顾客与厂商之间坐下来好好谈谈，这个项目主要的目标是什么？要达成目标，在有限的时间内，又可以完成些什么？以及整个项目要顺利结案，大概会花多少的时间？毕竟在项目开始，一片混沌时的估计，本来就应该要进行某种程度的修正，才会比较符合实际的状况。只有双方坐下来，将双方需要完成的目标摊开来，务实地讨论，重新订定schedule，并且订定适当的项目评估措施，这样子即使delay，最少也是在一个可以控制的范围内。
至于怎么评估，怎么样进行控制会比较好呢？我想推荐一种我没有完全实际用过，只有从书上看来的方法：『Critical Chain Project Management』(作者注)。在我自己读过相关书籍以后，管理项目时，通常就会清楚地把focus，聚集在critical path以及resource的availability上面。这些concept通常在软件工程的书籍里面，是找不到的。
※作者注：真的有本书就叫做这个名字：Critical Chain Project Management。只是我还没时间拜读就是了。如果你对于怎么安排schedule有兴趣，我建议你去看看TOC的书。在此再次推荐高德拉特所写的Critical Chain。不过因为这是本小说，所以我建议你可以找些相关的延伸阅读。我自己读过的是Project Management in the Fast Lane。里面的观念，对我还蛮有用的。:-)
结语
曾经有段时间，我接到一个全新的案子，一开始项目只有三个人在撑。后来miss掉蛮多milestone，被客户骂到狗血淋头，我就开始不停地工作，日以继夜地加班，唯恐整个项目，就毁在自己的手里。与我一起工作的伙伴，也都处在我所施加的潜在压力下，非常艰苦地长时间工作。到最后，那个项目meet某一个delay过后的milestone，也deliver出一些看起来很像是系统的东西。可是大部分的team member都走光了。对我来说，虽然看起来我们好象完成什么东西，可是team member的相继离开，让我觉得这个项目是一个彻底的失败。
当你看到一个manager，逼迫着team member不停地加班，潜藏在他内心深处的，就是一个害怕失败又不知所措的灵魂。很多时候，当你越在乎项目的成败，越被schedule引领你所有的行为，你的思考就会变得越狭隘。
怎么样才可以跳脱这个困境呢？换个角度吧。先假设你手头上的案子是全然的失败，delay远远超出你的想象，想想你会有什么下场？公司会受到多大的打击？先试着去接受这个事实，接着请想想，你有没有什么可以做的事情，可以让这个项目脱离这么完全又彻底的失败？有没有什么是还有机会改善？不管是多小的改善都好。
通常经过这样的思考，就有机会从完全不一样的观点来看待事情了。Delay就delay吧，那又怎么样呢？大不了就是这个project fail，当作是公司付给你很高的学费嘛。So what？当你能置之死地之后，就有机会可以浴火重生。
每个人对于一件工作要做多久，都会有不同的想法。因为每个人的能力与经验不同，同一件事情交给不同的两个人进行估计，很少会估出完全相同的schedule。再加上把大家的东西整合起来，到底需要多少时间，就是一个更难预测的问题。
以产业界目前流行的方法来说，如果你是个用传统结构化系统分析开发系统的人，可以用function point来帮忙估计；用UML + OOAD的人，可以试试用use case point来进行估计。这些方法最少背后还有一套理论根据。如果你对于你想要开发的系统已经了然于胸，你当然也可以使用WBS来进行规划，只要记得加上让大家的东西整合在一起的时间就好了，不过这个时间通常都不短。
不管你用哪种方法，持续地收集这方面的信息都是必要的。这会让你有鉴往知来的机会。不过不管你采用哪种方法，其实都不能保证你估出来的schedule，就会准到哪里去。因为每个不同的团队，在不同的项目下，都有属于他们自己的故事。
估计其实只是项目管理中的一环，很多时候，不管你做了再多学理上的研究与分析，客户想要8月上线，这个就必然会变成是预期的deadline。不管你花再多时间进行估计都没用。怎么面对即将delay的schedule，才是我们每天生活要面对的问题。
对我来说，项目管理除了软件工程上的理论以外，实际工作的体会，才是让我自己收获最多的。很多体会都是在实际工作的过程中，做了很多傻事，不断地修正自己的看法，才慢慢形成的。而这个修正的过程，虽然很痛苦，其实事后看起来，还是一件很有趣的事情。
当我在思索该怎么面对delay的schedule时，忽然想起电影铁达尼号里的乐师。在铁达尼号快要沉没时，还能悠哉悠哉，气定神闲地弹奏音乐，如果一个人可以修养到这种地步，或许就可以心平气和地面对所有不可预见的风险吧。
另一个脑中浮现的人物则是金庸笔下的韦小宝。他像是一只打不死的蟑螂。在相同的时间内，他要面对各式各样不同的项目，而且到最后，大多数的项目都可以顺利deliver，没有deliver的也获得了客户的肯定。除此之外，在项目deliver之后，他还可以从中获得不少好处。他对于资源巧妙的运用，简直是令人叹为观止。走笔至此，不禁跟吕留良有相同的慨叹：『百无一用是书生。』或许我们应该少读点书，多学学躺在地上装死，以及睁眼说瞎话的技巧，这样才能当做一个更称职的项目经理吧。
※作者注：关于吕留良的慨叹，请参考金庸先生所着，鹿鼎记第四十回。
这篇关于Delayed Project(下)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
