Chinaunix首页 | 论坛 | 博客

分类: 信息化

2016-10-21 13:55:55

『圣旨到。』

『吾皇万岁万万岁。』

『奉天承运,皇帝诏曰,本项目应在三个月后准时完成,若有违背者…杀无赦!钦此。』

『臣谢主隆恩。』

宣读圣旨的公公前脚才一离开,只见项目经理满脸铁青,面对满门老小,不禁仰天长叹,继之以涕泪纵横:『唉,想不到老夫一世英名,今日眼看着就要葬送在这个项目上。三个月…这怎么可能呢?连测试的时间都不够啊,眼见着这就是个抄家灭族的欺君大罪了,这可该如何是好啊…』

很多时候,我们所遇到的项目,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。只要离开的人,留下够多的文件,人员的更替就不会有问题。现在就明白自己年幼时,是多么地无知识浅。任何时候,走掉一个经验丰富的人,即使他留下再多的文件,都没有办法弥补这种损失。接手的人,常常光是要把文件看过一次都要很久的时间,更不要提如果你现在遇到一个状况,得要在很短的时间内找到正确的文件,这件事到底有多困难了。

文件并没有办法取代经验,当然,并不是所有资深的人,都拥有过人的经验与智能。不过有经验的人,在他离开的那一刹那,绝对是他人无法取代的。许多有智能的人,都是从实际的教训中,学到在困境中存活的智能与经验。这些人常常只要透过直觉来判断,就可以做出正确的决策。对于企业来说,唯一的困难应该是在于,一个人是否具有智能,并不会写在脸上。

一个人如果下定决心真要走,跟天要下雨,女儿长大要嫁人一样,是拦不住的。能够做的,旧是找人想办法去跟他办理交接。很多时候,我们都是在重要成员要离职时,才努力地思考怎么交接。然而再怎么交接,其实效果都有限。还不如平时就多想想,要怎么做才能让这些人愿意留下来一起奋斗。

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

※作者注:关于吕留良的慨叹,请参考金庸先生所着,鹿鼎记第四十回。


阅读(200) | 评论(0) | 转发(0) |
0

上一篇:People Management

下一篇:Process

给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册