项目百态：深入理解软件项目行为模式(txt+pdf+epub+mobi电子书下载)

作者：(美)Tom DeMarco等

出版社：人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

项目百态：深入理解软件项目行为模式试读：

对本书的赞誉

译者序

什么是项目？按照PMBOK的解释，项目是为提供某项独特产品、服务或者成果所做的临时性努力。现代项目管理通常被认为始于20世纪40年代，但项目管理自古已经开展于一些主要基础设施如埃及金字塔、运河、大桥、教堂、道路、城堡等的建设之中。从古老的“巴别塔”到20世纪40年代的美国曼哈顿计划，再到如今全球性的项目运作，项目管理的思想和实践已经走过了洪荒时代，进入到成熟、科学的阶段，在各个领域中大放异彩。

然而，相较于其他领域而言，软件还是一门非常年轻的领域。也正因为此，软件自从诞生伊始，尤其是在20世纪60年代软件危机爆发之后，其从业人员就一直在尝试着借鉴其他领域的思想，引入各种隐喻来描述软件领域的行为和事物，加深人们对于软件开发的理解，提高人们对于软件开发项目的洞察力。《代码大全（第2版）》指出：“David Gries说编写软件是一门科学（a science）（1981年），而Donald Knuth说它是艺术（an art）（1998），Watts Humphrey则说它是一个过程（a process）（1989），P．J．Plauger和Kent Beck都说它就像是驾驶汽车（driving a car）——可他们两个却几乎得出了完全相反的结论（Plauger 1993，Beck 2000）。Alistair Cockburn说它是一场游戏（a game）（2002）……而Fred Brooks说它像耕田、像捕猎，或像是跟恐龙一起淹死在‘焦油坑’里面（1995）……”

如果拭去隐喻带来的神秘性质，翻开思想和方法的装饰，直面软件领域与其他领域的根本差异，我们可以发现软件的核心特征在于其抽象性。软件开发由需求（问题域）到可执行的源代码（解决域），正是试图以一种抽象的形式捕捉或者展示另一种抽象。软件的抽象性导致了其他领域所不具备的两个重要特征。

●项目的不可见性。软件开发主要是一项抽象性活动。基于此，计划的执行情况、变更的影响范围、风险的大小等因素对于软件项目都是在一定程度不可见的。如果缺乏对这些因素的把握，项目必然是不可控的，必将走向失败。

●概念建模的复杂性。软件的本质复杂性源于概念模型的抽象和构建。而这一活动又属于智力的创造性活动，极大地取决于程序员对概念的掌握、理解以及再具象化。这些行动是无法通过灌输、强制等措施来做到的。

这两个特征使得软件开发蒙上了一层诗意的瑰丽色彩。《人月神话》在首篇“焦油坑”中对程序开发有非常形象的描写：“程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的‘城堡’。”软件以及软件开发与其他领域的差异正导致了软件项目异于其他领域项目的一个很重要的特点：对人的依赖性。人是摆在第一位的，正如Alistair Cockburn在《敏捷软件开发》之中把软件开发形容为“关于创新和沟通的正和博弈”，能否玩好这个博弈游戏，取决于游戏中每位个体以及他们之间的沟通与协作。如何施以管理，让人发挥最大的创造力，让团队保持持续稳定的开发速度，让项目最终走上成功？

也正因为此，二十年前的《人件》试图从社会学的角度来重新诠释软件的开发和管理，“我们工作的主要问题，与其说是技术性的，不如说更多的是社会性的”，围绕着“高效的项目和团队”探讨了资源管理、环境、团队建设等方面的种种实践。其中，作者指出了“管理工作需要系统思考、启发式判断和建立在经验基础上的直觉”。技术也许可以通过技能训练弥补，但经验的缺失却只能是通过经验的积累和传递。可惜的是，当下的软件管理书籍更多的是来自于学院派的理论和指导，缺少具体经验的传承。比如，项目的不可见性会有哪些形态？如何解决项目的不可见性？如何简化概念建模的复杂性？这些经验对于软件从业人士是亟需且多多益善的。

二十年后，《人件》的两位作者再次携手，延续《人件》的风趣和尖锐，推出了这部《项目百态》。《项目百态》包含了86种项目行为的模式，每一种模式都是实际经验的提炼，在风格上与《人件》一脉相承。每一种模式都命以一个通俗直观的名字，配以一张关联的图片和一段点题的说明。大部分的模式都是通过一则有趣的故事来引出问题，再以作者们的真知灼见一针见血地分析问题的根源与特征，最后以作者意味深长的总结收尾。

对于任何一项模式，作者平白表述的背后都是一个个倒下项目的身影。比如“明日复明日”（模式7），有多少项目因为目标设置过于遥远，导致项目计划对人们不再有紧迫感。又比如“残局游戏”（模式47），有多少项目沉醉于项目就绪度舞会之中，却浑然不觉截止日期渐进，而交付物的质量尚不曾经过检验。又比如“牵涉性疼痛”（模式6），“头痛医头，脚痛医脚”的庸医做法把多少项目扼杀在尚未可期的状态。又比如“主面板”（模式16），相信有很多项目已经使用主面板来直观了解项目状态，但对于如何设计良好的主面板却所知甚少，作者分享了一些经验。又比如“稻草人”（模式26），建模是困难的，从无到有的建模更是难上加难，何妨试试“稻草人”，阅后即焚？掩卷沉思，既悚然于种种模式的似曾相识，又庆幸于有些错误仍未出现于项目上，还有时间处理出现的问题。此时，不禁长叹一声：软件项目还可以这么玩！

本书不仅适合于项目团队的各种角色，也适合于软件组织参与到组织间“博弈游戏”的各种角色。事实上，围绕着软件项目的各种角色都能从本书中受益。从项目监控的角度上，分析自身项目的态征，如是否存在“错误的质量关卡”（模式34）、“造纸厂”（模式79）等；从团队建设的角度上，团队之中是否存在“英式保姆”，“本”（模式54），或者“记者”（模式49）和“影评人”（模式19），或者勇于跨出“蓝色区域”（模式44）的人；从项目交付上，团队是否交付了“没人在意的交付物”（模式61）；从项目生态管理上，“空椅子”（模式50）、“堆积”（模式77）是否存在于项目之中，各种角色是否“互相教学”（模式65）。

