代码之道(china-pub 10.22日首发)

【内容简介】

本书以一位微软内部人士的视角，揭示了关于软件编码、软件测试和项目管理中的方方面面问题。作者文笔犀利，见解独到，对软件行业内的很多常见问题提出了解决方案，并提供了最佳实践。本书详细介绍怎样提高软件的质量和价值；切合实际地管理项目的时间表、风险和规范书；为常见的低效率开发瘦身；应用过程改进方法，避免固执盲从；规划一个成功的、令人满意的职业生涯；发展并管理一个欣欣向荣的团队等。
　　本书是作者对过去在软件行业6个不同的公司、28年的工作经验的一次总结。
　　本书不仅是微软内部员工的必读之书，也同样适合于软件行业内其他所有工程师和管理者阅读。

【作译者介绍】

【目录信息】

序
简介
第1章 项目的不当管理
　2001年6月1日：“开发时间表、飞猪和其他幻想”
　　里氏震级估计
　　风险管理
　　客户赢了
　2001年10月1日：“竭尽所能：再论开发时间表”
　　软件工程绝对是含糊的
　　相信一半你看到的，别信你听到的
　　激励：不能光靠比萨和啤酒
　　在日期上沉沦
　2002年5月1日：“我们还开心吗？分诊的乐趣”
　　战争是地狱
　　这不是个人的事情
　　分诊的5条黄金法则
　　魔鬼藏在细节里面
　　很难进行下去，不是吗？
　　谨小慎微
<< 查看详细目录

【前言】

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

你手上拿着的是一本关于最佳实务的书。它会比较乏味。但也许会比较有意义，你能从中得到知识，读后甚至对你产生些许影响，但读起来肯定还是干巴巴而无趣的。为什么这么说呢？

最佳实务的书是乏味的，因为这个“最佳”是跟具体的项目、具体的人、他们的目标以及偏好紧密相关的。一个实务是不是“最佳”，大家可能看法不一。作者必须把实务列举出来让读者自己来选，并分析在什么时候、因为什么原因作出最佳选择。虽然这种做法是现实的、负责任的，但也是令人厌烦的，最终无法取悦读者。为释疑而设计的案例研究会使文字有味一些，但作者仍必须.. << 查看前言

【序言】

序

长期以来，我一直在阅读Eric Brechner以I. M. Wright为笔名撰写的栏目。当我第一次见到作者本人的时候，我费了好大的劲才让自己相信，我是在跟同一个人说话。Wright先生非常地自以为是，然而站在我面前说话的人却那么谦虚、彬彬有礼、非常友好，他看起来更像Clark Kent。（译者注：Clark Kent是“超人”的名字，他具有超强的本领，是一个虚构的超级英雄，美国漫画中的经典人物。）

我很关注微软内部团队在软件开发的过程中，他们是如何去处理技术与人际交流之间的关系的；这类栏目总是我的最爱。看到大量的公司内幕被写了出来，我常常会感到吃惊——我不知道还有多少不为人知的故事没有说出.. << 查看序言

【媒体评论】

专家评价：
“我能肯定，I. M. Wright不会听我的话，试都不用试。”.
——Jon DeVaan，微软公司高级副总裁
“尽管我绝不会从这家伙手里买二手车，但在软件开发方面，他确实也对他自己的东西知道得一清二楚。”
——Ian Ellison-Taylor，微软公司工程部总经理
“微软公司内部所有工程师的必读之书。”
——Peter Isensee，微软公司开发经理
揭示关于编码、测试和项目管理的残酷现实——一位微软的内部人士如实地向你述说。I. M. Wright的“Hard Code”故意煽情，几年来在微软内部成千上万的工程师之间引起了激烈的争论。现在（也顾不上“家丑不外扬”了），我们把他的观点向所有人公开。

本书收录了49个栏目。Eric Brechner重拳出击，对最令他苦恼的问题提出了最佳实践的解决方案，另外还加上了他坦诚的注解。他解剖了开发过程，审查了棘手的团队问题，批判了软件业务的运转方式——自始至终充斥着机灵的幽默和讥讽的风趣。他的想法并不总是很受欢迎（他也不关心那个），但它们的的确确激发起了人们的讨论和想象，推动着软件相关的活动走向卓越。

