“微软公司内部所有工程师的必读之书。”
　　——Peter Isensee，微软公司开发经理

　　本书揭示关于编码、测试和项目管理的残酷现实——一位微软的内部人士如实地向你述说。I. M. Wright的“Hard Code”栏目故意煽情，几年来在微软内部成千上万的工程师之间引起了激烈的争论。现在（也顾不上“家丑不外扬”了），我们把他的观点向所有人公开。
　　本书收录了49个栏目。作者重拳出击，对最令他苦恼的问题提出了最佳实践的解决方案，另外还加上了他坦诚的注解。他剖析了开发过程，审查了棘手的团队问题，批判了软件业务的运转方式——自始至终充斥着幽默和风趣。他的想法并不总是很受欢迎，但它们的的确确激发起了人们的讨论和想象，推动着软件相关的活动走向卓越。

　　怎样提高软件的质量和价值——从设计到安全
　　怎样切合实际地管理项目的时间表、风险和规范书
　　怎样为常见的低效率开发瘦身
　　怎样应用过程改进方法——避免固执盲从
　　怎样驱动一个成功的、令你自己满意的职业生涯
　　怎样不变成暴君——发展并管理一个欣欣向荣的团队！

无

献给当初对我说“你为什么不写？”的人：Bill Bowlus