当然，相对于《人件》，这本书可能在结构上存在着白璧微瑕。它没有像《人件》一样把相似的模式归并在一起，而是选择了以相对零乱的顺序来阐述。事实上，本书中的很多模式，比如“错误的质量关卡”、“造纸厂”等都可以归为一类。但这或许也是作者的匠心，并不试图勾勒软件项目的全貌或者结构，而是试图从不同的视角来观察、投影软件项目，然后从每一个视角窥一斑而识全豹。回忆对未知事物的认知模式，分解和投影往往能给人相对直接和较深入的体验。这些体验汇合在一起，给我们一个对软件项目的全面而直观的认识，又岂不快哉？

本书的翻译得到了很多人的帮助，我无法逐一列出。首先，要感谢刘江，正是他的推荐，才让我没有与这本书擦肩而过。其次，要感谢图灵的各位编辑们：他们的耐心，让我可以慢慢地斟酌自己的翻译；他们的细心，帮我发现了不少错误；他们的专业，让本书的排版和标注不再凌乱。

感谢我的父亲金建华和母亲胡赛花，我对文字的热爱很大一部分是来自于父亲深夜挑灯读书的背影，而母亲一直尊重我对软件工作的选择，即使那意味着她的儿子离开自己、置身于千里之外。虽然他们都已经不在了，但是当我孤单的时候，他们的目光一直是我前进的动力。我要感谢我的弟弟金成，他承担了照顾父亲和母亲的大部分责任，让做兄长的我可以将更多的精力放在工作上面。我还要感谢我的女朋友，虽然我们身处两地，但她始终给予了我足够的信任和支持，让我可以做我感兴趣的事情。

最后，由于本书是由六位风格迥异的作者写就，各成风格却又风趣一致。将原意表达出来又不失趣味是我的目标。虽然我已经下了不少功夫，但终究经验和能力有限，译稿之中难免有疏漏之处，欢迎读者批评指正。

实话的力量

我对我的客户、一支百人团队的领导说：“你们并不是没有优先级。你们的优先级策略是最后来的事情优先。”

他苦笑不语。因为他知道，这就等于在说，他手下的百十来号人基本是在做布朗运动；更因为他知道，这是实话。只是他自己不能说，他的手下人也不能说。

事情经常是这样：尽管所有人都知道，但谁也不会把它说出口，因为说那样的话是政治不正确的。比如说吧，也许你早就知道你手上那个项目注定是条死鱼，但你敢说出口吗？更多时候，你会让自己变得乐观──乐观程度与最后期限的紧迫程度成正比，直到时间夺走你所有的手牌。

另一些时候，你知道自己碰巧做对了某些事，你不愿意新来的经理改变它：取消每周四晚上的三国杀，把团队从大会议室里搬回格子间以便“释放资源”，把几个模块外包到一千公里外的另一个城市。可你没办法说服领导。“你有度量证据吗？”当然，你没有，而削减成本总是政治正确的。

情况不会自己变好的，如果人们连真实情况都不敢说出来的话。

幸运的是，像Tom DeMarco这样名声和年纪（这很重要）都足够大的人可以不在乎政治正确性──换句话说，他们可以说实话。这本《项目百态》就是他们关于项目管理的实话集。

在这本实话集里，作者们挑选了86个项目管理中常见的模式，从“肾上腺素成瘾”直到“模板僵尸”──从英文书名不难看出，这无非是“从A到Z”的又一个变体。这些模式，诚如一位评论者所说，有良性的，更多的不仅恶性，而且丑陋可笑。读这样一本书，你会笑，更多的时候你会摇头苦笑，甚至如芒在背。“我的团队没有肾上腺素成瘾吗？”很多读者将很难面对这个问题。

那就对了。

我要感谢我的同事金明向我推荐这本书：几位作者帮我们消解了政治正确性的风险，我们就可以放心地说出实话，然后努力进步。下次当同样的模式出现时，我就可以大声地说：“这就是《项目百态》中的××模式。”或者当我再次面对前面提到的那位客户时，我可以把书递给他，对他说：“也许你该看看××模式。”

也许你也应该看看。熊节ThoughtWorks中国公司首席咨询师《重构》译者

引言

抽象为人类独有。我们现在每天、每个清醒的时间都会进行抽象，但曾经却并非如此。在史前时代的某个时刻，抽象可能是这样萌芽的：一个早期智人凝视着一样依稀很熟悉的东西，他的脑海中闪过一个想法：“嗨！又是那个东西！”这就是最原始的抽象。从那时起，一切都不同了。人类在地球上不再受自然羁绊。

抽象完全是人类的行为。模式识别则不然，它并不为人类所独有。老鼠很清楚猫儿何时进入梦乡，人们何时不在厨房，面包屑又是何时掉落尚未被清扫。兴许你只是突发奇想，打算离家待一个周末，你的家犬也能提前察觉你的意图。（是不是因为你的手提箱？）而你的邻居浣熊也知道当潮水退去，遗留在海滩上的东西必然比你肥料堆里的东西要好得多。然而，虽然熟稔于模式识别，老鼠、狗、浣熊却不会观察，联想不到“嗨！又是那个东西”。这其中就需要抽象了。

模式识别和抽象的区别在于它们捕获本质的方式。模式随着时间被吸取和提炼，保留在脑海的深处，很难用语言来表述，而多半是以直觉的方式传达给你的。直觉，比如觉得持球队员将向左边冲击或者配偶的怒火即将爆发，都是源自过去识别出的模式。至于这周项目状况的会议上将引发争论的直觉，也不例外。不能明确表述的模式并非毫无价值——毕竟存在即合理，但如果你仔细考量，并且基于它可表述的观察结果进行探究，模式的价值就能显著地提升。

举例来说，问自己这个问题：过去的一年中，引发争论的会议之间存在哪些共同之处？呃，这些会议大部分都是这样的：老板的老板也参与了会议，而且通常是季度末期的会议。最糟糕的会议则当属——团队在会上汇报了计划表的失误。据此，你能形成一个模式：“我的老板对会上汇报的失误简直会发狂，特别是在接近季度末期的会议上面，因为他的老板那时也会出席。”

尽管已识别的信号可以推导出这个观察结果，但是它们仍然隐藏在无意识之中，偶尔才能让你产生直觉。然而，在右脑直觉和左脑表述能力交汇的一刹那，你抓住了本质，并且转化成清晰的语言。你可以把它写下来，使用明确的测试校验其正确性，和其他人分享，与一同工作的人合并各自的观察结果。