读者评价：
读者对I. M. Wright’s “Hard Code”栏目的喝彩
任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话，最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向，但它对于需要不断创新才能繁荣的技术公司来说，却是个致命杀手。Eric Brechner做了件难以置信的事——他亮出了手术刀，深深地切入了组织内部看似无关紧要的东西。他毫不吝啬地打出了重拳——偶尔也会故意玷污自己的名声。尽管有一些隐语和例子对于微软内部的员工更有吸引力，但他的智慧和至理名言，大都可以成为整个软件行业的财富。
——Clemens Szyperski，首要架构师
“I. M. Wright”写的关于开发时间表的文章真的是太棒了！它在我所属部门参与的基础设施项目上同样适用。
——Ian Puttergill，部门经理
你没有受到任何死亡威胁，是吗？..
——Tracey Meltzer，高级测试主管
这一定是个笑话——很坦率地说，这类纯粹的谬论危机四伏。
——Chad Dellinger，企业架构师
Eric是我本人崇拜的英雄——很大程度上是因为他长期以来一直代表着开发社区的一种声音。
——Chad Dellinger，企业架构师
软件工程师很容易就会迷失在他们的代码中，甚至更糟糕的是，他们迷失在过程中。那正是他们迫切需要Eric在“Hard Code”中提出的实用建议的时候。
——David Greenspoon，总经理
我刚刚读完这个月的栏目……我不得不指出，这是我第一次认为你正在推行一个对公司完全错误并且带有灾难性的想法。
——David Greenspoon，总经理
Eric你真了不起? 几个月之前，我跟我的产品单元经理和一些开发主管恰恰进行过这样的一次对话。
——Scott Cottrille，首要开发经理
我真的很喜欢这些栏目。它们是如此实用，而且还很全面！我喜欢它们的另外一个原因是，当我在指导初级开发人员的时候，我可以把这些栏目推荐给他们；他们也会记住这些栏目，因为它们都是那么地有趣。
——Malia Ansberry，高级软件工程师
Eric，干得好！我觉得你在这个栏目中说得非常中肯。我想，该给管理者传递这样的信息，“不要害怕试验。”事情的真实情况跟理想化的理论之间差别是非常大的。
——Bob Fries，合作伙伴开发经理
我只是想让你知道我有多喜欢你写的文字——它们充满智慧、见解深刻，你还神奇地把本来很严肃的问题变得如此有趣（采用的方法很不错）。
——Niels Hilmar Madsen，开发者传教士
你那篇关于死亡行军的栏目来的正是时候。我们正打算在未来几周内开会讨论功能削减的事情呢！那些我们以前付出很大代价才学到的教训，不知怎么回事，总是轻易就被忘记了；你的栏目对大家起到了很好的提醒作用。
——Bruce Morgan，首要开发经理
我想让你知道的是，我真的很喜欢并感谢你在EE站点上发表的所有文章。不过，直到今天，当我读了“停止写规范书”这个栏目之后，我不得不说，我强烈不同意你的观点。
——Cheng Wei，项目经理
你到底是谁？你跟Eric Brechner都做了些什么？
——Olof Hellman，软件工程师
Eric，我刚刚读完你写的那篇叫“不恰当的比较”的文章。你不知道我有多感激你！你实际上把这个观点传达给了公司里面成千上万的人……你致力于正确领导和管理团队，并把其中的奥秘跟大家分享，对于你的这种热情我真的非常欣赏！
——Teresa Horgan，商务项目经理...

【书摘】

