CSDN博客

img trybird

历尽英雄劫 赢得美人归

发表于2003/4/7 10:35:00  1792人阅读

历尽英雄劫 赢得美人归

 

——项目管理小说《最后期限》读后批评

 

“当心!千万别喝陌生人递给你的饮料。”——坐长途客车时在车厢内曾看到过这样的警示标语。常外出的人都知道要提防这样的事——有人诱你喝下下了药的毒水,好趁你被麻倒后实施劫财。

 

可有个叫汤普金斯的老外就不懂得这些了,汤普金斯是谁呢?他是一家大型电信公司的资深项目经理。不过更确切地讲应该是“曾经是”,因为他已经跟几千名同事一起被炒了鱿鱼,成了无业游民了。这很有点象中国某家IT企业,年初时一口气吞进五千多人,临近年尾时又都吐掉。不过汤普金斯曾受雇的这家公司倒看上去还很仁善,虽把几千员工都炒掉了,但人力资源部还组织这些人来公司礼堂看节目,想方设法麻醉并安慰他们,使其尽量不到公司的竞争对手那里去效力。就在这令人昏昏欲睡的无聊演出进行当中,汤普金斯突地眼睛一亮,发现了旁边坐着一个可爱的美眉,便搭讪上美眉,两人聊起来很投机,越聊越欢。聊天很费吐沫的呀,于是便要喝水补充,偏就那个美眉知道好挑剔爱讲究的汤普金斯喜欢喝哪种牌子的饮料,并投其所好,随手把饮料递给他。你想啊,英雄难过美人关,美眉的好意怎敢不承领呢?于是继续起劲地边喝边聊,终于——他被放倒了……随后就梦游般地在美眉的暖玉温香诱导下被挟带着走,嘴里还一个劲地说着梦话。然后就在半梦半醒中被美眉开着飞机给运送到了一个叫做“摩罗维亚”的岛国。——由艺术大师Tom DeMarco创作的这出名为《最后期限》的奥德塞式传奇喜剧,便在这样的马戏团气氛中拉开了帷幕。

 

汤普金斯中招后遭劫,人家要劫的是他的才而不是财。就象中国古代的思想家老子被把守函谷关的军阀尹喜强迫着写下《道德经》一样,汤普金斯也被美眉威逼利诱来管理摩罗维亚的软件开发项目,力求在短期内使得摩罗维亚成为软件出口大国。国家元首给了他足够的信赖和权力,任他放手去做。产品设计目标都对准了象PhotoShop之类6个世界最知名的软件产品,给他的人手足够多甚至大大超出所需。汤普金斯于是就按自己意愿来做受控管理的对比实验,把大批程序员分成了18个团队,每3个对应一个软件产品,团队有着不同的规模并运用不同的方法,彼此相互竞争,并都面对着相同的一个根本无法达成的最后期限。他就这样塞翁失马后又重新操刀上阵了。可他从来没管理过这么大规模的团队,而他的参谋部人员也还一个都没到位,我们不禁为他捏了把汗——这能成吗?呵呵,看了这本小说后你就清楚了。

 

作者Tom DeMarco显然是在瞎掰胡扯,费尽心思编了这么个既荒唐又浪漫的故事来哄骗读者。但是大多数人内心里都是甘愿受骗情愿上当的,不然电影就没那么多人来看了,小说也不会有那么多人去读了。书中的人物、地点和情节都是虚拟的,可由于编得巧妙,很多地方还是给人以真实可触的感觉。不过Tom DeMarco写这部小说的要旨不仅仅是为了编个传奇故事来娱乐大家,而是要通过讲故事这种寓教于乐的方式来解说项目管理的一些最重要的原则,使读者通过虚拟的项目来学习、理解和体验最重要的项目管理的知识与经验。可以说项目管理方面的理论知识学起来的确是很艰涩的,而这方面的书籍大多也比较枯燥,消化起来不容易。有位在银行负责IT部门的朋友曾问过我,看他考什么认证好一些,我建议他考PMP (Project Management Professional Certification),他听过介绍后对我说:“那还不得让我扒层皮啊!” 最后他决定考新设的国家项目管理师认证,也许他是考虑这会跟国内高程考试一样能有很多“捷径”可走,更轻松一些吧。想来项目管理方面的知识也确实够庞杂难学的了,各方面的理论还在不断发展中,新观点新思想也还层出不穷。但现在好了,在你读《最后期限》这本写得相当流畅的小说的同时,也能了解到项目管理的相关知识要点,良药不再苦口,忠言写进故事,不亦乐乎?

 