大部分做项目管理工作的人都非常善于识别模式和培养直觉（“我感觉这个项目会走向灾难”），但却不那么善于把模式抽象成更加有用的格式。我们几位作者一起研讨，从加起来长达150年的相关从业经验中吸取出特定的模式，再精确地表述出来——于是有了这本书。

一本书的格式会影响到内容陈述的顺序，因为必然是一页接着一页才能成书。但模式本身并不具有天然顺序。我们按照自己的喜好排列这些模式，从第一页到最后一页，争取给读者带来最愉悦的阅读体验。

无论你是从头读到尾，还是随意翻阅，脑海中请始终记住这一点：我们并没有宣称自己观察到的模式具有普适性。显然，它们不可能是到处适用的。别人给出的模式也许适合你的组织，也许不适合。如果适合，我们希望能帮助你将曾经只是直觉的东西转化成观察结果，你和你的团队可以表述、验证和提炼它。

在本书的创作过程中，我们从建筑大师、哲学家Christopher Alexander和他令人惊叹的《模式语言》一书那里受益匪浅。在那本影响深远的著作中，Alexander与合著者明确指出了建筑的几百种模式。该书帮助我们更好地理解我们所涉及以及想涉及的部分，而且，该书也向我们展示了一点，即经过深思熟虑的清晰抽象足以阐明任何事物。

第一部分

组织相信忙乱的工作象征着高效的生产率。

电话响了。“我们想这周完成需求的规格说明书。你能过来看看可以做些什么吗？”“规格说明书怎么了？”“我们很急，所以新招了许多人来撰写规格说明书。我们觉得他们完全不清楚自己在做什么。”“如果由我们来指导他们编写需求，效率不是更高吗？”“但是我们这周就需要规格说明书。”“好吧，我明天过来。”

两个小时之后。“你能过来看看我们评估的工作量吗？”“规格说明书怎么办？”“我们没时间了。我们就照现有的需求规格说明书进行。老板要求今天就把评估的工作量交上去……”

你可能已经识别出这一类“玩的就是心跳”（adrenaline junkie）型组织的特点了：优先级总是变化不休，所有事项都是“昨天”就要，总是没有足够的时间交付项目，所有项目都是紧迫项目，紧迫的项目源源不断。每个人都忙得焦头烂额……永远如此。

这些组织里面的人不会从战略层次上思考问题，只是按照紧迫程度来完成工作。除非“忙乱指数”非常高，否则它通常都会被忽略——尽管它很有可能会带来显著的长期优势。人们会一直对其不闻不问，直到它突然（绝对出乎意料地）变得非常紧迫。“玩的就是心跳”分子相信最好的工作方式不是先谋而后动，而是竭力追赶时间。

这种组织文化认为紧迫性越高的项目，绩效也越高。如果身处这种文化之中，你很难不受感染：紧迫性是受到鼓励的。那些为了某个短得可笑的期限而加班到深夜的程序员被视为英雄（根本不在乎他们交付的程序质量）。每个周末，团队的所有成员都照常上班，以保持他们的工作量：这样做的团队比不这样做的团队更受人赞许。此外，如果你不是一直都过度加班，或者没有发疯一般忙碌，你就会被贴上“不是自己人”的标签，你不是保障组织运转流畅的大忙人之一。非英雄行为绝对不能被接受。

绝大部分的“玩的就是心跳”型组织至少存在一个瓶颈，就是那位英雄。他包揽了所有设计的决定，是全部需求的唯一来源，或者一个人决定框架的方方面面。他扮演了两个角色：一是让自己表现得比常人难以想象的还要忙；二是引发决策僵局，他的决策一旦公布，就会导致组织的其他部分更加忙乱。

大部分的“玩的就是心跳”型组织满腔热情地拥护客户服务的理念：他们错误地认为对紧迫事件的响应就是值得赞赏的响应。当客户提出了一个请求，不管是否存在潜在的利润（甚至有效性），该项请求都会立即转化成一个项目，而且通常截止日期会短得可笑。（更多讨论，请参阅第38项模式。）这个新项目自然会加重本已超负荷工作的英雄们的负担，使他们更加手忙脚乱——所有的这一切无休止地让组织变得非常、非常忙碌。很多这一类的组织都（错误地）认为这就是敏捷的全部。“玩的就是心跳”型组织经常会断然行动，而不是三思而后行。这样导致的结果就是大部分工作都处在不断变化、无法固定的状态，没有什么可以固定下来，或者保持较长的时间。这种不固定的状态一直延续：需求规范不固定——没人真正清楚要构建什么；设计和计划也不固定——它们很可能明天就会改变。紧迫性是唯一的标准，没有人尝试按照重要性或者工作价值来对工作排定优先级。

对于“玩的就是心跳”型组织，回春妙手是不存在的。他们完全是没救了，除非消除那些令人心跳加速的事情，而且解雇经理，雇用那些明白“组织只有不再忙于处理突发事件才最有效率”的人。但是这样的人事变动根本不可能被采纳，因为高层领导，通常是CEO，希望看到组织长久地保持匆忙的状态，因为工作匆忙让人生出一种高生产率的幻觉。而且，如果公司的经理们是“玩的就是心跳”分子，项目团队也不会相去太远。“玩的就是心跳”型组织并不是总会失败，他们当中有一些在多年里一直保持着匆忙的节奏。但是，它们都不可能构建重大的东西——那需要稳定性和计划。亢奋型行为不可能扩展——由一些相对较少的人在没有方向，也没有战略指导的前提下，光凭借非常、非常忙碌的工作所能达到的效果十分有限。

当然了，任何组织内都会遇上紧迫的事情，也需要有一些角色去关心紧迫的任务。但是，不是所有的事情都是紧迫的，也不是所有的角色都要关心紧迫的任务。除非化紧迫性为优先级和约束，否则，这种“玩的就是心跳”的治愈希望是微乎其微了。模式2快，赶上

当项目团队决定谁在何时该做什么事情时，呈现出明显的紧迫感，并迫不及待地想立即采取所有必要的行动。

