CSDN博客

img singlelog

独孤木专栏Delayed Project(上)

发表于2003/9/24 14:57:00  938人阅读

『圣旨到。』
『吾皇万岁万万岁。』
『奉天承运,皇帝诏曰,本项目应在三个月后准时完成,若有违背者…杀无赦!钦此。』
『臣谢主隆恩。』
宣读圣旨的公公前脚才一离开,只见项目经理满脸铁青,面对满门老小,不禁仰天长叹,继之以涕泪纵横:『唉,想不到老夫一世英名,今日眼看着就要葬送在这个项目上。三个月…这怎么可能呢?连测试的时间都不够啊,眼见着这就是个抄家灭族的欺君大罪了,这可该如何是好啊…』
很多时候,我们所遇到的项目,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就可以赶上的人,如果不是全然地敷衍的话,最少还会想想怎么赶上进度。有些人会采取截然不同的角度,他们努力地想,用力地想,可是就是没有结论。到最后就会采取下面的这个做法:拒绝任何明确的承诺。
0 0

相关博文

我的热门文章

img
取 消
img