Tom DeMarco用讲故事的方式来图解管理原理的好处十分明显的,效果是极其成功的。我们跟着汤普金斯一起发现“真理”的同时,也会探究到这些“真理”的来由,使得我们对很多道理,真正做到了不但知其然也知其所以然,也对这些理论什么情况下适用什么地方不实用,留下了更进一步的思考。

 

在此书每一章节结尾处,都列出了汤普金斯先生在日记里写下的提炼精华的管理原则。这些原则很象《圣经》里的戒律,可以说汤普金斯是个称职的项目经理,他每晚就是再困再累甚至喝多了酒的时候,也不忘了坚持把当天脑海中感悟到的思想火花记录下来,力求在项目进程中学到真知。这些分类论述的原则,涵盖了管理要素、管理者素质、管理艺术、人员心理、人员选聘与解聘、任务分派、冲突调解、高层管理强权干预、工作压力、风险管理、过程改进、效率改进、建模、度量、文档规格、会议安排等等软件开发项目所涉及到的各方面管理内容, 全书加起来共有111条这样的管理格言和训诫。小说的故事情节是次要的,而这些菜谱似的条例才是书中的画龙点睛之处。

 

如果说这本小说是Tom DeMarco发射的一记糖衣炮弹的话,那小说的形式和内容都只是糖衣,而这些精到的管理语丝才是炮弹。其实这本书要完全从文学角度来评价,恐怕也只能算得上是部三流小说,是另外一个英雄抱美人的俗套故事。它也绝非一本纯管理科学的论著,也不是心理学、社会学方面的手册,更不是商业资本投资运作指南。而也许就是这“四不象”,才使得此书颇具卖点。

 

这本书的中文版是清华大学出版社在2003年年初出版的,封面上的广告词哗众取宠地宣称这是“中国第一本项目管理小说”,实际上更准确地说应是“中国第一本被译介过来的项目管理小说”(当然我们更希望有朝一日也能有一本完全由中国人原创的“中国第一本项目管理小说”)。译者是《程序员》杂志的技术编辑熊节先生和他的女友马姗姗小姐,他们也同时是UMLChina网站翻译组的成员。熊节先生是位年轻有为才情并茂的技术作家和写手,他和女友的联手翻译还是十分准确到位的,译笔也很流畅。这样看来书的另一句广告词说“趣味、精彩、引人深思”,还是不为过的,比较准确道出了这本小说的特点。书的内容简介里还夸大其词煞有介事地说“掌握了这些经验,你一定也可以成为一名优秀项目经理”——且不说对经验的“掌握”绝不能仅通过阅读来实现,而是要更多地通过实际工作的历练来实现;就算读者真的掌握了这本书中的经验,我看也不见得都“一定也可以成为一名优秀项目经理”。这就象说“掌握了这些《孙子兵法》的经验,你一定也可以成为一名优秀的将军;掌握了这些马基雅维里《君主论》的经验,你一定也可以成为一个杰出的国王”一样荒谬。明眼人一看便知,这纯属为了吸眼球吊胃口好使你掏腰包买书而抛出的噱头。不过我读了这本书后还是觉得付出银子买回它是不后悔的,一个字:值!

 

我是在羊年除夕之夜一口气畅快地读完这部项目管理小说的,记得在CSDN网站上有个女孩版主自称是“红袖添香夜读书的小乖乖”,照此我就该是“除夕守岁夜读书的老油条”了,读后感觉是经历了一次很愉快的阅读之旅,滋味就跟在除夕夜里随爆竹声吃下一大盘香喷喷的水饺一样,真的很爽。《聊斋志异》里曾写过一个被砍头的死囚,非要在行刑时死于快刀手之下,并且脑袋被砍掉后还要大赞一句“好快刀!”Tom DeMarco就是这样的一个刽子手,令我伸着脖子被他宰过后,还要赞他“好快刀”。

 

贯穿整本书的主题就一个字:人。这跟Tom DeMarco的另一本书《人件》(Peopleware)是一气相通的,当然《人件》基本上是站在了程序员的立场,而《最后期限》更多地出发于项目经理的视角。书中自始至终在强调下面的优质管理的四大要素:

·选择正确的人。

·为他们分配正确的工作。

·保持他们的积极性。

·帮助团队凝聚起来并保持团队的凝聚力。

(其他一切都只是“文案”。)

这也就是我们常说的知人、善任、鼓劲、抱团的意思。

 

由于作者认为“人”是项目中最宝贵的资源和要素,而且是项目成功的关键,对项目的管理也就是对人的管理,所以书中总结出的上百条管理方面的金科玉律,大多都是关于项目管理中所涉及的主要针对人的软性主题,如人的心理情绪、人性弱点及人际关系等,而其他那些被作者认为都是“文案”的管理硬科学方面的内容则很少提及。当然书中的管理信条也多是作者本人所要推销的理念,而不全都是项目管理科学所公认的观点。

 