想象你是一只苍蝇正停在墙上，此时开发团队正在召开例会。随着会议的进行，你能看到下面的角色分工，听到下面的交谈。我们要解决的问题是什么？解决方案的要点是什么？每项要点由谁负责？首先需要完成的事情有什么？谁来完成它们？在什么时间之内完成？如果我们不清楚某一项个别的任务要花多长时间，谁来定义任务范围，以及何时才能完成？什么时候我们再聚一起，计划接下来的任务？好了，散会。

会议之后，通常在一个小时之内，所有成员会收到一封邮件，上面总结了团队达成的行动计划。事实上，往往在这封总结邮件发出之前，其中一项或多项行动事项就已经完成了。人们在会议结束之后就立刻投入到行动之中。

即使在墙上，以你苍蝇的眼睛也能看出来这是一支高效的团队。

我们知道对于一支高效的团队而言，人们在会上就开始处理商定的事项，这一点都不稀奇。通常，接受任务的人会认为相较于把任务写下来会后再做，现在就做反而更容易一些——比如“把所有尚未解决的优先级为2的缺陷分派给产品管理工程师进行分类”这个任务。如果只有询问过会议之外的某人之后才能做出决定，那么接受任务的人就会给那人发送即时消息，并且把结果汇报给与会人员，保证行动计划的制订工作可以继续进行。

这种“立刻行动”的例子非常特殊，而且应当承认它们是拜技术所赐。但是行动的内在基础来源于团队的文化，而不是所使用的技术。分派缺陷到底是花费10分钟抑或90分钟并不是重点，重点是团队立刻就着手开始。在团队日常“快，赶上”的活动中，你能观察到下面一些特点。

●他们对于时间的紧迫性有着内在的直觉。他们把延迟视为成功的真正风险，不需要用截止时间来督促。他们竭尽全力，一旦完成，就把产品推向市场（或者把系统做成产品）。他们明白时间就是金钱。

●他们对个人和集体的能力非常有信心。想象一下赤足走在一间黑暗且完全陌生的房间里面。当你不确定前面有什么东西，或者不知道下一步会撞上什么东西的时候，你会慢下来。信心不足就像一种摩擦阻力。以行动为导向的团队对自己决定和行动的正确性（或者可纠正性）非常有信心，所以他们一往无前，勇无所惧。

●他们相信迭代的价值。他们不会特别担心做错了事情——部分是因为他们很自信，但同时也因为他们完全准备好了随着工作的进行，经常做出评估，不断修正方向。摆脱掉“每次决定都必须毫无瑕疵”的包袱，但同时坚信大多数决定都是正确的，他们可以很痛快地做出决定，并付诸行动。

也许值得花一些功夫考虑一下相反的模式，“脱口秀”会议——它们有时十分有趣，但却缺乏行动。这种会议有如下几种形式。

●要求完美的信息。有些公司的文化把不犯错误看得比完成事情还重。换句话说，什么也不做都比做错了更安全。这种文化催生了这样一类领导和团队，他们企图搜寻到所有的信息，在第一次就做出绝对正确的决定。通常，团队会议的结果不是决定出做什么，而是决定出还需要收集哪些额外的信息以决定做什么。

●对“等一等”的膜拜。弱团队比强团队更倾向于推迟他们的决定和行动事项。“推迟”的理念与强软件团队的行动方针背道而驰。强团队渴望把事情全部做完。如果需要做出决定，或者决定完成一项任务，团队一定会去完成。如果决定被合理地推迟到未来的某个时间，团队会为其在开发活动中安排一个特定的点。弱团队则总是会寻找借口，等着晚一会儿再做决定或者采取行动。

●未定事项的大浆糊。会议组织不善，一个接一个的新想法冒出，从一个主题跳跃到另一个主题，一个接一个的议题被提出，但却没有一个能够得出结论。

●篝火旁边的轶闻。一些团队会议毫无组织，纯粹是一系列的轶事趣谈，以及对组织过去和现在的口头传说的回忆。

●条条大路通设计。当团队由架构师和开发人员主宰时，我们有时观察到，无论会议的目标和议程如何，每一次会议都最终演化成对设计的讨论。设计讨论也许很精彩，但如果妨碍了其他更有价值的议题，就不再如此了。

●开会安排额外的会议。所有失败的会议最终都走上这一步，概莫能外。模式3死鱼

自打开工起，项目就完全不可能完成目标，项目团队中的大多数人都很清楚这一点，但却都缄口不言。

很多IT项目的目标可以被扼要地概括为：我们要在截止日期之前，完成这一系列功能，达到这种准确度，并且保证足够的健壮性。项目团队于是组建起来，项目目标和约束条件转化成详细的需求和设计，并且公布于众。

一个天大的秘密是项目团队中没有一个人相信项目最终能成功。通常看来，如果其他目标不做修改，截止日期是无法达到的。不可思议的是，没有人指出失败的阴影正如一只散发恶臭的大死鱼一样把项目变得臭不可闻。

希腊式悲剧拉开帷幕，项目进行得步履维艰。然后一如既往地，在预期交付日期之前的几周，所有的项目成员、项目经理、项目经理的上司以及任何与项目沾点边的人，要么——

1．对于项目没有按照即将到来的发布日期进行，表示震惊、气馁、诧异；要么——

2．保持低调，除非被点名问到，否则在任何事情上都一言不发。

为什么如此多的组织里面有如此多的人给实际情况喷洒上除臭剂，而不是简单地指出“项目现在的方式不是我们所希望的方式，死鱼就在那儿”呢？

很多组织是如此汲汲于成功，以至于任何表达疑虑的人不会因为讲出由衷的意见得到任何奖赏。事实上，如果谁在项目的前期阶段就声称死鱼的存在，管理层的第一反应多半如下。“证明给我们看。给我们证明成功的可能性只是零。不要拿以前项目的死鱼经验来唬人。现在的项目不一样。用严密的数学证明来告诉我们失败无法避免。”

一旦你提出任何缺乏精确证据的东西，就会被指责为软蛋或者是试图逃避朴实的辛勤工作：“你是软蛋，还是懒汉？你自己选择吧。但是我们不相信你还能在这个良好的组织里面待很长时间。”

在这样的环境里面，“努力”而无法完成比站出来指出目标无法达到更安全。确实，有时需要勇于承担有挑战性的项目，在认输之前真正地拼搏一番。非常正确——但区别是，在有确定截止时间的艰难项目中，没人会捱到最后一刻才声明情况的危急。如果项目是给只有18个月就要上天的通信卫星构建软件（你知道如果错过了这次发射时间，下次机会就要再等16个月），那么，你们每个人每天都要闻一闻项目有没有出现什么异味。你非常清楚“死鱼”项目只有到后无退路的情况下才会采取行动，所以，一旦闻到异味，你就会立即采取行动。