这是一本关于极其实操性的书。它会比较乏味。但也许会比较有意义，你能从中得到知识，读后甚至对你产生些许影响，但读起来肯定还是干巴巴而无趣的。为什么这么说呢？
实操性强的书是乏味的，因为它是跟具体的项目、具体的人、具体的目标以及偏好紧密相关的。一次实践能不能产生“最佳”效果，大家可能看法不一。作者必须把实践列举出来让读者自己来选，并分析在什么时候、因为什么原因作出最佳选择。虽然这种做法是现实的、负责任的，但也是令人厌烦的，最终无法取悦读者。为释疑而设计的案例研究会使文字有趣味一些，但作者仍必须把选择的机会留给读者，否则作者就会显得傲慢、教条并且死板。
然而人们喜欢看到傲慢、教条、死板的学者之间的针锋相对。大家喜欢引用学者们的只言片语，与朋友和同事一起讨论。为什么不把这些最佳实践当作观点栏目来争论呢？唯一的条件，就是要有人愿意将自己扮演成一个思想保守的傻瓜。
本书的由来
2001年4月，在我历经了Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司总共16年的职业程序员生涯，以及在微软做了6年的程序员和经理之后，我转入了微软内部的一个以在公司范围内传播最佳实践为职责的团队。当时这个组正在运作发行名为《Interface》月刊网络杂志的一个项目。它很有意义，且富有知识性，但同样也是枯燥无趣的。我那时建议增加一个观点栏目。
我的上司Bill Bowlus建议由我来写。我拒绝了。作为一个半大孩子，我努力成为一个协调员，撮合多方产生成果。成为一个爱唠叨的实践学者会毁掉我的名誉和效力。因此，我当时的想法是说服一个大家公认的小心眼的工程师来写，他可能是我在微软前6年工作经历中接触过的一位最固执的开发经理之一。
但Bill指出，我有22年的开发经验，4年的开发管理经验，写作技巧也还行，而且有足够认真的态度来做这件事。我只需要放下自身的心理包袱。另外，其他开发经理都忙于日常的工作，不可能每个月来为我们写观点。最后Bill和我想出了一个用假名撰稿的点子，于是I M Wright的“Hard Code”栏目诞生了。
从2001年6月开始，我使用“I M Wright，微软逍遥的开发经理”这个笔名为微软的开发者和经理写了49个“Hard Code”观点栏目。这些栏目的标签行都打上了“绝对诚实，重拳出击”的标语。每个月，成千上万的微软工程师和经理都在读这些栏目。
前16个栏目在《Interface》内部网络杂志上发表了。随后同事们（Mark Ashley和Liza White）给我分配了更多的主题。我和《Interface》的美工Todd Timmcke还一起炮制了作者的很多搞怪照片。当网络杂志停刊的时候，我才得以喘息一会儿，但也停止了写作。
14个月之后，在我们组的同事Amy Hamilton（Blair）、Dia Reeves、Linda Caputo、Shannon Evans和Marc Wilson的帮助下，我又开始在内部站点上发表我的栏目。去年11月份，我将所有栏目转移到了一个内部的SharePoint博客上。
2007年春天，正当我打算休掉几年前奖励给我的假期的时候，我现在的经理Cedric Coco给了我在休假期间将“Hard Code”栏目内容整理出版成书的授权。而微软出版社的Ben Ryan也同意了。
除了我已经提及的人，我还想感谢《Interface》的其他成员（Susan Fario、Bruce Fenske、Ann Hoegemeier、John Spilker和John Swenson），其他帮助过本书出版的人（Suzanne Sowinska、Alex Blanton、Scott Berkun、Devon Musgrave和Valerie Wolley），支持我的管理层（Cedric Coco、Scott Charney和John Devaan），我现在的和以前的、复审过我的栏目并提出过很多主题的团队成员（William Adams、Alan Auerbach、Adam Barr、Eric Bush、Scott Cheney、Jennifer Hamilton、Corey Ladas、David Norris、Bernie Thompson、James Waletzky、Don Willits和Mitch Wyle），我才华出众的中学英语老师（Alan Shapiro），以及那些慷慨给予我反馈的读者们。特别地，我还要感谢我的妻子Karen和我的儿子Alex和Peter，他们让我做任何事情都充满信心。
本书的读者
组成本书的49个观点栏目最初是写给微软的开发人员和他们的经理的，这些是从我过去在软件行业6个不同的公司、28年的工作经验中提炼出来的。编辑和我一起修正了文字，注解了那些微软内部的特殊用语，使得本书适合于所有软件工程师和工程经理阅读。
我在这些栏目中表达的观点是我个人的，不代表我现在和以前任职过的任何一家公司，包括微软。我在栏目中的注解以及简介中的言论同样都是我个人的，与公司无关。
本书的组织方式
根据主题的不同，我把所有栏目分成了10章。前6章剖析了软件开发流程，接下来3章重点讨论人的问题，最后1章批判软件业务运转方式。用于解决这些问题的工具、技巧和建议遍布全书。本书的最后还附有术语表方便大家参考。
每一章的各个栏目均按照当初在微软内部发表的时间顺序排列。每章开头我都给出了一个简短的介绍，随后就是当初我以“I M Wright”名义发表的栏目内容。编辑成书的时候，我还适时在栏目中加上了“作者注”，以解释微软的术语，提供更新内容或者额外的背景知识。
编辑和我尽力保持了原有栏目的完整性。我们做的，仅仅是纠正语法和内部引用。称得上改动的其实只有一处：就是将原来一个叫“你被解雇了”的栏目标题改成了“最艰难的工作”，因为以前那个标题太容易让人误解了。
每个栏目都以一段激昂的演说开场，然后就是对问题根源的分析，最后以我对这个问题如何改善的建议结束。我酷爱文字游戏、头韵和通俗文化，因此栏目中充斥着对这些东西的引用。特别是大部分栏目的标题和副标题都直接取材于歌词、电影对白和有名的谚语。是的，我自娱自乐，但撰写这些栏目确实给我带来了些许乐趣以及痛快的宣泄。希望你也会喜欢！
系统要求
本书提供的工具都是微软的Excel 2003和Word 2003格式的。只要你的电脑上安装有Word和Excel，你就能使用这些文件。
微软的组织结构
因为这些栏目最初是写给微软的内部员工看的，因此简要了解一下微软以及我在工作中扮演的角色会有助于更好地理解这些文字。
目前，微软的产品开发分成三大业务部门，总共有大概25条产品线，超过450个产品单元和众多的功能团队。这些部门是平台产品与服务部门、微软商业部门、娱乐与设备部门。部门内的产品线是由相关的产品套件整合在一起形成的，比如Office System和Visual Studio。
每条产品线包含了大约20个独立的产品单元。通常情况下，这些产品单元共享源代码控制、建造、安装、工作条款跟踪和项目协调，包括价值主张、里程碑安排、发布管理和工程支持。除了这些协调服务之外，产品单元还有高度的自主权，可以对产品、流程和人员作出自己的安排。
一个典型的产品单元通常有一个产品单元经理（Product Unit Manager，PUM）和三个工程工种经理：部门项目经理（Group Program Manager，GPM）、开发经理（Development Manager）和测试经理（Test Manager）。其他工程工种，比如用户体验、内容发布（比如在线帮助）、实施，可能单独对某个产品单元负责，也可能在产品线或者整个部门中共享。
每个工种都要抽出一个或多个代表，以组成一个叫功能团队的虚拟组织，来开发具体的产品功能。这些人的工作仍然汇报给各自的工种经理。有些功能团队选择敏捷方法，有些喜欢精益模型，有些采用传统的软件工程模型，有些则根据实际情况混合了上述多种方法。
微软怎么能包容所有这些多样性和产品的区域自治、还能为朝着一个共同的目标有效地工作呢？这就要靠产品线公共的项目协调了。举例来说，产品线的价值主张为所有产品单元和他们的功能团队设置并统一关键应用范例、质量尺度和框架体系。
为了促进跨部门和产品线的协调和共享，特别是为提高质量和效率，微软还设立了一个组织叫Microsoft Trustworthy Computing and Excellence。它是我的上级组织。具体来说，我的工作职责是，要让微软全球超过1万名的开发者在构建令人兴奋的、高质量的用户体验时，能够做得更加开心、更富有效力。不用说，这是一项长期的工作。
我的团队每月将开发部门的领导层召集在一起，讨论问题并指导我们的工作。我们研究公司范围内乃至整个行业内的工程方法，以期找到新的机会和领域去提高。我们通过网络共享工具、最佳实务，以及实施职业生涯指导。我们举办各种活动和奖项评比，与各种团队商讨，为开发中的各个级别、各种角色提供技术培训。非常棒的工作！另外，我每月还在写着观点栏目。
示范工具和文档
本书提到的示范工具和文档，作为本书的附属内容，都可以通过如下网址下载到：
http://wwwmicrosoftcom/mspress/companion/9780735624351在线资料列表
工具栏目章节Sprint backlog: SprintBacklogExamplexls; SprintBacklogTemplatexltThe agile bullet（敏捷子弹）2Product backlog: ProductBacklogExamplexls; ProductBacklogTemplatexltThe agile bullet（敏捷子弹）2Spec template: Spec templatedocBad specs:Who is to blame（糟糕的规范书：该指责谁？）3Spec checklist: Spec checklistdocBad specs:Who is to blame（糟糕的规范书：该指责谁？）3Pugh Concept Selection:PughConceptSelectionExamplexls; PughConceptSelectionTemplatexltReview this（复审一下这个）5Inspection Worksheet: InspectionWorksheetExamplexls; Inspection WorksheetTemplatexltReview this（复审一下这个）5Interview Role Playing, a howto guide: InterviewRolePlayingdocOut of the interview loop（面试流程之外）9
为本书提供的支持
为了保证本书及其附属内容的准确无误，我们尽了最大的努力。本书所有修正和改动都会搜集起来并放到微软的知识库中去。微软出版社通过如下站点对本书及其附属内容提供支持：http://wwwmicrosoftcom/learning/support/books/。
问题和意见
如果你对本书及其附属内容有任何意见、建议或问题，并且通过访问上述站点仍然无法解决，请给微软出版社发送电子邮件: mspinput@microsoftcom，或者按照如下方式邮寄：
Microsoft Press
Attn: I M Wrights “Hard Code” Editor
One Microsoft Way
Redmond, WA 980526399
请注意，上面的地址对微软的软件产品不提供支持。