不过我是绝对赞同Tom DeMarco以人为本的项目管理思想的。就是说项目管理最重要的事情就是对人的管理;人是项目最重要的资源和成功关键;一个经实际项目磨练而打造出来的、凝聚力和战斗力都极强的团队,本身就是一个成功的价值非凡的产品,而产品质量中也蕴涵了人的内在品质。所以讲管理只讲“硬”的方面,不讲涉及人的“软”的方面,绝对是买椟还珠舍本求末。

 

大家都知道管理学真正上升为一门科学,是从泰勒(Frederick Taylor)的机械管理学开始的,他的方法就是把人当成了机器,对工人的动作进行分解并进行科学研究,以找出最佳操作,再力求教会所有工人都灵巧地工作,总的说来就是要象提高机器性能一样来提高工人工作的熟练程度。不知怎么回事,我一想到泰勒的理论,脑海里就很自然再现出卓别林在电影《摩登时代》里被快速流水线玩得团团转而穷于应付最终还被卷进大机器里的滑稽情景。当然现代软件开发也是复杂的现代大工业,也很少是小作坊中的手工活,许多管理者也希望把程序员造就成熟练的螺丝工,或期望程序员本身就象一颗工作良好的螺丝一样,拧在团队这台大机器上就能很好地工作。但实际上程序员毕竟不是螺丝钉,拧在哪里就能安安稳稳地固在那里不松懈。就象《最后期限》中所比喻的,程序员就象玩世不恭的猫,在天大的压力下,也不会改变其心高气傲桀骜不驯的天性的。曾有人建议中国要仿效印度把程序员造就成“软件蓝领”,这事一提,程序员中十个有九个就会拍案而起愤情怒斥,因为几乎所有程序员都会坚持认为自己从事的是高级技术工作,当然不甘被当做什么低级的“蓝领”工人来对待了。所以国内有些软件公司的管理者,对自己手下的不服管理的技术牛人(或技术牛仔)尤其是技术军阀型的程序员高手总感到很头疼,这都是不重视人在管理中的核心作用所带来的恶果。

 

现代管理理论发展的方向就是更重视人的作用,提倡人本主义和人性化管理。比尔·盖茨说过,他做过的最聪明的事就是雇佣了一帮聪明人;想来古代的孟尝君善用鸡鸣狗盗之士也算得上是聪明做法吧。宝洁公司的管理者也曾说过,如果把公司的资金都抽掉,厂房设备都搬走,但只要还留下了人,那么不出三年宝洁公司还会重新崛起成为世界一流公司的。这都说明了人的因素的重要,就是Tom DeMarco所说的“选用正确的人员,分配正确的任务,保持他们的斗志,增强他们的凝聚”的意思。

 

看得出来,对于病态的政治、病态的上司以及由于病态统治所带来的裁员,Tom DeMarco简直是太深恶痛绝了;所以才塑造了贝洛克这么个十足讨厌和变态的恶人形象,并且作者花了很大的篇幅来论述这个问题对项目的危害,第11章、第21章、第22章后面的管理日志上记载的都是关于这方面的感悟。指出他们的乱施威和乱指挥不但对项目无益,反倒会毁灭整个项目,一旦有成果时他们还要占有不应得的荣誉。对于他们的所谓权威,下面的员工也只能用欺瞒来糊弄他们,从表面上让他们的淫威和虚荣加以得逞。书中很多处都留有对贝洛克这个管理层施虐狂的最狠毒的痛骂和粗口,最后还用最解恨的方式使他得病,而且得的还是那么一个带有难言之隐的怪病,而且患病的部位还是那么一个特殊的地方——实在是大快人心。而且这个恶魔最后出场时,还被汤普金斯给结结实实地侮辱了一顿——想必全世界受尽病态高压政治摧残的人们,读到这里时都会痛痛快快地叫好,大大地出了一口恶气!可能复仇是每个人潜意识里都藏有的吧,就象有一回,我也一记左勾拳把老板的下巴打得脱了臼,又一个右直拳把他打翻在地,然后踏上一只脚,正当准备让他永世不得翻身时——却惊觉自己已把床上的被子给踢飞了——想必对施虐狂老板出恶气这样的事也只能是南柯一梦!

 