第1章　项目的不当管理
　　本章内容：
　 2001年6月1日：“开发时间表、飞猪和其他幻想”
　2001年10月1日：“竭尽所能：再论开发时间表”
　 2002年5月1日：“我们还开心吗？分诊的乐趣”
　2004年12月1日：“向死亡进军”
　 2005年10月1日：“揭露真相”
　我的第一个栏目是在2001年6月刊的微软内部网络杂志《Interface》上发表的。为了进入I.M.Wright的人物角色，我需要一个真正能让我伤脑筋的主题。而工作的时间安排和进度跟踪再好不过了。
　 项目管理的伟大神话至今都让我疯狂，它的威力远胜过其他任何主题。这些神话是：
　1.人们能够按期交付被要求实现的功能（事实上，项目可以按期交付，但人们按期交付功能的概率不会高于击中曲棍球的概率）。
　 2.有经验的人估计日期比较准（事实上，他们能够较好地估计工作，但不是日期）
　3.人们必须按照项目预定的日期按时交付项目（事实上，因为人们不能按期交付被要求实现的功能，而你若想你的项目能够按期交付的话，你必须进行管理风险、范围和通过沟通来减轻人性的弱点可能给项目带来的负面影响）。
在本章中，I.M.Wright讨论了如何通过管理风险、范围和进行沟通，来保障你的项目能够按时完成。前两个栏目专门讨论开发工作的时间安排，接着讨论善后事宜的管理（我们称之为“Bu9分诊”），最后是一篇对死亡行军的声讨，以及一个关于人们为什么要撒谎的哲学栏目。
不得不提的是：通过我在微软多年的工作经历，以及对我所在组织的观察，我发现，项目管理行为和方法在不同规模和抽象层次的组织中，其表现大不相同。这些层次包括：团队或功能层次（10人左右），项目层次（50～5000人，他们一起致力于某个特定的产品发布），以及产品层次（由高层人员主管的多次产品发布）。敏捷方法在团队这个层次能够很好地发挥作用，组织方法在项目这个层次比较适用，而长远的战略规划方法在产品这个层次功效显著。然而，一个人几乎不可能同时在多个层次上工作。时间长河为每个人将这些经历错开了。当一个人从一个层次转到另一个层次工作的时候，他可能会想，在以前那个层次上有效的方法在其他层次上应该也同样有效。灾难就这么产生了！原因很简单：小型、紧凑的群体跟大型、松散的机构在运转方式上是不同的。因此要因地制宜，选择最适合的方法。
　　　　　　　　　　　　　　 ——Eric
　　2001年6月1日：“开发时间表、飞猪和其他幻想”
一匹马走进酒吧，说道：“我能在两天内完成那个功能。”开发成本计算和时问安排是个玩笑。相信它的人，要么是傻瓜，要么是初出茅庐的项目经理。这不是模糊科学，纯粹是杜撰。不错，的确有人相信编码可以被分割成一个可预见进度和质量的可重复的过程，那我儿子至今还相信牙仙子呢！事实上，除非你只需编写10行那么长的代码，或者代码可以直接从以前的工作中复制过来，否则你不可能知道编码会花费你多久时间。
　　作者注：项目经理（Program Manager，PM）有很多职责，其中最主要的是负责说明最终用户体验和跟踪项目的整体进度。这种角色是必要的，但他们常常不讨开发者的喜欢，因而也很少得到开发者的尊重。真遗憾，项目经理是一份很难做好的工作。但是，对于Wright先生来说，做好项目经理仍然是一个有趣并且容易达到的目标。
　　里氏震级估计
当然，你可以估计，但估计出来的时间是成对数比例的。有些事情需要花费几个月，有些事情需要几周，有些需要几天，有些需要几个小时，有些则只需几分钟。而我跟我的部门项目经理（Group Program Manager，GPM）一起给一个项目做时间安排时，我们对每个功能使用“困难／中等／容易”3个等级来评估。“困难”意味着一个全职开发人员需要花费整个里程碑时间；“中等”意味着一个全职开发人员需要花费2～3周时间；“容易”意味着一个全职开发人员需要花费2～3天时间。这里没有中间等级，也不做精确的时间表。为什么呢？因为我们俩知道，我们已经不可能知道得再精确了。
在我的记忆里，除了一系列里程碑、测试版、正式版发布等“项目日期”外，我没有在开发时间表上为各个功能规定交付日期。一个好的开发时间表应该是这样的——它只是简单地列出在每个里程碑期间需要实现的功能。那些“必须有”的功能放在第一个里程碑内，并且标上开发人员的数量和“困难／中等／容易”等级；“最好有”的功能放在第二个里程碑内；“希望有”的功能放在第三个里程碑内。除此之外的所有功能统统不做。通常情况下，如果到了第三个里程碑内的第二周，你仍然有较多“最好有”、“希望有”的功能没有实现，这时候大家都很惶恐，你就要把所有“希望有”的功能扔掉，并且将“最好有”的功能也只保留一半。
　　作者注：里程碑的设定因团队而异，也因产品而异。典型情况下，一个里程碑跨越6～12周不等。它们被认为是“项目日期”，是组织（50-5000人）用于同步工作和复审项目计划的时间点。在里程碑期问，各个团队（3-10人）可能使用他们自己的方法来跟踪具体的工作，比如简单的工作条款清单或bum-down图。
　　风险管理
这才是我要引出的主题。开发成本计算和时间安排不能只盯着日期或时间不放，而应该关注的是风险管理。我们通过软件的功能和特性来取悦客户，而不管这个软件产品是零售包还是网络服务。这里的风险是，我们否能在合适的时间、将包含必要的功能集合、并且达到一定质量要求的软件产品交付到客户手中。
　 一个好的开发时间表通过优先处理关键功能来管理风险。这些关键功能是能让客户满意的最小功能集合。通过“困难／中等／容易”这种评级方法，可以判断出在这个最小集合中包含哪些功能才是切实可行的。其他功能按照优先顺序和一致性原则依次加入。
然后你开始编写代码，并且选择功能实现从困难转向容易，或者从容易转向困难。你通过平衡资源，以降低不能按时交付高质量的“必须有”的功能的风险。其他都是次要的，有则锦上添花，没有也无妨，况且你还可以设立不重要、但又不失挑战性的项目交给实习生去做。
　　作者注：具有讽刺意味的是，几乎所有工程师和经理都赞同要优先处理“必须有”的功能，但事实上很少有人真的这么做，因为“必须有”的功能通常是乏味的，比如安装、建造、向后兼容性、性能和测试套件等。然而没有这些功能，你的产品根本就发布不了。
　　因此，产品发布往往是因为这些领域的问题一拖再拖。
一定要破除“功能交付日期”的神话，因为开发人员专注于这种日期的时候会破坏风险管理。真正要关心的日期只能是“项目日期”，比如各个里程碑、测试版发布等，而绝不应该是“功能交付日期”。项目日期之间一般都有较长时间的间隔，而且不会很多。管理这几个日期要容易得多。如果要求开发人员在某个日期之前一定要实现某个功能，当他们不能按时完成时他们往往不会告诉你，而是对你说“我正在加紧做……我会加班……”之类的话。
在软件开发过程中进行风险管理，我们还要特别注意以下几个因素：一个是过度劳累的员工，一个是匆匆忙忙实现的、质量很差的功能，再一个就是你花费几周的时间、动用2～3位甚至更多的高级开发人员去解决一个棘手的问题。如果你的开发人员是在围绕“功能交付日期”付出大量的努力，而不是帮助你在产品的关键功能上实现降低风险，那么那些时间真的就被浪费了。
　　客户赢了
一个产品的成功与否，取决于你对关键功能的风险管理能力。当你给开发团队解释清楚这一点之后，情况就完全不一样了。当然，额外的功能可以锦上添花，但最关键的还是要专注于存在风险的领域，充分沟通，并一起努力把它们解决掉。
当所有人都理解了目标，所有人都能比以前工作得更好。每个艰巨任务的完成都能鼓舞士气，即使新员工也会因为成熟的决议而得到回报。最终，我们的客户是大赢家，因为他们得到了真正想要的功能，并且产品质量也是他们当初所期望的，而不是一些勉强实现的、质量不能保证的垃圾。
顺便提一句，我对开发时间安排的所有论述，对于测试时间安排同样适用。
　　2001年10月1日：“竭尽所能：再论开发时间表”
该对我6月份的那个栏目（“开发时间表、飞猪和其他幻想”）的评论做出一些回应了。其实，大部分评论都是恭维之词，这里就不再赘述，因为没有必要再次证明我有多么正确。我这里要做的是，去帮助一下那些对那个栏目还在无知中徘徊、但又非常热情的读者朋友们。
　　软件工程绝对是含糊的
我对关于不能也不应该对一个功能的开发做时间安排的论断表示怀疑。文中的论述精确地描绘了“编码”活动。不幸的是，这是初中生干的事情，类似于他们拼凑一个VB程序来解密信息、相互通信。我们可是软件工程师啊，不是电脑苦工。
　　——一个充满怀疑的无知者
　　作者注：这是我仅有的一个“邮件箱”栏目，收集了我对一些读者来信的回复。我还在持续不断地收到读者对我的栏目的大量“反馈”，但一旦一个栏目很受欢迎，很多新的话题便会涌现出来；讨论那些新话题的价值要远远超过对一个老话题邮件的回复。不管怎么样，当我回顾这个早期的栏目时，我意识到，可能Wright先生应该再次清空他的邮件箱了。
我经常听到这种说法，但请就此打住。银行经理并不管理银行，软件工程师也不在软件上做工程。他们开发软件，定制软件，通常随意性很大，对所谓的操作范围、公差、故障率、压力条件等没有明确的度量标准。的确，我们的系统有这些标准，但这些标准不是为软件编码准备的。
　 我曾到一个工程学校进修过。我的朋友当中也有很多是电力、基建、航空、机械等方面的工程师。工程师做的项目，其建造模块和建筑流程都经过了很好的定义和提炼，而且都是可预测的。虽然有时候为了达到客户的要求需要一个优雅的设计，像写小说一样把各个模块创造性地组合在一起，但最标新立异的建筑也会符合一定的公差要求，并且具有严格的可控质量和功能。
　 但对软件开发来说，情况就不一样了，尽管很多人竭力想让这两者达成一致。软件的各个构造模块太底层了，变数太多。它们之间的交互影响太难预料了。像Windows、Office、Visual Studio、MSN等大型软件系统的复杂度，已经远远超过了工程的正常范围，以至于哪怕只在这些系统中做微小的功能改动，也无法粗略估计出这些改动所引起的“平均失效时间”。
因此无论好坏，还是抛开痴心妄想和崇高理想，回到现实中来吧！我们必须承认，我们是开发者，而不是工程师。我们不能奢望轻易得到传统的工程领域积累了成百上千、甚至成千上万年的经验才能做到的“可预测性”。这无异于我们奢望：不跟电脑说什么，而电脑却能按照我们心里的想法去做事。我们还办不到！
　　作者注：在我写下这个栏目6年后的今天，微软已经对其很多软件进行了“平均失效时间”的评估。除此之外，把编程当作工程看待的各种方法也逐渐出现了。这个我会在第5章的“软件发展之路”栏目中再次介绍。纵然如此，我仍然认为本栏目很好地见证了软件开发作为一个领域，他已经走过了幼年，但跟他早已长大成人的传统工程兄弟相比，他还只是个10几岁的小朋友的现状。
　　相信一半你看到的，别信你听到的
如果我在某个功能或者一段代码上依赖于另外一个团队或产品组，我肯定不想听到像
　　“你要的东西应该可以在这个里程碑内完成”这样的说法。我需要一个很具体的交付日期。
　　——一个需要日期的人
　 我想写几个关于依赖关系和组件团队的栏目，也许将来会吧，但眼下我只想讨论依赖方的开发时间表。首先，假设你的依赖方确实有一份开发时间表，你会相信它吗？你也许会说：“当然要信，我有其他选择吗？”建议在你的溃疡恶化之前赶紧吃一点Pepcid（一种胃酸抑制剂）。不光只是开发时间表，不要相信依赖方所说的任何事情。如果他们坐在隔壁房间，他们告诉你外面正在下雨，你首先要做的是到自己的窗口去看一下。
但我并不是说你不能同依赖方合作。相反，你可以同他们合作，因为依赖方可能给你的团队、产品和客户带来大量的经验和意外的收获。我只是告诫你要高度警惕当前正在发生的事情。要向他们提出定期多次交付的要求，并对交付的东西进行自动化测试。获取他们对RAID（Redundant Aarry of independent Disk，独立冗余磁盘阵列）进行读和写的RDQ，观察它们的数量以及存在问题的地方。派你的项目经理去参加他们的分诊会议。熟悉他们的E.mail别名。
　　作者注：查一下本书最后的“术语表”，以便理解这些用于Bug跟踪的词汇。
基本上，你需要像鹰一样盯着依赖方。他们是你的团队和产品的一个扩充。你跟他们接触、沟通得越多，你在规避他们的短处以及促进他们改变方面的能力就越强。至于他们承诺的功能什么时候能够完成，你必须依赖你在如下3个方面上的影响力：提高优先级；沟通渠道；接收测试（为了知道他们的功能是否真正可用了）。
　　激励：不能光靠比萨和啤酒
总的来说，你的观点用在项目早期的计划上还行，但对于产品发布前的最后一个里程碑就不那么合适了。时间表怎样提供最后期限和时间约束，让团队遵照执行，使得它能作为一种日常管理工具去驱动团队的绩效？你必须要解决诸如之类的问题。
——一个找不到（汽车）油门的人
首先我要重申：如果你坚持让开发人员遵从“功能交付日期”，那他们为了准时交付可能会撒谎。他们会隐瞒自己的工作状态，会在质量和完成度上给你虚假信息。如果你不想你的开发团队这么对你的话，你必须建立起一个更好的激励机制。我已经实践了3种不同的方法；如果把它们配合使用，效果更佳！
第一种，也是最基本的方法，就是应用里氏震级估计。我的开发人员知道，我期望的是每个功能在大致那么多的时间内完成。如果一个原先估计需要2周的任务实际上花了2周半，可能关系不大。但如果花的时间比原先估计的要长得多，那么通常是有实实在在的原因的，那个开发人员必然会让我知道这个原因。缺乏充分的理由去延期交付，足以对开发人员形成一种鞭策。然而，因为没有卡得很死的日期，大家几乎不会去想到隐瞒和欺骗。
第二种激励工具是瞄准里程碑日期。这有招致大家走捷径的危险，但总体的效果是鼓励开发人员从一开始就努力工作，并且让他们对自己是否落后于进度做到心里有数。“功能交付日期”和里程碑日期关键的不同在于，后者是给整个团队设置的日期，需要整个团队一起努力去达到它。因此，个人抄近路的压力就会小很多。然而，这种危险性仍然无法杜绝，逼得我使出最后、也是最有效的一招。
　　作者注：一个自我导向的团队向着一个清晰的共同目标一起努力，这是很多敏捷方法的核心概念，尽管在2001年我还不知道有敏捷方法。
最后一种激励工具是迄今为止我使用起来最有效的。我向团队解释清楚哪些功能是必须要有的，它们必须优先被完成。我告诉他们，必要时任何其他的功能都可能被放弃不做。不幸的是，这些必须要有的功能常常做起来比较乏味，没有意思，甚至不值得一提。因此我告诉我的团队，如果他们想要做那些很酷的功能，必须首先保质保量地完成之前的这些关键功能。在这个前提下，他们才会被鼓励去做那些不那么关键、却要炫得多的东西。这种激励是积极的、有建设性的，并且非常地有效。屡试不爽！
　　在日期上沉沦
继续前面的讨论：时间表在不同的功能单位之间（不只是开发，还有项目管理、测试、用户体验、市场、外部合作伙伴）同步工作时，绝对是必要的；你还必须要解决这个问题。
——一个没有对齐的脑袋
如果你确实需要具体的“功能交付日期”来同步各个工种和依赖方的工作，那么你的软件永远也没法出货。当然，我们的软件一直在出货——我们甚至准时发布了庞大的Office XP。要知道，它的发布日期是在两年之前计划的。因此，肯定存在其他的一些关键因素。
其实真正起决定作用的，是要在顺序、成本和方法上达成一致，并且提供及时的状态报告。各个工种之间要协商达成协议，定义好状态汇报的流程，并且避免工作的相互牵制。
·顺序：对于功能实现的先后顺序的协商已经不是什么新鲜事了，尽管有些部门从来都不能对优先顺序达成一致。
·成本：成本的协商通常发生在开发人员和项目经理之间。（比方说一个开发人员说：“如果我们使用标准控件，可以帮你节省2周的时间。”）但有时候就只是开发人员做决定。其实，成本的协商也应该让测试和实施人员参与进来。
　　·方法：对所使用的方法的协商通常在项目管理规范书中做，但很少在开发和测试的规范书中做——这对他们不利。
　　·状态汇报：至于状态的及时汇报，你务必要把邮件和“测试发布文档”（TRD，Test Release Document）登记起来，或者两者任选其一，以便让项目经理、测试和实施人员了解项目的进展情况。测试部门需要对阻碍工作继续进行的Bug使用警报。项目经理采用类似于“规范书变更请求”（Spec Change Request，SCR）的方式来汇报规范书的更改。（了解更多的关于SCR的内容，请阅读第3章的“迟到的规范书：生活现实或先天不足”栏日）
如果各个不同的部门能够对他们的工作顺序进行合理的安排，知道各自的工作需要花费多少时间，对他们使用的方法也很有信心，并且保持着最新的状态报告，那么项目就上轨道了！问题找到了，风险降低了，意外也很少发生。更重要的是，没人有压力去为了几个人为的交付日期而犯错。相反，每个人都朝着同一个目标在努力——为我们的客户交付一个令人愉快的体验。
　　……

【免费试读】

　电子书Web试读版：试读本书　全部品种