长期以来，我一直在阅读Eric Brechner以I M Wright为笔名撰写的栏目。当我第一次见到作者本人的时候，我费了好大的劲才让自己相信，我是在跟同一个人说话。栏目中的Wright先生非常地自信、张扬，然而站在我面前说话的人却那么谦虚、彬彬有礼、非常友好，他看起来更像Clark Kent。
　Clark Kent是“超人”的名字，他具有超强的本领，是一个虚构的超级英雄，美国漫画中的经典人物。——译者注我很关注微软团队在软件开发的过程中是如何处理技术与人际交流之间的关系的；这类栏目总是我的最爱。看到大量的公司内幕被写了出来，我常常会感到吃惊——我不知道还有多少不为人知的故事没有说出来。
　　大型项目中的软件工程管理者面临着3个基本问题。第一个是，程序代码太容易被改变了。跟机械或土木工程不一样，它们在现有系统上做一次改变总是要付出实实在在地拆毁某些东西的代价，而软件程序的改变只需要敲敲键盘就行了。如果对一座桥的桥墩或一架飞机的引擎做一个错误的结构性更改，由此产生的后果，即使不是专家也很容易就能看出来。然而，如果在一个现有程序上做修改，对于其风险，即使经验丰富的软件开发者进行了充分的讨论，其结果常常还是错的。
　　建筑领域中的情况实际上可以很好地用来比喻软件开发。基于程序代码在系统中所处的层次，可以把其比作为“基础、框架和装饰”代码。“基础”代码具有高度的冒牌效应，它们的改动常常会引发严重的连锁反应。“装饰”代码比较容易改动，而且也需要经常改动。问题是，累积了几年的改变之后，复杂的程序就跟历经过几次装修的房子差不多了——电源插座躲到了橱柜的后面，浴室风扇的出风口通向了厨房。再做任何改变的话，其副作用或最终的结果都是很难预知的。
　　第二个基本问题是，软件行业还太年轻，关于可复用组件的正确标准实际上还没有被发现或建立起来。螺栓是否应该放在离开16英寸的地方，以同时适应水平或垂直的4英尺×8英尺的干垒墙或夹板？我们不仅在这类问题上还没有取得一致意见，甚至我们还没有决定，是否像螺栓、干垒墙和夹板这样的组合更可取，还是我们要去发明像泥浆、稻草、石头、钢铁和碳化纤维这样的组合。
　　最后一个问题实际上是第二个问题的另一种表现形式。每个项目中重复发明的软件组件也被重复命名了。软件行业里对现有的概念发明新的名字是很常见的，即使用的名字相同，这些名字也以新的方式被重用。行业里有一个心照不宣的秘密：软件开发最佳方法的大量内容，实际上是由不同的人群参与讨论而且使用了不同的名字，他们对彼此正在说的东西都没有一个哪怕是很朦胧的想法。
　　表面上看来，这些都是很简单的问题。建立一些标准，然后强制实行它们。在快速进步的大容量、高价值、低成本的软件世界里，这可是一个让你的业务落败的捷径。实际情况是，软件最大的工程障碍，同时也是它最大的优势。无处不在的软件（运行在低成本的个人电脑和互联网上），已经使得以惊人的步伐去创新成为可能。
　　随着微软的成长，公司已经不能在最佳工程实践的研究方面大量地投入，然后经过深思熟虑，挑选出其中具有最好质量的方法。个人电脑和Windows的成功，已经把公司从按传统方式做些小项目的形态转变出来，转而要去谱写开发有史以来最庞大、最复杂软件的新篇章。
　　为了能够创建出平衡风险与效率、创新的最佳系统，微软面临着持续不断的挣扎。考虑到我们的一些项目极其复杂，这些努力甚至可以称得上“英勇无畏”。在过去的一段时间以来，我们已经设置了专员，建立了专门的组织，他们都一心一意、致力于这个行业里最困难的事情——“软件发布”。我们已经学会了很多的民间传说、风俗、文化、工具、过程和大拇指规则，这些都有助于我们建造和发布这个世界上最复杂的软件。但与此同时，每天都处理这些问题难免也让人心惊胆战、士气受挫。Eric的栏目正是大家跟我们一起分享和学习的极好方式。
　Rules of Thumb，是指没有经过科学实验、直接从实践中总结出来的方法和规 则；它们在很多情况下都有用，但并不是放之四海皆准。——译者注Mike Zintel，微软公司Windows Live内核开发部门总监
　　2007年8月