非常清楚的是，“死鱼”不仅给组织带来破坏影响，而且打击了“死鱼”项目团队和他们经理的士气。无论组织文化如何，没有人会觉得长期作为发臭的“死鱼”项目成员会很舒服。严密捂盘“死鱼”消息的成本实在太高。

献给《蒙特·派森》（Monty Python）迷们：“项目还没死，它正在附住峡湾！”“项目没有死，只是在蜕皮！”“这项目已死。它已经驾鹤西去了。”“现在上场的是完全不同的模式……”模式4欢乐的鼓掌会议

是否表现出高涨的士气成为个人绩效的评价因素。

高涨的士气永远是组织健康运转的一个象征。与之类似，低糜的士气则说明肯定有什么地方做错了。有一种管理理念就是奉这种关系如圭臬，试图从相反的方向来利用这种关系。这种理念的逻辑是这样的：把士气鼓舞起来，其他美好的东西也就接踵而至。

啊哈，那如何鼓舞士气？尤其是如何在不增加时间、精力和花销——虽然它们是改善事物的必要投入——的情况下鼓舞士气？这是个难题，但别以为人们就不会去尝试。于是，才有了这样的谚语：“打气，打到士气提升为止。”

鼓舞士气的常见举措是仪式性的会议。会上老板笑容可掬，站在集合好的团队前面，大开言路。“让我听听你们的心底话，”他大度地告诉大家，“任何事情都行，坏的消息和尖锐的问题也可以。”注意这里的腔调和背后传达的信息：没有什么好隐瞒的，我们是一个欢乐的大家庭。（欢乐，该死的，欢乐。注意了。）

我知道有一家公司，这样欢乐的鼓掌仪式被称作全体会议。之所以称为全体会议，是因为所有人都获邀参加。但是一旦哪位勇敢的人果真举起手，向CEO提出尖锐的问题，最后的结果却根本不是他所预想的。CEO咕哝了几句，就迅速改变话题，不再讨论这个问题。在当天的晚些时候，这个冒失的提问者就被他的顶头上司叫去训了一顿，本来还指望这类尖锐问题会很受欢迎呢，结果这种幻想彻底破灭了。从此以后，在私底下大家都把这种会议都称为一言堂，因为没人会再次举手发言了。——TDM

一旦理解到老板并不是在征求你们的发言，而只是征求你们的同意时，你就能清楚地知道要上演什么好戏了：欢迎参加欢乐的鼓掌会议。模式5保姆型项目经理

项目经理拥有的技能与传统的英式保姆有很多共同之处。

一个优秀的项目经理要对手下员工的能力了如指掌。他分派任务、制订计划，在可用的技能和任务本身的要求之间寻求最佳的契合点。这是显而易见的。还有一些项目经理更进一步：他们提供一个工作环境——不仅是技术性的，而且是社会性的——让人们可以最大限度地使用自己的技能，并且提高这些技能。这些项目经理确保自己的员工拥有完成任务所必需的工具。这些项目经理鼓励提问，并且乐意与员工辩论；他们给每位团队成员设定最合适的挑战；他们在需要的时候提出批评；他们建设一个人人乐于工作的场所；而且他们采取必要的调整以保障各项事宜运作良好。简单地说，好的经理培养他们的员工，就像保姆培养她们照看的孩子一样。

一个保姆，在传统的英式文化中，受雇于某个家庭来照看孩子。保姆通常要具有教师、护士和厨师的技能，对孩子的体格、心灵、社交、创造性和智力发展都要负责。在每天的日常活动中，保姆要确保孩子远离伤害，保证孩子们得到了足够的新鲜空气与锻炼，食用有营养的食物，并且增进对世界的理解，学会更多在世界上生存的技巧。除了照看孩子，保姆还需要与孩子的父母就孩子成长方面的顾虑进行沟通，鼓励孩子的特殊天赋。保姆创建出一个安全的环境，使孩子能适当冒险并从中学到新知。

经理们拥有这些与保姆类似的才能，就能通过鼓励和培养员工的天赋，从员工那里获得更多、更好的工作成果。

迄今为止，我为之工作过的最好的经理是Peter Ford。这再明显不过了，比如他让员工在工作时各尽其能。举一个例子，我们在一大间开放式设计办公室工作，这不是最好的思考环境，于是他设法为团队弄到一些消音的屏幕，并保留了几间“静室”。所有的这些，还有他为我们做的其他事情，牵涉了我们所不知情的协商和政治。他鼓励我们阅读，在系统开发的时候讨论新的想法。他为团队购买书籍和杂志，并安排时间让我们聚在一起讨论。当我们觉得不开心或者不舒服的时候，他会注意到这一点，跟我们交谈，帮助我们。他保护我们不受组织其他人和事的干扰，但如果他对我们不满意，他会让我们知道。他办公室的门很少关着。Peter就是我们的保姆。——SQR

如果注意到如下一项或者多项情况，那么你所在的组织就已经有一些“保姆型”经理。不必预约就能见到你的头儿，或者不必在琐碎和令人生厌的管理工作上花费太多时间。周围是开放的氛围，人们畅所欲言，互相学习。这种经理认为培训或进修非常必要，而不是视之为奢侈烧钱。他们还会单独抽出时间（比如早晨咖啡闲谈或者周五下午阅读探讨），让大家在一起讨论新的想法。

在任何由人组成的团体里面，总会有流言蜚语、小道八卦和一些磨洋工的情况。然而，在被经理细心呵护的办公室里面，这类浪费时间的事情会极少，因为经理确保团队成员对于实际进行中的事情都非常清楚。人们不需要去靠打探小道消息以得知组织内发生的事情。与之相反，他们觉得自己充分知情和受到信任，把精力都放在自己的本职工作上面。

一个类似于保姆的经理会把他自己看成是工作的催化剂。传统保姆的工作满意度来自于看到孩子能力的发展，“保姆”型经理的工作满意度则来自于看到每个团队成员在个人角色方面得到发展、生产率得到提高，并对自己的工作更加满意。