不过Tom DeMarco对病态统治的治疗,也是黔驴技穷,拿不出什么切实的高招巧计和灵丹妙药。他先是出了个欺骗隐瞒的招数,让汤普金斯造假报告做假汇报来糊弄贝洛克。可现实生活中,“贝洛克”往往并不是呆在很远的地方来遥控,而是就坐在和我们同一间的办公室里;而且现实中也不会有那么多的善良的好同事,都那么热心也真心地帮我们去糊弄老板;而且老板也不傻,不是等闲之辈,岂是我等轻易糊弄得了的?所以我们是糊弄不了“贝洛克”的,这一招是绝对不灵的。记得一个当过程序员后又创业做了老板的朋友,曾对我讲过这样的话:“对待员工千万不能太仁慈了!太仁慈了就会被他们当作软弱,当作好糊弄。你能成天看着这帮臭小子们闲着没事干或不干正事而不着急吗?!我雇他们就是让他们来做事的,不是来玩的。所以一定要常拿棒子敲打他们,逼着他们干活……”Tom DeMarco到最后实在没招了,只好在作品里用恐怖主义的手段让贝洛克这个恶魔染上了恶病,想必谁都知道这招就更不现实了,也治不了本。还有Tom DeMarco为了表示对贝洛克的蔑视,竟然让真正的大老板元首把这家伙的名字都给忘掉了,并且竟还要征询汤普金斯的意见来开除掉贝洛克,这简直就太不可信了。现实中贝洛克式人物必然都是大老板的心腹,一般都对大老板忠诚度极高,大老板也对他信任度极高,所以才放心让他来监管下级经理和员工们的情况。你想啊,元首这个大老板一走就是几个月,然后不闻不问地把项目撇下就全权交由二老板贝洛克来掌舵,如果对其没有足够的信任度能这样子做么?而且贝洛克作为看管监督汤普金斯这个“外来工”干活的上层人物来说是全心全意克尽职守的。对元首来讲,对贝洛克的信任度绝对要比对汤普金斯的信任度要高。所以真正的现实生活中,恐怕是元首要征求贝洛克意见,看是否要开除汤普金斯,而不是反过来行事。汤普金斯最终也只能为此发了一通愁发了一顿呆,最后慨叹到“不要浪费时间,……,别想根治……”,最后只能寄希望于所谓的奇迹,而“奇迹是有可能发生的(但是千万别去指望它)。”——也许我们真的就无法根除病态的政治,因为它并不仅仅只是某个恶人或某种恶行的问题,而可能更是因由普遍存于我们每个人之中的人性的丑恶所致。

 