Eric Brechner：Eric Brechner: 微软公司“卓越开发”部门的总监，在软件行业已经积累了20多年的经验。他从2001年开始写“Hard Code”栏目，作为一种资源提供给微软的员工。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今，这些观点走出了微软，走向了整个开发社区。

陆其明：暂无简介

读者对 I M Wright的“Hard Code”
栏目的喝彩
序
前言


第1章项目的不当管理1
2001年6月1日：“开发时间表、飞猪和
其他幻想”2
里氏震级估计2
风险管理3
客户赢了4
2001年10月1日：“竭尽所能：再论
开发时间表”4
软件工程绝对是含糊的4
相信一半你看到的，别信你听到的5
激励：不能光靠比萨和啤酒6
在日期上沉沦7
2002年5月1日：“我们还开心吗？
分诊的乐趣”8
战争是地狱8
这不是个人的事情8
分诊的5条黄金法则9
魔鬼藏在细节里面10
很难进行下去，不是吗10
谨小慎微11
2004年12月1日：“向死亡进军”11
暗箭伤人12
对失败的连祷13
转折点14
很少有人走过的路14
2005年10月1日：“揭露真相”15
遭受错觉之苦15
拿把叉子扎进我的身体16
给我个坦率的回答16
给猪抹口红17
看看所有这些传言18
我想知道真相19
第2章过程改进，没有魔法20
2002年9月2日：“六西格玛？
饶了我吧！”21
啊！这是什么巫术21
召集骑兵22
在混沌之外建立秩序22
2004年10月1日：“精益：比帕斯雀
牛肉还好”23
任何事情都要适中23
俭则不匮23
过量生产24
走向深处25
运输25
多余动作26
等待27
过程不当27
库存28
缺陷28
组合应用28
2005年4月1日：“客户不满”29
但愿不知道29
太过分，太迟了30
敏捷错觉31
回退你的步伐31
更多用武之地31
使用正确的工具32
布基胶带和打包钢丝33
客户满意33
2006年3月1日：“敏捷子弹”34
真理的敌人34
拨乱反正35
准备改变了吗36
让他说话37
你完善我37
有点极端38
准备玩橄榄球38
最后你要知道的39
第3章根除低下的效率41
2001年7月1日：“迟到的规范书：
生活现实或先天不足”42
对于每次变更，搅动，搅动，搅动42
走廊会议43
委员会议43
规范书变更请求43
预防是最好的治疗44
2002年6月1日：“闲置人手”44
宝宝做了件极坏的事情45
告诉我该做什么47
俭则不匮48
2004年6月1日：“我们开会的时候”48
为什么我们会在这里49
我们正在试图做什么49
为什么他们会在这里50
为什么我现在才听到这个50
接下去要做什么51
2006年7月1日：“停止写规范书，
跟功能小组呆在一起”51
你失去理智了吗51
在那里进退两难52
特殊要求52
我不记得了53
坚持做一件事情53
你准备好了吗53
2007年2月1日：“糟糕的规范书：
该指责谁？”54
树立靶子54
沟通分解54
保持简单容易55
变得稳健55
获取反馈56
集成质量检查56
差别在哪57
第4章跨越工种58
2002年4月1日：“现代临时夫妻？
开发与测试”59
我怎么爱你？看看我的招术59
必要的邪恶或珍贵的伙伴60
每个人都要知道自己的弱点61
你完善我61
2004年7月1日：“感觉性急——测试者
的角色”62
高级保护62
改变一下对你有好处63
黎明时分63
充分利用数据64
非常酷——我保证你64
2005年5月1日：“模糊逻辑——
君子之道”65
包罗万象65
他们跟我们不一样66
通过安检68
着手去改变68
更好地在一起68
2005年11月1日：“废除工种——有什么
理由搞专业化？”69
历经未来的日子69
考察它的极限70
足球是门科学70
两者之间的距离71
你深陷其中71
第5章软件质量不是梦72
2002年3月1日：“你对你的安全
放心吗？”73
小心晃动的钟摆73
做正确的事74
安全受制于最薄弱环节74
领导、跟随或者离开75
2002年11月1日：“牛肉在哪里？
为什么我们要质量”75
情况变了76
足够好还不行77
艰难的选择77
终于有足够的时间了78
再检查一遍79
医生，治好你自己的病79
步步为营80
太多疑问80
2004年4月1日：“软件发展之路——
从手工艺到工程”81
工艺制桌子，工程造汽车81
其实你知道82
真实面对自己82
数字的含义83
各人有各人的习性83
大处着想，小处着手84
从优秀到卓越84
2005年7月1日：“复审一下这个——
审查”85
糟糕的混合85
完美风暴85
谁来负责86
你有什么想法86
正是这个形式87
孩子，准备好了吗87
再检查一遍88
神奇的汇总会议88
审查的诀窍89
走上正道90
2006年10月1日：“对质量的大胆预测”90
谜？我不这么认为90
邪恶双煞91
嫌疑惯犯91
你会喜欢它的91
停止卖弄愚蠢92
质量就是没有意外92
第6章有时间就做软件设计94
2001年9月1日：“错误处理的灾难”95
恐怖，恐怖95
使用异常96
别丢弃，用上它96
2002年2月1日：“厨师太多烧不好菜——
唯一权威”97
一幅图片抵得上一千个字97
有人确切知道现在几点了吗97
只能有一个98
万物皆有联系98
2004年5月1日：“通过设计解决”99
如何才算足够好99
设计完成99
细节，细节101
让我看看你是由什么组成的101
当心缺口102
成功处方103
2006年2月1日：“质量的另一面——
设计师和架构师”103
你必须比那做得更好103
改变一下对你有好处104
他这么做不对104
正确的做法104
下一次，试试雕塑105
关键要有正确的工具105
打破这些壁垒106
2006年8月1日：“美妙隔离——
更好的设计”106
分解难做106
正确的做法107
团队不需要“我”107
循序渐进108
猫狗不分家109
第7章职业生涯历险110
2001年12月1日：“当熟练就是目标”111
每个人都要知道自己的弱点111
享其成但不坐等112
我希望他们尊重我112
我们都牵连其中112
2002年10月1日：“生活是不公平的——
考核曲线”113
我不想再逆来顺受了114
知识就是力量114
关注业务114
前进，让我快乐115
伸出手去接触某人115
有了柠檬？制作柠檬水116
改变你的主意116
方向盘后面的人116
2006年11月1日：“职业阶段中的角色”117
一个人同时扮演很多角色117
搞清楚职业阶段118
我是有抱负的118
资历过高118
我是特殊的119
只能选一个119
你想成为什么119
2007年5月1日：“让你自己与
世界相连”120
你认识的人120
我利用习惯121
难道你不好奇121
你得到了我们的感谢122
我回头再找你122
欢迎来到这个世界123
第8章自我完善124
2002年12月1日：“要么听我的，
要么走人——协商”125
一个你无法拒绝的方式125
逐渐长大125
我脑子里闪过的阴影和凶兆126
不要伤害Messenger126
皆大欢喜127
2005年2月1日：“最好学会平衡生活”128
平衡是关键128
光说不练128
我甚至不能平衡我的支票簿129
平衡好，一切都好130
2005年6月1日：“时间够用了”131
直接告诉我131
免受打扰之苦131
找到你的乐园132
我们谁也不笨132
我们必须共同承担133
告诉我必须做什么133
他还是个孩子134
你应该休息一下134
这里秩序井然134
坦诚相待135
大有可为136
2005年8月1日：“有理有节地控制
你的上司”136
我没辙了136
知彼知己137
他们能自我适应137
把水卖给鱼138
势利的眼睛139
付诸行动139
敢于做梦140
2006年4月1日：“你在跟我说话吗？
基本沟通”140
为我着想一下141
告诉我你想要什么141
你什么时候想要142
缩小注意力跨度142
就这样完了143
2007年3月1日：“不只是开放和诚实”144
那不是理由144
我会对你诚实144
那不容易145
他们似乎有个开放政策145
无处隐藏146
跟我想的不一样146
走上正道147
第9章成为管理者，而不是邪恶
的化身148
2003年2月1日：“不只是数字——
生产力”149
小心你希望得到的东西149
扮演一个角色150
卓越开发者的素质150
你要做法官151
2004年9月1日：“面试流程之外”151
抱怨得不到帮助151
90%是准备152
那就是问题152
白板编译器153
帮招聘专员准备154
再次帮面试官准备154
友情提醒155
最后的难题155
2004年11月1日：“最难做的工作——
绩效不佳者”156
你期望什么156
知难而进157
寻求专业援助157
没人想失败158
目标是成功158
无所求，则无所获158
你不会总能如愿159
2005年9月1日：“随波逐流——
人才的保持和流动”159
我只是想环球旅行160
不错的水坝160
像河水一样流动161
新鲜血液161
分享就是关爱162
成长空间162
我必须要旅行163
放任自流163
2005年12月1日：“我能够管理”163
持续送出的赠品164
优秀就够了164
草率行事164
我想要工作165
我不是物件165
从优秀到卓越166
我服务于人167
2006年5月1日：“不恰当的比较——
病态团队”167
想要挑起战争167
这不是竞争168
我会给你些提示169
团结在一起169
第10章微软，你会喜欢它的171
2001年11月1日：“我是怎么学会停止
焦虑并爱上重组的”172
沿着巴别塔下来172
地狱里的生活173
很少有人走过的路173
容忍问题还是主动去解决174
2005年3月1日：“你的产品单元经理
是个游民吗？”175
有计划的人175
我等不及要去实施了176
魔鬼藏在细节里面176
道路规则176
回到正确的跑道上177
2006年9月1日：“有幸成为Windows
的主宰者”177
你还有别的要求吗178
准备轮船178
设置路线179
启航179
导航180
责任181
下一代Windows181
2006年12月1日：“A公司：严重的威胁
还是糟糕的拼写？”182
他们步伐踉跄，我们手舞足蹈182
注定要失败183
聪明人需要智能客户端183
保持警惕184
一马当先184
2007年4月1日：“中年危机”185
你已经变了185

日子照过，只不过要掌握一点窍门186
不轻易冒险186
我认为他们还不能胜任187
不再年轻了187
不要惊慌失措187
没有人是完美的188
术语表190