这个模式的反模式有：经理把工作重心放在员工内部的明争暗斗上面、放在行政管理上面、放在流程上面，抑或放在逢迎更上层领导上面；绘制、调整PERT图和甘特图比与团队成员交谈更重要；还有一些经理承担了太多的实际开发工作，而不是去解决好团队的需求。

你们组织如何看待经理的角色？他们会因为“催化”了工作受到赞扬吗？你们是雇佣“保姆”还是“管理者”？模式6牵涉性疼痛

项目治愈了外部的病状，却没有根治内部的病因。

牵涉性疼痛这个术语通常是指疼痛不是表现在病源位置，而是表现在身体的其他部位。举例来说，脊柱损伤患者并不会觉得脊柱有问题。坐骨神经痛也是如此：病人感觉到腿部疼痛，但是问题却是因为椎间盘脱垂压迫脊椎神经导致。你可以费尽心机治疗病人的腿脚，但那并不能消除疼痛——因为病因在其他的地方。类似地，患有心脏病的病人通常会感觉左臂疼痛，治疗左臂对于挽救病人的生命没有任何帮助。

在项目立项的时候，人们往往会解决显式的问题——最明显的、客户疼痛感最强的问题。但是，如果只盯住牵涉性疼痛，项目交付的产品——一旦交付了——最终就会变成极大的浪费，因为它对于解决真正的需求几乎没有任何的帮助。

考虑下面的例子：忘记密码的银行客户向安全部门申请重新设置密码。在确认新密码生效之前，会牵扯到极其复杂、成本昂贵的用户鉴定流程。在一家英国银行，每年花在重新设定密码的开销都会超过400万英镑。于是，一项旨在构建新的软件以简化密码重置流程、降低密码重置成本的项目开始了。

项目开始解决牵涉性疼痛，而不是问题根源（太多人忘记他们的密码）。由于巴洛克式密码设置协议，用户最终得到的密码并没有保存在他们的脑海里面，这家银行收到的“我忘记了密码”的请求远远多于其竞争对手。如果银行解决了真正的问题，从成本的角度上看，它就能极大减少请求的数量，现有的密码重置流程也就能非常良好地继续运作。

为何只解决牵涉性疼痛而不是病源？观察到的一个普遍原因是不愿意去做调查研究。有时是因为组织的文化，有时是因为项目需要立即着手进行：“听着，我非常清楚我所要的。所以，给我生成这些报表就够了。立刻！马上！”在很多组织的内部，分析师需要非常有勇气才能提出问题：“如果这些报告在手，你会用它们做什么？你真正想做的是什么？”

有时，我们只想在最亮的灯光下找寻。比如说，我们可能倚重自己所具备的技术，用与我们所熟知的解决方案最契合的方式来看待问题：问Web服务设计人员如何解决业务问题，他通常会给出基于Web服务的解决方案；问数据库设计人员，你会得到从数据库角度产生的解决方案。不消说，二者都会轻易地忽略其他与自己所偏好的解决方案契合得不够完美的方面。此外，我们可能更喜欢解决最吸引人、能够产生最炫产品的问题。不管哪一种方案，工程师都急于针对明显或者明了的问题找出独创性的解决方案，但他的技术能力却用错了方向，不能带来正确的结果。

是否在处理牵涉性疼痛，一个强烈的信号是临时补丁：允许事情出错，然后解决错误。当目前系统需要做一些修正的时候，这些补丁就会骤然出现。临时补丁用来修正问题的外部情况，而没有去修正主要的系统。临时补丁如同创可贴，很少（甚至从不）能帮助解决问题的根本原因。但是，当一条补丁看上去有效，更多的补丁就会被采用，有时甚至每个补丁上面都是一层又一层的临时补丁。每次在采用临时补丁的时候，这种“创可贴”看上去比外科手术更便宜、更划算。

很多问题的根本原因都是细微的，而且通常与表面的症状一点也不相干。但是，集中精力研究真正的需求，解决真正的问题，总是能事半功倍。模式7明日复明日

每个人都有时间窗，提醒自己立即采取行动并持之以恒，直至工作完成。逾出时间窗的交付日期不会导致任何紧迫感，因此也就产生不了行动的动力。

如果里维尔在午夜纵马驰过马萨诸塞州的村庄和乡镇，呐喊着：“不列颠人要来了！不列颠人要来了！就在明年的某个时刻——我不确定具体何时何地，但是我确定是在明年，不列颠人就要来了！”那么又会发生什么情况呢？“保罗·里维尔跃过了黑夜，

一如他的警报跃过黑幕

传到米德塞斯的每个村庄和农场，

蔑视和无所不惧的呼喊，

黑暗中的一道声音，门上的一次敲门，

一句永远传诵的话语！

从历史的晚风中传来，

经过我们所有的历史，传诵至今，

在黑暗、危急和必要的一个小时

人们被惊醒，倾听，

骏马的蹄声气势如虹，

以及保罗·里维尔的午夜警报。”

对保罗来说，不存在“明天”，他对紧迫性有天生的直觉。

你能预料到他肯定不会获得期望的回应，倒很可能会有人愤怒地吼道：“闭嘴，保罗！”甚至偶尔还会被人投掷夜壶。

紧迫感是实际行动的重要催化剂。如果事情不再紧迫，它在今日待办事宜的列表上就会被排到后面。其他事情的紧迫性就更为显著，今天就应该处理所有那些需要几天才能完成的事情。

每个人都有时间窗，提醒自己立即采取行动以完成工作。对于大多数人而言，这个时间窗的长度是30到90天。我们可以分析现在的处境，预料出未来30到90天的工作进展。我们可以计划这段时间的工作，感觉到紧迫度。我们即刻着手，目光牢牢地盯住需要完成的事情。

除此之外，逾出时间窗的日子都是“明日”。“明日”是这样一种状态：意识到自己需要负责完成工作，但却没意识到如果期望成功，自己就必须从现在开始。

大多数项目的周期都长于人们认知紧迫性的时间窗。当组织告诉他们在未来30个月之内完成项目的重要性是多么令人难以置信时，人们在内心深处并不能感觉到紧迫性。他们听到了这个消息，他们理解了它的重要性，但在脑海中，有一个声音在告诉他们：“30个月，那时你也许都见马克思了。”