当然啦,向来都是老板自有老板的韬略,员工自有员工的兵法;两者的想法,天然上就会因看问题的立场和视角不同而有所差距的。上级和下属,也不见得都非得针尖对麦芒,但这需要双方的诚意同谋和良性互动。有很多远非恶人型的老板或管理者,也害怕自己会雇佣了一个恶劣的员工的,而期望自己的员工都是些忠诚敬业并能干肯做的人。(最能代表管理阶层这种想法的主张就是《捎信给加西亚》了。参见:http://www.csdn.net/develop/read_article.asp?id=17785

 

Tom DeMarco显然对过程改进存有相当深的成见。他对过程改进中的教条化形式化的东西很反感,反对纯粹为了CMM升级而升级,认为进行过程改进是投资大于收益的赔本买卖,告戒别指望过程改进能短期内就有明显好效果,并且在项目进行当中进行这件事只会耽误时间拖后进度而无助于提高生产率。当然Tom DeMarco的很多见解都是有道理的,不过我觉得他对过程改进的批评有点过了头;正因为他抱有敌意,才在书中对此进行了丑化。

 

Tom DeMarco是经过了精心构思来写这本书的,它的每个章节基本上都不长不短,就象期刊上的连载故事一样适合阅读,而且几乎每一章都要出场一位新人物,出场的人物大都是专家、学者、顾问、经理等高级知识分子或白领,也有元首、恶魔这样一正一反的老板以及面善手毒的间谍等,由于注重细节刻画,人物出场的方式绝不雷同,并且也赋予了各个人物栩栩如生并且性情迥异的形象。比如里面写到有个年近50岁的人,不愿住在楼里,却宁愿每晚都睡在公园的草地上,看着天空中一颗颗划落的流星入眠,我们就会真切感受到这一定是个浪漫可爱的人。还有对巴顿式青年的描写会让我们每个人都觉得十分可笑又有趣。年轻狂傲的卡布福斯、害怕惩罚而吓得要命的莫波卡、思维极快赛过机关枪的卡波诺斯等,都给人留下了深刻印象。当然给人印象最深的还是贝洛克这个恶魔老板,尤其是第22章写他最后一次跟汤普金斯通电话的对话描写,活脱脱把个恶魔形象暴露无遗。另外,我认为书中描写最生动的场景,当数在第18章中汤普金斯自以为是地充当调节人来解决两位经理之间的矛盾冲突却以失败告终的描写,简直就跟真事一模一样。Tom DeMarco60多岁了,思维却极活跃,作品中充满了奇思妙想和出人意料的地方。比如他先向我们述说有这么一位主持过很多大型项目管理却神话般地几乎从来没有失败过的“世界上最伟大的项目经理”,这样我们就会先入为主,想象成他一定是个很威猛的形象,而看到后面却绝对让人跌破眼镜,都会跟着汤普金斯先生一样大吃一惊的。而在求解和说明为什么压力对提高程序员效率没有太大作用时,他甚至故弄玄虚动用了电子巫术,让神秘的先贤来告知我们答案。

 

我觉得这本书毕竟是翻译作品,对其中用到的一些不常见的缩略语,象ReSOE(Released to Seek Opportunities Elsewhere)NNL(Nation's Noble Leader)IPO(Initial Public Offering)等,最好还是把它们所表示的原文都完整附注出来并加以简单解释好一些,以利于读者更好地理解并能在更广范围进行探讨和交流。这一点我认为是很必要的。当然这部书绝对不必象萧乾翻的《尤利西斯》似的,在每章后都搞一大长串爬虫注,但象ReSOE这样的缩略词,还是不光翻出来同时也给出原文好一些。

 

书中对汤普金斯的家址描述前后不一,写得有点混乱。汤普金斯的国籍是美国,但其家址似乎是西泽西卡(新泽西?)、纽约、波士顿都对,有点象个包二奶的家伙,好几处都有家。

 

还有由此书而普遍流传的什么“项目管理101”,其实应该是“项目管理111”,因为书中总共有111条管理原则,而且三个1很整齐,作者的本意如此,但写到后面不知是忙还是怎么的,竟然自己都数错数了,搞得谬种流传。

 

另外,第250页的最顶端的插图跟文中的说明也不一致。文中描述:

 

“那么,我们会选择右边的这个。”

“对。我们会选择它,因为各部分之间的接口会更少。……”

 

而实际上图示的两幅图中,左边的那个接口更少。不知是原书就错了,还是译介过程中给排错了。

 

值得一提的是书中的插图起了很好的辅读效果,我觉得画得很不错,这些带着漫画式的夸张并颇具动感的素描插图,很好地补充了阅读时的想象力。当然插图中的人物给人的感觉好象根本不是老外,而是我们国人,比如马可夫准将的形象,我就怎么看怎么象我们中国的党委书记的典型形象;不过这样反倒觉得更亲切些吧,认同感也更多些,感觉还是很不错的。

 

就如同现今中国出版的大多数图书一样,《最后期限》也继续发扬光大了中国图书富产错字、别字及印刷错误的光荣传统。仅举几例如下:

 

·第125

“你们要知道,螳臂当车是没有用的。”她柔声对他们说。(这里“螳臂挡车”成了“螳臂当车”,“当”字应该是现代通假字吧?)

 

·第208

“这个问题比较困难。让我们先从比较简单的部分开始把,……”(这里句末语助词“吧”改成了“把”,就好象在QQ上聊天打错了字,没什么大关系吧?)

 

·第305

他让自75己平静一下,然后说道:“元首助理和夫人。”(这里用数字75把“自”和“己”分开,很有创意,不过也很令人费解。)

 

另外此书的装订质量也同样令人遗憾和不敢恭维,刚买回来头一天,不经意间轻轻扯动了一下封底,竟然一下把整个书皮给扯开脱掉了,我只好再找来胶水重新粘紧贴牢。

 

可能大家最关心的是——这本书在实际工作中到底有没有用?谁应该读这本书?它对哪些人最适用?

 

做为实用主义者,最关心“学用”的问题,对此让我们先借用一下林彪为《毛主席语录》做序时写的三十字方针来说明一下吧:

 

要带着问题学,活学活用,学用结合,急用先学,立竿见影,在“用”字上狠下功夫。

 

尽管Tom DeMarco自称,若他写得还足够好的话,看了他的这部书,应该相当于提升了两年的管理功力。(原话如下:If the novel works as I hope it will, reading it should almost be the equivalent of adding two great years to your management experience. 参见:http://www.csdn.net/develop/read_article.asp?id=17790)但我对此不敢苟同。我想如果你初为项目经理(有点象初为人夫或初为人父似的),那么想“急用先学”或许能给你提供点思路和方向,但也不见得能有什么大成效,跟落水的人抓着根稻草差不多吧。至于想达到“立竿见影”的收效就更没门了。而三十字方针中的其他方针,都是我们在读这本书时应该贯彻执行的。

 

全书共24个章节(包括“间奏”),但我觉得作者并不是平均用力的,或者说各章的深浅程度不一。如果你原本一点项目管理知识都不了解,可能每一章都对你极有启发和帮助。但就我而言,觉得最值得细味的,当属第8章有关风险管理的内容、第12章有关度量的问题以及第1718章有关冲突的解决和调解的论述。其他比较好的章节还有第15章对压力效果的探讨、第16章有关规格文档和管理者情绪控制的论述、第20章有关会务管理的问题;当然第7章有关选聘人员的问题,也有写得不错的地方。

 

我最推崇书中有关处理人员冲突的提法,认为它完全正确并有实用价值。当然对于书中的催化剂角色,不要就此理解成每个公司都要专门聘用牛皮匠或故事大王似人物,但培养每个员工有能说会道的沟通能力,尤其是项目经理本身就应象朱镕基总理似的有演讲和鼓动的才能;并就此造就一个大家都敢讲敢放、舌灿莲花不止、头脑风暴不休的公司或团队小社会;使得这个小社会始终处于自然和谐、宽松融洽、自由自在的环境中,则项目成功在握矣。

 

书中提倡营造轻松减压的开发环境,反对无边无际地加班和对员工不断施压的做法。因为“压力之下的人无法更快地思考”,并且“增加加班时间只会降低生产力”,“长期加压肯定是错误的”,而且滥用施压本身就表明了管理者的无能。书中明确提倡开发者应该懂得享受生活,而不要老是被昏天暗地的繁重工作给搞晕了头。比如书中的这些描写:第11章开头那春日清晨的一派动人的景物描述,我想每个程序员看了后都会被深深感动的;书中间奏的一整章里汤普金斯不但给他的团队放了假也给自己放了假,并在休假的途中得到了意外的思想收获;第21章提到贝琳达,“她现在有越来越多的时间回到海港公园去,坐在棕榈树下读书。”——这太动人也太诱人了;第22章结尾处写汤普金斯在对付恶人贝洛克并有力反击他时,还念念不忘“如果现在就出发,他还可以顺道去看看刚开的玫瑰花。”,真是太会享受生活了。

 

还有书中关于度量的问题写得真好,我们有时也该象贝琳达一样自责,太缺乏“考古”方面的东西了,有时做了很多项目,程序员自己也说不清自己到底一个星期写的代码能有多少行或多少功能点,经理和主管也拿不准团队的生产能力,大家都冒蒙着干。

 

    当然《最后期限》不可能在其篇幅内将问题剥离得过细,所以很多地方都是些总纲式的提要。比如,第8章提到风险管理要先有风险列表,至于风险列表如何规划和按其施行就是你得花功夫去做的了,书中绝对没讲具体怎么做。有经验的项目经理都知道最起码有这几样风险几乎每个项目都会碰到,就是熟练员工的跳槽、对项目规模估算不够、对人员生产力度量不准确、对需求的变化和膨胀应对乏术、对功能规格把握不准意见不一、测试和质量保证不够或干脆忽略、使用团队成员都不熟悉的新技术的风险等。再如第12章有关度量的问题,只是起劲地讲到了功能点或用你自己发明的团队都能接受的自创方法来度量团队的生产力,但具体怎么使用功能点度量或怎样用自创的方法来度量,还得你自己去摸索和实践。据我所知,有很多国内的小规模公司或团队,干脆就没什么度量的概念,也没有科学的“考古”方法,每次对项目的估算是大概觉得行就上马,团队和程序员对自身到底生产力达到什么样的程度也没个准确的衡量,只是冒蒙着去干,大概乐观着去做,甚至象大跃进似的“人有多大胆,就写多少码”。甚至都搞过好几个类似项目了,项目经理还对自己团队的生产能力没个准,程序员也对自己的产能没个准,拍胸脯的事时有发生。我就曾听一个“牛”级程序员很不屑地讲过“一天100行程序算个啥呀!我一天就能写1000行!”后来我发现他真的一天能写1000行代码,但你要让他写的这1000行代码都没什么大bug地正常运行起来,却要至少花上一周时间的调试,那你说他一天到底能写多少行呢?还有第16章对功能规格说明书,只是说了它最起码应有的要素,最起码应该是什么样子,具体的功能规格怎么写,还得你自己费心使力去做。第1718章有关冲突的解决和调解也只是指出了个方向,如果你没什么更多的人生历练和对人性的深察透识的话,照猫画虎也不会有啥大起色。我就曾看到过一个小伙子,技术是真棒,老板就因为他技术好就把他提升为项目经理了,但他其实不会讲话也没幽默感,极不善于与人打交道,是个完全内秀型的家伙。我看过他试图解决两位牛级程序员的冲突,就比汤普金斯的那场尴尬的调解还要糟,结果不但没调解好,还搞得两个人都打起来了。所以说要想单单通过阅读就达到立杆见影的效果,真的是没门。当然我不是说看这本书就没好处,我想对于每个项目组的人,无论你是项目经理也好还是程序员,总之都要会处理项目中的各种问题,尤其是人的问题。如何进行自我管理和处理好人际关系始终是相当重要的。从这点看,我们任何人读《最后期限》都绝对是开卷有益的,即使你以完全娱乐放松的心情去读也绝对会有收获不会失望的。

 

    另外建议对此书一定要以“批判性”的眼光来阅读,比如书中写开发的6个产品都是以PhotoShop等知名软件品牌为竞争对象,但开发的新品在各方面性能是否能超过对手,是否在设计时就考虑了要有超出老产品的新功能和新卖点,这些关键问题中都没怎么提,好象只要设计出跟PhotoShop一模一样的产品就算赢了。很可气的是在第13章里讲为了不浪费时间,就得出了这么个真理——“用户手册就是需求规格文档”。我也同意特殊情况下为了抢时间赶进度,着急时可以就用自己老产品或竞争对手产品的用户手册为依据来编写需求规格,但也不能就那么原封不动地,一点也不重新设计和改动,就拿过来全盘照抄照用啊!法律上也不允许这样吧?所以大家要是都把“用户手册就是功能规格”当成普遍真理的话,可真是惨透了!更可气的是在第3章——

 

“我们会免费发放我们的产品。”

“什么?那我们怎么赚钱呢?”

元首脸上浮现出神秘而得意的表情:“你只管把产品造出来,我会拿它赚到钱,成吨的钱,这就是我的承诺。”

 

可见这些项目纯粹是为了玩资本游戏,所以才在产品的设计功能上从不考虑要有超越部分的新功能,只要仿造达到了原有产品的原有功能就行了。该书写作于1997年,那正是“眼球经济”(或注意力经济)甚嚣尘上狂热至极之时,有大量疯狂的风险投资和资金来源供大家圈钱和烧钱,那时开发软件产品也被当作吸引眼球并进一步圈钱的手段。但时隔这些年,早已证明了眼球经济并不完全靠得住,IT行业也要象传统行业一样踏踏实实靠赢利而不是哗众取宠来赚钱,吸引眼球只是赚钱的手段之一,现时光靠它已经赚不到“成吨的钱”了。

 

Tom DeMarco最危险的建议是在第21章,提出为了赶进度满足最后期限,取消所有的代码检查。理由是绝大多数Bug都出现在接口部分,而设计已经完美到不会导致内部代码错误的程度,所以设计检查完后就不需要代码检查了。——吹牛,我还从没见过有这么完美的设计,完美到竟不需要代码检查的地步!而且即使绝大多数Bug出现在接口部分,难道就敢保证模块内部不出Bug了吗?为了增强说服力,作者还特意夹了“间奏”这一章节,当然里面的比方很贴切,相信许多人在生活中也碰到过类似的经验,而且得出的关于“人类的错误”的结论也是正确的;但却错用在了“取消代码检查”这件事上,不但牵强附会,而且遗留祸患啊。

 

对于书中“愤怒 = 恐惧”这一论断,我承认此公式在很多情况下是成立的(尤其对那些恶劣的无能的管理者而言,很正确)。但也绝非全都如此,很多时候发怒就绝不等同于害怕的。实际项目中,要是经理总是个一点脾气都没的老好人,也真不容易啊;尤其是遇到糟心的员工——就是那些叹其不自尊、怒其不上进的员工(很多是选聘时不仔细、没选好造成的),你对他没一点脾气也不行的;只是作为管理者任何时候都要控制自己的情绪,即使是发脾气也不要伤了人的尊严。

 

另外,现实中的项目约束条件一般远较书中所描写的要苛刻,实际项目遇到的复杂问题也绝非一本书所能完全涵盖的。书中所有场景都是想象假定的,就是为了说明问题作铺垫,大家千万别当真。象汤普金斯那样的好运,即每遇困境就会有贵人相助,而且这些贵人又都是世界级顶尖高手,都那么乐于甘将自己多年练就的真传金丹无偿奉献出来。类似这样的事例在现实生活中根本就不会出现,这就象真实的泰坦尼克号上根本不可能发生过好莱坞大片中所渲染的浪漫场景一样。

 

看过整部书,再一细想,汤普金斯的成功简直太轻易了,虽然他历经了一些困扰和磨难(最主要是来自病态政治方面的阻碍),但在那么多贵人相助下,很顺利地就完工了。所以我讲他“历尽英雄劫”,这个“劫”不是劫难而是劫持,在他的项目中不但劫持了众多高手,还把他们的宝贵思想给劫持了过来。书的最后他所爱的人又给他找下一个新活,他又重新被劫持了,真可说是——

 

如果你恨他,就让他去管理项目,因为那会使他受尽非人折磨;

如果你爱他,就让他来管理项目,因为那会使他享有幸福王国。

 

那么谁应该读这本书呢?我觉得所有搞项目开发的人都该好好读一下这本书,也该都能从中受到启发和教益。

 

就象人们常讲的,不想当元帅的兵不是好兵,想当元帅的好兵不一定都能当得上元帅。我刚看过这样一篇文章,讲一个打工仔给老板发了一封只有一句话的公函,说:“老板,我已替公司管理了我自己。”文中提倡自我管理的观念,就是说“一个人的品质和一个公司的品质一样,是用他的管理和声誉一同建立起来的。”(原载于《深圳青年》杂志20033月份上半月刊“打工深圳赚未来”一文。可参见:http://www.csdn.net/develop/read_article.asp?id=17784实际上在公司内部没有绝对的管理者和被管理者,每个人都应该了解管理的原理,并先从自身做起搞好自我管理,从而力争项目成功。中国的程序员在学校里都没怎么学习和实践过怎样应付压力、怎样与人打交道以及团队合作等有关人的软科学,这方面的经验都是在工作后才逐渐摸索和总结的;而这本书就可为程序员们学习如何进行自我管理和处理人际关系打开一扇大门。

 

书中附有大量图表,体现了在科学研究过程中通过函数化、数量化来进行问题求解的风格。大家都知道,项目管理中有很多东西,都难以准确地量化、估算和度量,象员工的压力、客户的满意程度、项目工时量的预算等,但《最后期限》都提供了很明确可行的研究案例来示范,其中第12章关于功能点的探讨以及第15章关于员工压力的探讨都很有代表性也很精彩。

 

尽管Tom DeMarco本人不承认,怕有人对号入座,给自己造成麻烦。但几乎公认他的这本书中的人物都是有现实原型的,兹举几个普遍流传的如下:

 

·元首The Nation's Noble Leader 或 他Himself -> 原型是微软公司的Bill Gates

 

·贝洛克Belok -> 原型是苹果公司的Steve Jobs

(呵呵,别搞错了,可不是我们中国IT界风流,比如托普的宋如华、西风的梅俊林、北京利玛的张爱清等各色人物啊,要是DeMarco知道了中国有比Steve Jobs还厉害的家伙,一定会以他们来塑型啊)

 

·思维讲话都赛过机关枪的精晓功能点的数字人约翰·卡波诺斯T. Johns Caporous -> Capers Jones

 

·解决冲突的专家拉里·波希米Larry Boheme -> Barry Boehm

 

·解决会务问题和人的问题的项目社会学专家哈里·温尼佩格Harry Winnipeg -> Gerald Weinberg

 

·妖怪The Genie 或者 伟大的约迪尼Great Yordini -> Ed Yourdon

 

Tom DeMarco是个耳顺之年的老程序员了,但他的书中还是有很多新意的,即使你是个搞项目管理多年的老手,也还会有很新鲜的感觉,并可从中找到新的发现、汲取新的营养,其中的观点你不必都赞同,但提出的问题绝对都会引你深思,引导你开启解决问题的智慧之门。所以我认为这本书的最大价值就在于它的启发性。

 

本书的另一个价值就是它能提神,能使你象抽了大烟一样兴奋起来,书中洋溢的乐观主义和英雄主义会极大鼓舞我们的斗志,而其中弥漫的理想主义和自由主义气息也将极大地感染我们。如同我老人家的语录中所言:“我们都是寻常之人,渴望创造惊天奇迹。”就象很多优秀的推销员,每天早上都要照照镜子,调整好最佳微笑,然后再对着镜子挥动拳头大喊一声:“我行!我能行!我一定要成功!”然后才出门工作,据说这种精神激励能使得推销员一天多卖掉不少产品。我想这部书应该也是象这样的一面镜子吧。

 

好吃不过饺子,《最后期限》就是这样一盘热腾腾的美味水饺。我是美滋滋地品尝过了这个美味的故事,现在我也诚挚地向你推荐——请来享用这个美味的故事吧。

 

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

呵呵,也象汤普金斯一样,我也再次重温了一遍电影《Patton》和它的续集《The last days of Patton》。模仿它里面的话,做个广告——

 

世上不会有永开不败的花朵,情人节的鲜花终究还会烂掉。

听听白发老头的热情传道没啥坏处,上帝造我们时也有最后期限。

 

trybird

 

2003.02.14

St. Valentine's Day

0 0

我的热门文章

相关博文

img
取 消
img即使是一小步
也想与你分享
打开
img