CSDN博客

img singlelog

Delayed Project(下)

发表于2003/10/7 20:45:00  862人阅读

交相指责
项目会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之后,他还可以从中获得不少好处。他对于资源巧妙的运用,简直是令人叹为观止。走笔至此,不禁跟吕留良有相同的慨叹:『百无一用是书生。』或许我们应该少读点书,多学学躺在地上装死,以及睁眼说瞎话的技巧,这样才能当做一个更称职的项目经理吧。
※作者注:关于吕留良的慨叹,请参考金庸先生所着,鹿鼎记第四十回。

 

0 0

相关博文

我的热门文章

img
取 消
img