大规模的项目通过让大多数人保持对时间窗的关注，来避免“明日”的影响。他们把工作转化成在90天之内——通常在30天内——能够交付的具体任务。你能听到如下的交付建议。“在接下来的两周里面，让我们只是针对证券交易员用户创建交易界面的原型吧。”“让我们写一些代码，使得系统能够接受新的订单，检查订单项是否有库存，然后发送一条处理消息。不用去管订单修改或者取消，抑或其他的事情，只是负责新的订单。我们要能在这个月中旬演示这个功能，觉得怎么样？”

对于项目成员，其好处在于他们在处理这些短期任务的时候，真实的终点线如同就在眼前。在基本正常的项目上，人们努力工作，集中精力于两周之内需要完成的原型任务，就好像他们要在两周之内交付最终的系统。

但是，要小心，关键在于每个时间窗都必须产生真正的交付物。只有进度是远远不够的。诸如“让我们在五月底完成50％的规范”这样的任务，并没有提供一个令人满意的结尾。人们会在心里嘀咕：“百分之五十——也就是说五月底不能全部完成了。剩下的工作到底什么时候才能完成？”

警惕“明日”的另一种特殊变体：耗费大量的时间来准备开始。每个人花时间去寻找完美的支持测试的工具；每个人不厌其烦地讨论如何制订库文件，以向开发人员提供最完整的支持。如果这些时间被节省下来，匀到项目的结束阶段来完成工作，它们的价值会更大。

回忆起自己在苹果公司担任项目经理的日子，Sheila Brady对于“明日”与时间窗有这样的评论：“所有的项目，一旦式微到后期，即使时间表上延长一周，也依旧摆脱不了失败的结局。”

就像所有优秀的项目经理一样，Sheila意识到项目前期阶段的时间并没有像结束阶段的时间一样被仔细地对待，使行动开始的最佳方式就是不等“明天”，今天就开始动手。模式8眼神交流

当任务紧迫而且复杂的时候，组织往往会把项目成员安置在一起工作。

如今，项目分布式开发合作的潮流已经大行其道，也没有任何迹象表明这种做法将会在未来消失。你与我们一样了解这一事实。也许你已经发现自己在寻找理由，向手下的人解释为什么大部分的员工都在这个市区，而在Kissimmee和Richmond- upon-Thames却也有几处的偏远办公点。都是因为想充分利用金钱和资源，对吧？

现在，还是痛痛快快地承认吧，如果项目的成败对你性命攸关，你难道会不想把所有的项目成员都安置在一个地方，让他们可以在视线范围之内看到对方？当然，或许远方的团队有一些人身怀特技，其他地方的项目团队没有人能与之媲美。如果这样，你可能会愿意付出分布式办公的代价，否则就不然。关键在于，之所以分散工作应该是因为缺乏人才和技能，而非金钱和资源短缺。而且，工作越紧急，团队成员就越有必要在一起。

当所有全职的、专注的项目成员处在同一个屋檐下工作时，会产生一些很神奇的效果。他们了解彼此的需要和能力，而且随着了解的增多，他们会调整自己的行为方式，以获得最佳的整合效果。比如，这种团队合作的理念与从运作良好的曲棍球队中观察到的现象非常相近。有一种无形的信息交流使得人际之间的合作变得顺畅，而这依赖于人们在地理位置上的接近度。

类似地，在开发团队里面有一些关键的信息交流对于紧密的合作也非常必要，其中最重要的是信任的给予和获取。你可以通过电子邮件和电话与远方团队的成员进行交流，把某些事情了解得非常清楚，比方说，对方要求的规范文档，以及他们应许和请求的承诺。如果问你是否相信对方向你表达的信息，你也许会说相信，为什么不呢？但是如果问你：“你在多大程度上相信自己所了解到的信息？”则根据对方的工作地点不同，答案也迥然不同。对于一起工作的团队成员，承诺的应许和需求的表达还伴随着双方的肢体语言和过去的经历，这些也促进了关系的不断演化。你清楚对方的真正想法。同样的承诺和需求飞过千山万水的阻隔，在接收到的时候就已经丧失了大量背景信息。

中间横亘着距离，双方很难相互信任。同样，也很难察觉语言上的微妙之处、信心、某些讽刺和挖苦、真实意图、信服程度、无望感和无能为力感、轻重缓急以及话外之音。缺乏了这些潜台词，沟通就变得脆弱。纵然明白了大的图景，得出的结论也依然包含着不确定的因素。缺少了这些沟通，一个项目还能顺利进行吗？当然也行，但它肯定没有在一起工作的效果好。

在第14项模式中，我们断言不得不采取分布式开发的团队，即使成员之间会面的机会很稀少，也能从这些会面中受益匪浅。目光接触能提升交流的效果。如果项目足够重要，为了利用其他地方的同类资源而采取分布式开发实在毫无意义。与之相反，如果分散工作方式也能被本国或者全球其他地方的人员接受，那么很明显该项目并不特别重要。在可以做到目光接触的组织内，紧急性和复杂性是用来保证项目团队一地协同工作的王牌。

在忽略一地协同工作优势（这不能容忍）的组织里，分布式团队无坚不摧的神话早已根植管理层的思想深处。任何人，不管身处何方，只要在项目开始的时候可以派遣，就自然而然成为新项目团队的候选成员。在这样的环境下面，团队只是挂着“团队”的名号而已。模式9情绪戒指管理

经理不是基于摆在项目面前的风险、决策和问题来汇报项目状态，而是基于团队的活动、付出和热情。

去听听项目经理如何谈论他们的工作，特别是他们如何交流各自项目的状态。这往往在一定程度上能反映出他们管理项目的方式。

下面的项目状态概要出自一位项目经理，我们假设她叫Donna。虽然这个例子可能有些极端，但它是众多真实报告的缩影。“我很高兴地向大家汇报我们正处于此次发布的特性完成（Feature Complete）阶段。虽然有一些人的进度比较慢，但我依旧为团队取得的成就，以及每个人的努力工作感到骄傲。看到办公室里每个人脸上的笑容，我相信团队的士气依旧高涨。我很感激能够拥有表现如此优异的团队成员，而且我知道他们在不久的某天就会解决掉剩下的一些特性。“接下来是一个悲伤的消息，我很遗憾地告诉大家Bob Jensen决定离开公司。Bob在过去五年里一直是我们QA团队的中流砥柱，我们会想念他的。Bob是继上月Kathy Enright后辞职离开的第二位QA。众所周知，Kathy也是一位非常有经验的测试人员，所以大家能想象我们的QA经理要开始忙得汗流浃背了。“我，同样有一点担心某些新特性上的测试进度问题。现在来下结论还为时尚早，所以我还只是有一些不安。虽然见到好帮手和好朋友Kathy和Bob消失在落日的余晖里面我很伤心，但我们的QA团队一向以善于挺过艰难时期而著称，而且我知道他们以后会加班加点地工作。随着时间的推移，我们会知道更多的信息。”

请注意Donna是如何描述项目当前状态的。

1．她更多是在谈高层次的活动、团队成员的认真努力，以及每个人对项目的热情。

2．她关注的是当前，以及之前或之后一点点时间，没有在时间、资源和交付物的整体框架内谈论团队的状态。

3．当她识别出不符合计划的事情时，她谈的是由这些事引发的个人情感，比方说，“我，同样有一点担心……测试进度问题”。

4．她的观察大体上是开放结论式的和未确定式的，比方说，“我知道他们在不久的某天就会解决掉剩下的一些特性”。

5．尽管偶尔有一些消沉的话语，这份报告总体上的语气是乐观的。

你也许会问，乐观的、带一点点情绪化的经理，有什么不好？当然，没有什么不好。但是当项目经理的交流方式非常强烈地倾向这一种极端，你往往能发现下面两个问题。首先，这种风格的报告并没有完全达成最基本（所有的项目状态报告都应该达成）的目的：它没有把我们的注意力集中到那些最需要立即采取纠正举措的内容上，以尽量增加项目成功的可能性。它也没有指出现有哪些情况需要我们在接下来的几个星期里面注意、决策和行动。由于Donna描述事情的方式，我们获得的只是从几个方面对工作整体的定性评价，根本没有对任何问题进行清晰的定量分析。

其次，频繁地使用这种交流方式更是有害无益，因为项目经理仅仅关注开放结论式的、目前进行中的行动，常常对他们努力追求的最终结果没有清楚的认识。他们（和他们的团队）只是尽可能快地一步一步低头赶路。但是这些团队极有可能在项目的最后一分钟发现按时交付根本没有指望，或者他们已经偏离航向太远，最后所能交付的东西根本不是他们所承诺的。

我们之前说过Donna的交流方式处于一种极端，现在，让我们来听听Lisa，她则是处于另一种极端的项目经理。“上周4月28号，我们赶上了特性完成（Feature Complete）的日期。本次发布包括18个组件，其中有15个已经处于‘特性完成’的状态；两个将在本周结束之前完成。最后那个组件——数据仓库接口——还要再迟一些才能完成，我们估计它得到5月20号才能‘特性完成’。QA团队正在评估在多大程度上重新设定优先级才能解决这个延误，或者该延误是否会导致我们建议更改交付日期。在我们下次5月10号的核心小组会议上QA团队将给出一个建议方案。不管怎么样，产品管理领导已经同意我们下个月可以在没有那个特性的情况下开始进行公开beta测试。“截至本周，已有特性的自动化回归测试套件已经完成，现在每晚都会运行。测试通过率是在80％左右，对于发布周期的本阶段，这是典型现象。我们希望测试通过率在四周后，也就是在公开beta测试的阶段能达到90％左右。“由于在过去的30天里面有两位QA工程师辞职，新特性测试的开发工作变得迟缓。相应的招聘工作正在进行，但我们必须做好最坏的打算——假定新招聘人员不能及时入职和磨合充分来支援我们的这次发布。QA正在评估从产品支持团队借几个人帮忙的可能性。在一周内我们应该能知道这次人员流失如何影响新特性的测试覆盖率，但是现在，我们必须假定我们不能达到进度表上的测试开发完成（Test Development Complete）里程碑了。”

Lisa的项目状态概要与Donna的在如下几个方面有所不同：

1．她选择了基于最能反映工作进展的交付物的状态来评述；

2．她关注于项目的产出、问题以及针对计划提出的修改建议，并且她指出了必要的纠正举措和决策；

3．她的评论是独立的，而非不可切分，而且大部分都是可测的；

4．她在客观和主观方面很好地做到了平衡。

很少有经理会完全像Donna或者Lisa一样交流，大部分都是处于两者之间。不管怎样，Donna式的经理们还是值得注意：长期关注于付出的努力而非进度本身，有时反映出项目经理没有很好理解领导和管理的区别。

哦，顺便说一句，尤为重要的是从自己身上寻找Donna的影子。如果你发现你的个人交流趋于这种方式，就要问自己是否需要这样做，因为正如Donna，你对团队应该走向何方并不是非常确定，而只知道每个人都在努力工作以求到达彼岸。模式10忠实信徒

个体把某种思想派系作为真理来膜拜，与圣典稍有偏差即被认为是亵渎神灵。

几乎所有流行的软件工程方法学都来源于软件从业者的经验，而不是基础性研究。人们积极地记录下项目里面对他们有效的东西，这些经验从一个小组传递给更广泛的群体。与很多业内领先的流程设计者交流之后，我们得知他们中的大部分人承认：（1）他们的方法来源于一定的领域或者项目大小；（2）他们的方法从来没有被期望如同描述的一样用在所有可能的环境中。

我们的CASE工具ProMod的早期版本里，把很多客户认为OK的东西都标识成错误。不管用的是何种方法，我们都是按照书上写的来做——我们是忠实的信徒。无论何时只要书中提出一项建议，抑或展示一个例子，我们都从中抽象出规则，然后作为硬性规定编码进系统里面。如果用户没有完全遵循我们的规则，我们就标识上一个错误。只是随着时间的推移，我们认识到应该把那些东西标识成警告，而不是错误。更进一步，我们认识到应该把所有的消息设置成可选的；换句话说，我们让用户决定是否开启这些设置，并且允许用户违犯规则。——PH

虽然大部分的流程书籍对于方法的可用性提出了一定的警告，但忠实的信徒要么忽略这些警告，要么从来不读那些包含警告信息的书页——大部分都作为书的最后一部分内容。如今，拥护XP的风潮日盛，那些人中有人甚至都没有读过Kent Beck第一本书的倒数第二章。在那一章里面，Kent很清楚地解释了该方法的不足。

我有一个客户因为她的软件工程技能和热情，被她的老板认为是一个主要的成功因素。我们讨论了他们最新版本2.1产品里面的UML

试读结束[说明：试读内容隐藏了图片]

下载完整电子书