项目行为模式

模式1.玩的就是心跳

组织相信忙乱的工作象征着高效的生产率。
这类组织的特点：优先级总是变化不休。人不会从战略层次上思考问题，只是按照紧迫程度来完成工作。这种组织认为紧迫性越高的项目，绩效也越高。绝大部分“玩的就是心跳”型组织至少存在一个瓶颈，就是那位英雄。错误地认为对紧迫事件的响应是值得赞赏的响应。断然行动使得大部分工作都处在不断变化、无法固定的状态。他们不太可能构建重大的东西（那需要稳定性和计划）。

模式2.快，赶上

当项目团队决定谁在何时该做什么事情时，呈现出明显的紧迫感，并迫不及待地想立即采取所有必要的行动。
“立刻行动”不仅是拜技术所赐，内在基础来源于团队的文化。特点：他们对于时间的紧迫性有着内在的直觉；他们对个人和集体的能力非常有信心；他们相信迭代的价值。相反的有“脱口秀”会议，形式：要求完美的信息；对“等一等”的膜拜；未定事项的大浆糊；篝火旁边的轶闻；条条大路通设计；开会安排额外的会议。

模式3.死鱼

自打开工起，项目就完全不可能完成目标，项目团队中的大多数人都很清楚这一点，但却都缄口不言。
狠多组织如此汲汲于成功，以至于任何表达疑惑的人不会因为讲出由衷的意见得到任何奖赏。在这样的环境里面，“努力”而无法完成比站出来指出目标无法达到更安全。

模式4.欢乐的鼓掌会议

是否表现出高涨的士气成为个人绩效的评价因素。
最常见的举措是仪式性会议，老板笑容可掬，“让我听听你们的心底话”，大度的告诉大家“任何事情都行，坏的消息和尖锐的问题也可以”，注意这里的强调和背后传达的消息，一旦理解到老板并不是在征求你们的发言，而只是征求你们的同意时，你就能清楚地知道要上演什么好戏了，欢迎参加欢乐的鼓掌会议。

模式5.保姆型项目经理

项目经理拥有的技能与传统的英式保姆有很多共同之处。
一个类似保姆的经理会把自己看做是工作的催化剂，工作满意度来自于看到每个团队成员在个人角色方面得到发展、生产率提高，并对自己的工作更加满意。这个模式的反模式有：经理把工作重心放在员工内部的明争暗斗上面，放在行政管理上面，放在流程上面，抑或放在逢迎更上层领导上面；还有一些经理承担了太多的实际开发工作，而不是去解决好团队的需求。

模式6.牵涉性疼痛

项目治愈了外部的病状，却没有根治内部的病因。
在项目立项的时候，人们往往会解决显示的问题，但是，如果只盯住牵涉性疼痛，项目交付的产品会造成极大的浪费，因为它对于解决真正的需求几乎没有任何的帮助。为何只解决牵涉性疼痛而不是病源？一个普遍的原因是不愿意去做调查研究，有时是因为组织的文化，有时是因为项目需要立即着手进行。我们可能倚重自己所具备的技术，用于我们所熟知的解决方案最契合的方式来看待问题，此外我们可能更喜欢解决最吸引人、能够产生最炫产品的问题。我们都急于针对明显或者明了的问题找出独创性的解决方案，但技术能力却用错了方向，不能带来正确的结果。是否在处理牵涉性疼痛，一个强烈的信号是临时补丁，这种“创口贴”看上去比外科手术更便宜、更划算。很多问题的根本原因都是细微的，而且通常与表面的症状一点也不相干。但是集中精力研究真正的需求，解决真正的问题，总是能事半功倍。

模式7.明日复明日

每个人都有时间窗，提醒自己立即采取行动并持之以恒，直至工作完成。逾出时间窗的交付日期不会导致任何紧迫感，因此也就产生不了行动的动力。
紧迫感是实际行动的重要催化剂。逾出时间窗的日子都是“明日”：意识到自己需要负责完成工作，但却没有意识到如果期望成功，自己就必须从现在开始。解决办法是：把时间很长的任务转化成短期任务（通常在30天以内），这样真实的终点线如同就在眼前。每个时间窗都必须产生真正的交付物，只有进度是远远不够的。警惕另一种变体：耗费大量的时间来准备开始。

模式8.眼神交流

当任务紧迫而且复杂的时候，组织往往会把项目成员安置在一起工作。
之所以分散工作应该是因为缺乏人才和技能，而非金钱和资源短缺。工作越紧急，团队成员就越有必要在一起。当所有全职的成员在同一个屋檐下工作时，他们了解彼此的需要和能力，随着了解的增多，他们会调整自己的行为方式，以获得最佳的整合效果。类似的，在开发团队里面有一些关键的信息交流对于紧密的合作也非常重要，其中最重要的是信任的给予和获取。中间如果横着距离，双方很难相互信任。在忽略一地协同工作优势的组织里，分布式团队无坚不摧的神话早已根植管理层的思想深处，任何人，不管身处何方，只要在项目开始的时候可以派遣，就自然而然成为新项目团队的候选成员，在这样的环境下面，团队只是挂着“团队”的名号而已。

模式9.情绪戒指管理

经理不是基于项目面前的风险、决策和问题来汇报项目状态，而是基于团队的活动、付出和热情。
听听项目经理如何谈论他们的工作，特别是他们如何交流各自项目的状态，这往往在一定程度上反映出他们管理项目的方式。乐观的、带一点点情绪化的经理，他们的报告并没有完全达成最基本的目的，没有把我们的注意力集中到那些最需要立即采取纠正举措的内容上，因为描述的方式，我们获得的只是从几个方面对工作整体的定型评价，根本没有对任何问题进行清晰的定量分析，同时仅仅关注开放结论式的、目前进行中的行动，常常对他们努力追求的最终结果没有清楚的认识，他们只是尽可能快地一步一步低头赶路。

模式10.忠实信徒

个体把某种思想派系作为真理来膜拜，与圣典稍有偏差即被认为是亵渎神灵。
项目上的忠实信徒会让工作止步不前，他们不去专注于内容，反而为方法争执不休。

模式11.出租灵魂

从业者愿意放弃长期练就的技能或者技术。
称职的专业人士有一项令人钦佩的地方，在于能够根据待解决问题的实际情况来裁剪解决方案，而不是把问题往个人或者团队4检验的技能上生搬硬套。虽然他们并非追赶最新技术潮流的狂热分子，但他们也愿意放弃现在熟练于心的工作方式，去考虑其他真正的先进技术的优势。他们的态度是着眼未来，而非从现实中寻求安慰。能够把问题本身跟解决方案区分开来是成为灵魂出租者的第一步，第二步则是要弄明白无论技术多优秀，明天总会有更优秀的出现。

模式12.系统开发旅鼠周期

虽然组织流程很明显地需要进行定制，但项目团队依旧盲从于未定制的标准。
团队出于保险起见而不漏过每个细节，把所有建议的章节和段落都事无巨细地加进规范里面。缺乏勇气并不是放弃定制的唯一原因，通常定制流程去匹配项目的实际约束需要做更多的工作。如果流程很少照顾到项目的实际需要，照搬流程也许能让项目早点开工，但却无法早点完工。项目经理不定制流程，就像厨师严格遵循菜谱来烧菜，不会成为一个好的主厨。

模式13.清空“板凳”

组织变得如此精简，以至于失去任何一个关键人物都会演变成一场灾难。
很自然的，你早已悄悄预备下了一个或两个替身。没有这些人员储备的原因是他们得花钱。这种逻辑的问题在于它只考虑了金钱，一点也没有考虑时间。在大多数开发项目中，时间是一项比金钱更稀缺的资源。留有一些“板凳成员”，在关键人物离开的时候，可能就是一种拿金钱换取时间的方法。

模式14.面对面

分布式团队通过各地之间大量的面对面交流机会，以建立使远距离团队合作成为可能的熟悉感和可靠感。
可能仅仅因为协作技术的提升，分布式开发迅速盛行。精心地为团队成员提供至少偶尔聚在一起的机会，如果面对面交流不够充分，在一个地点的团队往往会以高傲的态度对待位于其他地点的团队。多大程度上的面对面交流才足够？：在几个地点之间负责协调工作的人需要最频繁的交流；对于开发人员、QA工程师和技术文档作者，他们之中的资深人员在每次发布周期里面至少需要与其他地点的同行碰头一次；偶尔允许初级的团队成员前往其他地点。要想分布式开发获得成功，必须增加出差预算。

模式15.我给了你凿子，可你为什么不是米开朗基罗

经理购买工具，潜意识里希望它们可以赐予团队技能。
一些经理承担了交付的压力，而他们却几乎没有人手来做到这一点。自动工具有时看上去就像是一条救生绳。在某一个绝望的时刻，工具购买者忽视了工具用户必须具备适当技能的观念。

模式16.主面板

强团队和弱团队都在使用主面板（Dashboard），但普通团队则不然。
通过色彩搭配和简单设计，主面板展示项目或者业务流程各个方面的健康情况，但他们也可能沦为彻头彻尾浪费时间的累赘，这些都与主面板本身无关，而是取决于使用主面板的组织的文化。弱团队使用主面板以责备其他人或者转移其他人的责备，他们的迹象：红色以为着失败；橙色其实是不愿承认的红色；绿色是站在遥远的地方看项目。这些反映了团队的前进动力并非源于对成功一腔热情，而是对批评心有余悸。有效的主面板特点：不使用海量数据淹没观众；可编辑、可选择；多一些评价，少一些信息；在反映现实情况之外，还能帮助预估未来；根据时间显示变化趋势；在团队需要汇报主观判断时，能够提供一个比较框架。好的主面板定义建议：绿色，计划正按部就班地进展，而且很可能达到预期目标，不需要打的纠正措施；黄色，需要大量的及（或）立即的纠正措施，以满足之前承诺的日期和其他的预期目标；红色，计划已经无法达成了，要么已经错过计划的日期，要么马上就要错过，除非采取激进措施，或者至少还要重新制定计划。

模式17.无休止的集体会议

允许无休止地争辩，最终肯定无法达成任何一项决定。
最糟糕的后果是挥霍掉了最宝贵的资源（时间）。起源不仅是组织文化，根源在于团队的领导者。避免无休止的争辩需要有一个适合具体项目的决策流程。当人们认为只有经过他们同意才能让他们遵守决定的时候，无休止的争辩就产生了。这是，项目经理应该站出来，建立规范让人们遵守决定，而且让人们认识到，一旦决定作出，就必须无条件接受。

模式18.幼犬和老狗

拥有很多年轻人（20多岁）的组织比充满老员工的组织更富有生气。
他们充满热情，让老员工不敢停下手中的工作而去打个盹，我们也变得“年轻”。最重要的，他们在学习方面起了带头作用。“非常老”的组织有三个原因：组织不再成长，几乎没有机会聘用年轻人；组织只雇用经验丰富的人；组织已全然丧失了冒险精神。

模式19.影评人

影评人是团队成员或者公司内部的旁观者，他们认为自己给项目带来的价值在于指出问题所在或者将会出现问题的地方，却不把解决问题视为自己的职责。
他们的共同特征：他们相信即使自己所处的项目失败了，他们也能成功。并不是所有评论项目的人都是“影评人”，区别在于选择的时机不同，如果对项目的成败负有责任感，一旦发现事情不对就会毫无顾忌地讲出来，及时纠正。产生的原因：有些组织的管理文化只是强调正确地做事情，而有些组织则强调不许出现任何差池。当经理更多地关注于不犯错误，或者错误至少不能被人发现的时候，他们就向外界传播了明显的信号，对于组织而言，发现别人犯错与正确地做事同等重要。做一名“影评人”比作“制片人”要容易得多。对组织而言，这些人的努力是微不足道的，甚至是适得其反的。

模式20.单一问责

项目的每件任务都清晰地反射到仅仅承担单一职责的个体身上。每个人都十分清楚自己承担的职责，以及自己同事承担的职责。
人们因为承担职责并且清楚职责内容而兴奋。这种模式的组织如果遇上了未能预知的事情，即使没有一个人对此有责任，也能游刃有余。承担单一职责并不是拒绝寻求帮助，也不是拒绝从同事或者其他相关人员那里获得关键性的投入，关键自傲与指定的人员对约定好的基本元素负责。这与授予工作头衔是不一样的。一些项目的运作原则是每一件事的责任都由所有人共同承担，表面看起来值得赞叹，但这种方法很少奏效。进行单一问责，源于这样一种自信，即人们清楚地认识到其他人对自己的期望，同时你要能够定义基本元素的特征（基本元素也许是软件的某个特定模块），被标示出来，以便每个人都能对它有相同的理解。

模式21.英式风格

交付的产品包含了客户要求的功能，但却不受客户待见，很快就被搁置一边了。
苏式风格的产品——他们多多少少实现了功能意图，但却让你觉得笨拙不堪。可用性无从谈起，在非功能性需要上败下阵来。如何避免：保证你的项目计划中明确包含了非功能性需要，除了持续关注之外，尽量使用早期项目原型以得到有价值的反馈。

模式22.自然权利

能力吸引权利。
做决策的权利应该与能力相配。与该模式相反的：决策的制定遵循组织结构，而不是遵循知识和技巧，身居更高职位的人负责做出大部分决策，有时甚至不咨询那些对问题有更深刻理解的人。这样的后果：除非被特别要求，否则他们不会提出任何建议，这是对责任的放弃，因为沉默即同意。

模式23.万籁俱寂的办公室

办公室太安静了，凸显出团队已经失去了活力源泉。

模式24.白线

项目团队借用网球场上的“白线”，来界定需求的范围。
很多项目都没有白线，人们试图借助于特性列表或者目标声明来区分哪些需求属于系统范围之内，哪些需求则不属于，然后这样的白线并不实用。特性列表上的任何一个特性固然要完成，但却不一定要完整地纳入需求范围已定的系统里面（它在部分上或者整体上可能破坏了系统的完整性）。通过声明（更准确地说，建模）每一个跨越系统边界的数据项集合，你其实是在强调“边界这一边生产数据，而边界另一边则使用数据”，从另一个角度看，你是在通过声明需要修改的系统/业务领域与直接交互的外部世界之间的每个接口来定义项目范围，一旦该工作完成，系统范围就将不再有任何的歧义，你已经借助于接口绘出了白线。

模式25.沉默即同意

利害相干人无法区分屈服的沉默和同意。
承诺被误解的情形通常是：一方表达了需求，然后另一方点头示意明白，前者把这种情形理解成一项承诺。这对每个人都不利，双方不可避免地给工作定义出不同的优先级。如果过度的承诺，新需求就以惊人的速度接连不断。要使隐式承诺更易于管理，一个行之有效的方法是公开声明少量的重要承诺，把它们写下来，然后共享给所有的相关人士。承诺书没有必要，短短的承诺列表即可。

模式26.稻草人

团队成员很乐于提供“稻草人”解决方案以获得早期的反馈和认识。
最好的分析师从来不会试图去分析了客户的所有问题后，再拿出解决方案。他们分析得出一些理解，对解决方案的整体或者部分做出最小的投入，然后把解决方案快速交给客户，寻求客户的反馈。稻草人模型是一种需求钓饵。人们讨厌对着一张白纸创造答案，但乐意于批评纸上已经存在的答案。最好的稻草人模型可能甚至包括一些有意为之的错误。以保持客户的警惕性，同时释放一种信号——针对模型畅所欲言的批评都会被接受。能够把“做蠢事”作为高级方法，以加快收敛到一个具体的解决方案，这是最高境界。哲学上是早早犯错、频繁犯错，这样你将会尽快地得到正确的结果。

模式27.伪造的紧急性

仅仅是为了抑制成本，项目的截止期限被强行安排得非常紧张。
识别是否是伪造的紧急性，需要仔细查看项目可能产生的收益，如果收益千真万确、十分可观，那时限太短的计划安排绝对意味着头脑发热的冒险行为，假如果真能得到如此重要的收益，为什么不多分派一些时间认真去做这件事呢？如果收益其实是微不足道的，那么明显冒进的计划只是制约开销的策略。

模式28.时间清除了你的手牌

时间是位拙劣的项目经理。
时间的流逝会彻底错失了添加新人所带来的价值。“时间”的策略就是生产大量接近于完成、但却尚未完成的特性，然而接近于完成不等于完成。

模式29.Lewis与Clark（一个美国历史故事）

项目团队在前期投入精力，探索领域并发掘潜能。
分配一些预算对问题域进行探索，以判定可能发生的情形，以及针对该问题域启动项目的切实可行性。项目团队中的探索者从抽象的角度来开展探索工作，他们不关心谁在处理什么，或者涉及了哪些机器和个人，相反，他们检查各种条件，看能引发什么点子，产生什么机会，以及该工作未来可能是什么情形，他们需求着机会和点子，一旦被证实，将会给探索的发起机构带来最可观的潜在收益。这样的发现是一种红利，它阻止了不必要的项目损耗宝贵的资源。

模式30.短铅笔

连续不断的成本消减开始影响到组织完成任务的能力。
症状：解雇员工，把他们的工作分派给剩余同事；超负荷工作的员工会失去热情，在工作中产生缺陷；薪水高的专业人员越来越把时间花在文案工作上，而这些工作本来是由薪酬较低的员工处理的；一线员工会因为原来照顾他们的经理的离职，相应地变得无所适从；人们可能会因为同伴被解雇而怒气冲冲地离开公司；当长期没有任务，计划一再延期的时候，员工的忠诚度、活力、创造性、士气以及奉献精神都会下降。单一的成本消减计划还可以理解，但是如果将要掀起第二波甚至第三波的浪潮，或许该开始考虑自己个人的幸福了。

模式31.节奏

团队通过定期交付，建立起工作的节奏。
面对艰辛而复杂的任务，拥有节奏的项目团队不是望而却步，而是采取小而有规律的步调，朝着自己的目标发起有规律的冲击。这样的团队，通常仰望着“山顶”，定下项目的目标，然后作为一个团队，他们针对一段可预测的时间（通常一个月），制定交付计划。在那个月里团队成员每天都会聚在一起交流各自的进度、想法以及问题，为接下来的一天做好计划。项目目标、每月目标交付，以及每日反馈会议，给工作建立了一种节奏。节奏的周期长度并不重要，只要人们能够感觉到节奏的存在即可。太长的时间，会使大多数人丧失紧迫感。与没有节奏的项目相比，拥有节奏的项目能更频繁、更快速地交付有用的产品。有了节奏，人们就会习惯于按照一个既定的频率交付东西。即使有一些中间交付物不够完美，光凭项目的节奏就能让团队保持精力充沛和热情高涨。没人期待完美，但是人们都期待交付。

模式32.加班预兆

经理认为，项目早期的加班表明项目的健康状况非常令人满意。
手下的人把额外的空闲时间投入在项目上，有些经理认为自己在团队鼓舞和个人激励方面做得很好，但是，这也有可能源于人们在工作中产生的无望感。如果恐惧文化充斥于组织内部，他的症状有：基于恐惧的管理；惧怕为了消减成本而强行裁员；惧怕个人失败；惧怕项目失败；确信项目会失败，但惧怕个人承受责备。早期以及长期的加班预示了严重的加班情况，把它视为健康的信号就并不是一种明智的做法。

模式33.扑克之夜

来自组织各个部门的雇员聚集在一起，参加与工作角色并无关联的活动。
无论人们何时聚在一起，打破阶层和职务的约束，组织都会变得更健康一些。在活动中，有很多机会进行海阔天空的闲谈，还有很多机会从其他人那里学习。相互熟悉可以使彼此相互信任，也可以使彼此更有耐心。组织内的界线之所以存在，只是为了便于管理和制定决策，往往不是为了加快工作的进度。组织的界线与组织的工作流程通常并不吻合。对于组织中平时不常打交道的人而言，培养他们之间的私人关系对于组织中的重要工作可以起到润滑剂的作用。很多组织试图通过一系列的团队建设活动人为地“润滑”沟通渠道，虽然有时也能奏效，但由于个人不能产生志愿参与的感觉，所以大多数情况下的效果并不明显。只要创造条件让人们碰面、玩得开心，并且能够达到目的就足够了。

模式34.错误的质量关卡

项目中的质量保证工作着眼于格式检查，而这些工作根本不能给真正的产品质量带来任何改善。
在抵达里程碑或者结束迭代之前，很多组织会对项目的产出结果执行规定的质量检查，通常包含：确保预期交付物按照预定的格式完成（关乎语法）；检查各项交付物的内容是否恰当、精确，是否达到目标（关于语义）。如果确实了语义，关心交付物的语法就是舍本逐末。如果你使用了错误的质量关卡，就会发现质检过程传回来的大多数反馈都是关于交付物的形式，而不是交付物的内容含义。该模式把时间浪费在不具备产出性的步骤上面，更严重的是，与内容相关的缺陷却溜进了最后的产品之中。

模式35.测试之前先测试

“测试可不仅仅是测试（而且应该在测试之前进行）。”
把测试活动散步在整个软件生命周期的全过程之中，在测试阶段之前的测试意味着在最开始的项目讨论时期就引入了质量控制，早期测试的关键在于尽可能早地揭晓尽可能多的错误概念、误会、冲突、不现实的期望等（在这些观念变得根深蒂固、积重难返之前）。

模式36.苹果酒屋规则

项目团队成员罔顾或者绕过那些由项目工作无关人士制定的规则。
当遴选流程、方法或者工具变成遴选者唯一的工作职责时，本模式就更为彰显。外部的规则制定者很少是决定项目工作如何进行的最佳人选，他们对工作不是非常熟悉，只会泛泛地制定一些规则，而这些规则不得要领，当出现问题的时候，他的规则则必须是可以帮助他避开批评、推卸责任的。规则制定者眼中的世界和规则遵守者栖息的世界必须得存在耦合的地方。

模式37.说，然后写下来

项目团队在交谈间得出了决定，然后立刻用书面形式记录下来以供交流。
对话是快速达成满意决定的最佳方式，井然有序的对话把所有人的思想集中在一起，在很短的时间里，把众多团队成员的经验智慧汇聚在一起。与缓慢的电子邮件不同，高效的对话是同步的，能让人一直投入其中。用书面方式交流决定，可以为那些没有在场或者忘记细节的人们保存决策制定的对话过程。越大越正式的组织依赖书面，越小型越快速的组织依赖面对面的对话，大家依赖于最契合组织文化的沟通方式。小型公司在制定抉择上面效率很高，但是在有必要‘换挡’的时候却没有意识。大型或者分布式团队里，邮件你来我往，越来越多的人被假如到‘抄送’一栏，那些能够在一两个简短会议上决定的东西争论几天也得不到解决。

模式38.项目中贪多求全

组织经常贪多求全就会放慢速度，最终导致净效益降低。但是那种诱惑可能是无法抵抗的……
组织接受的负载超出了它所能顺利解决的范围，这样做是能讨得有权势人士的欢心。同样的有限资源现在需要放在更多的工作上面，所以完成那些工作的平均速度会更慢。接受超出团队处理范围的工作是管理层怯懦的表现，没有勇气在第一时间说‘不’。想逆转这种恶性循环，就给工作任务排定优先级，制作你最大能力范围之内的事情。政治不是唯一原因，个人也会让自己变得超出负荷，他们也听过‘少即是多’，但在内心认为只有‘多才是多’。

模式39.巨神阿特拉斯

团队领袖（几乎）擅长于一切事情
他做到了你心目中一个领袖能做到的一切事情，唯独没有给团队的其他成员安排任何重要的领导或管理工作，没有把他们作为领导来培养。他虽然划分团队任命小组长，但是任然直接管理到每一个人，在小型团队中有效，却无法领导大型团队。后者他突然离开怎么办。

模式40.所有人都穿着衣服是有原因的

完全公开的政策让进度慢慢停下来、停下来……最终完全停下来。
当吸引注意力的信息量太多时，我们会处在超负荷的状态之中。一个原因是你收到了信息，但又不表示不满，你实际上是同意了全部信息。一个原因是因为害怕自己不知道别人知道的东西。

模式41.同事预审

组织让将来与应聘共事的员工也参与到招聘过程中来。
团队在招聘过程中拥有话语权的时候：当前团队成员大部分已经接受了他；应聘人也可以接触到未来的同事，而不仅仅是老板；经理也可以借鉴整支团队的评价；团队里也可以发现其他人使用的问题和标准，在以后派上用场，经理也能了解团队成员的思维方式。

模式42.浮潜与水肺潜水

不同形式的分析活动贯穿项目的整个生命周期：自上而下、自下而上以及先中间后两边。
在项目或子项目的起始阶段，通过浮潜识别出研究范围、目标、利害相干人、研究边界、已知事实以及需要进一步做水肺潜水的地方。深度潜水的发现常常会改变浮潜阶段所作出的假设。在广度上知晓的越多，就越能识别出高风险与高收益的领域，以及如果辅以进一步的深度研究可能大有裨益的领域。他们对于哪些是自己所知道的、哪些是自己所不知道的、哪些是需要加以探索的以及哪些是可以放在一边的，都心中有数。

模式43.一切都是该死的接口

项目团队成员毫不妥协地强调接口——既在产品里面，也在人与人之间。
洞悉该模式的团队会早早地对付接口，在提交所有的组件代码之前，他们构建了一系列的程序来检验接口。他们早早的集成个人代码，频繁地测试。言警惕项目团队中的接口，防止出现任何一个工作组在任何一个接口上做出不恰当假设的可能性。康威定律（Conway’s Law）：产品反映了制造该产品的组织结构。对于接口，这一点尤为正确：项目中复杂的人类接口容易导致复杂的产品接口。

模式44.蓝色区域

团队至少有一位成员经常性越职。
把项目任务的分派想象成三个权限区域：绿色区域是安排中明确定义的事情，是待完成的核心部分；红色区域是被明确排除在任务范畴之外的事情；蓝色区域则包括了其他所有事，既没有要求也没有禁止的活动。为了获得最佳结果，有的人会处理蓝色区域的事情，设置会说服团队领头人同意他处理红色区域的事情，这样的冒险天性意味着较之原来安排任务之时所预想的结果，他能得到更好又富有创造性的解决方案。绝对的服从可能是有害的，某些善意的无序反而是有益的。

模式45.消息美化

坏消息在组织里面没有准确地向上传达。
最典型的症状是出现意外，延误了一个又一个截止日期。刻意隐瞒坏消息可能使得可解决的问题变成无法解决的问题。最普遍的原因是恐惧，由于不想被视为悲泣者或者懦夫。改进的办法：你得把对坏消息的反应分成两部分：（1）决定如何处理；（2）弄清楚它是怎么发生的。首先关注第一部分，把精力放在督促团队，提出改进计划，然后落实行动，注重富有成效的纠正措施，团队就不会认为是对他们的指责。最后一定要分析问题的根源，但这可以等到事态已经发展良好了再说。

模式46.慢慢地道出事实

公司文化迫使人们把令人不安的消息埋在心底。
原因：他们不希望对自己公布的问题负责；他们对自己将会被问到的后续问题没有答案；他们在等待其他的人揭露更大的问题，好隐瞒自己的问题。

模式47.残局游戏

团队在整个开发过程中定期地使用交付标准检验构建中的产品。
好处：在开发的每个阶段，你的团队都会再一次关注到产品交付的剩余工作；一旦此前已经通过的回归测试失败，你就可以及早得到警报；随着项目的进行，你有大量的机会来改进交付标准；虽然一些交付标准在开发早期很难被检验，但即使是些‘TBD’（待完成事项），也能引发出有意义的问题，比如：“hi，我们什么时候会第一次运行性能测试套件呢”。

模式48.音乐制作人

在IT组织里面，拥有音乐才华的人所占的比例超出在平常群体中的比例，有时甚至还会大很多。
或许源于音乐的数学与逻辑基础性，以及音乐对于技术性思维的人士非常具有吸引力。技术的数字本质与音乐的模拟本质之间的对比可能是非常地奇妙，又抑或只是个巧合。

模式49.记者

记者是指那些把准确报告这个目标与让项目成功这个目标完全分开的项目经理。
正如影评人那样，项目记者坚信，即使项目失败，他们个人也能成功（但愿仅仅是潜意识中里）。不要忽略经理角色之所以存在，是要保证项目有个圆满的结局，保障项目安全、准时‘着陆’正确的目的地。随之而来的准确报告只是达成这些目标的一种手段，但却无法代替这些目标。

模式50.空椅子

没有人为整体用户体验的概念一致性负责。
项目成功需要一个人来关注的是整个项目对于客户而言的最佳结果，一直到最细微的细节。这个人可能没有任何人直接向他汇报，他也几乎肯定不需要为预算或者计划负责。他全部的关注点都只在于产品如何与目标环境交互，特别是与产品的最终用户交互。空椅子在那些需要集成原有系统的项目中甚至更为常见。往往只是集成工作的技术因素在驱动着项目，而业务集成的细节、用户交互的功效因素，以及可能产生突破性创新的想法都被忽略了。

模式51.我的堂兄文尼（美国的一部喜剧片）

团队成员争论不休——群情激昂却了无敌意——去评价和改良他们的主张。
在争辩某项主张的过程中，争锋相对的争论几乎总能导致新想法的产生。争论的关键在于说服别人，而且在这样做的同时，我们也在说服自己，因为你得让自己组织严密、表达清楚、主张合情合理、论据充分。为得到最佳解决方案而争论的团队成员会互相尊重，否则不可有富有成效的进行争论。这种安全感不来自仁慈的管理层，抑或好心的团队领导，而是来自‘其他人是自己的堂兄文尼’的认识，他只是在检验你的主张，并通过与你争论的方式试图改善你的主张。

模式52.特性汤

产品夸耀自己繁多的零碎特性，其中很多对于解决客户真正的业务需求几乎毫无帮助。
随着需求不断添加，产品的特性集不断增多，如何把这些碎片整合在一起以及如何利用它们实现业务目标这些问题上，开始变得盲目起来。情况变得更加汤汁淋漓，因为各个利益相关方都从不同的角度来看待产品的需求，根本不存在共同的、连贯的思路。人们会自然而然地认为自己的需求才是最重要的。当零散的需求来了之后，分析师需要将它们与其影响的业务流程映射起来。向不同的人展示变更需求会对他们的工作产生哪些影响。这样可以获得基本的理解，从而发现人们真正需要的是什么。设计人员在面对新的需求时，也要去追究其与既有产品在整体上有和关联。避开特性汤：尽可能干脆、尽可能早地定义项目目标和非项目目标；声明项目范围，并以精确定义输入/输出数据的形式时刻保持更新；坚决地拒绝那些对声明的目标没有积极效应而又明显超出项目范围的需求；新需求的添加遵照被核准的、可追溯的变更管理流程进行，同时使用项目声明的目标对它们进行评估。

模式53数据质量

数据质量经常会糟糕透顶。遗憾的是，解决这个问题的常见做法是寻求更好的软件来处理数据。
问题就像鼻子长在脸上一样明显，但每个人要看到自己的鼻子却非常困难。即便每个人都看出其他人的数据问题，也很难去直面应对。公司看到的总是软件与数据合在一起的问题，因为软件总是比数据（数据量多得可怕）更易于修复。指出数据可能会被破坏是值得的，至少有一些半自动化的方法能够通过恢复更早的备份版本来抵消造成的破坏。数据质量随着时间推移而逐渐下降的主要原因是变更。

模式54.本

对于有些人而言，工作条件简直太好了，或者项目太有趣，又或者产品太酷，以至于他们对工作的热爱大于对薪水的热爱。
虽然很容易管理（而且令人愉快），但更容易对他管理不当。如果安排的工作负载变得无法承受，他就无法感觉到工作的乐趣，进而选择离开。他不需要密切的监管。引导他去从事他感兴趣的工作。从而保证他这个高度胜任并热爱这个工作的员工以饱满的热忱去完成它。

模式55.礼数小姐

人们认为质疑同一个团队的成员的主张是不礼貌的。
在一些组织里面，任何批评被认为是针对个人的，因为视作是禁忌。这种滥用礼貌的结果就是严重的平庸，工作无法得到真正的改善，无论以何种形式，完全重新开发工作或者推翻重写都是不可能的。错误的‘良好’礼数来源于从组织某个高层传来的明确信息（但从未公开挑明的），这是披着‘礼貌’外衣的一种懦弱的表现。

模式56.全神贯注

在单一的项目上投入全部的时间，可以改进个人的绩效。
被分派到多个并行开展项目上的员工不可能保持最高的智力产出率，因为多任务是要付出代价的，需要消耗一定单位的智力成本。从A项目的上下文切换到B项目，需要耗费一些脑细胞来了解B项目的状态。找齐所有正确的B项目文件，从大脑中消除A项目的思维，重新与从事B项目的其他人建立联系，把之前建立的思路重新建立起来——这些步骤对于大脑重新适应B项目的上下文都是必不可少的。背景切换的确会导致生产率的巨大下降。避免把一个人分派到多个并行的项目上面，从而提高了员工全神贯注的效率。

模式57.“棒球不相信眼泪！”（电影台词）

组织文化不鼓励人们表露情绪，进而使得冲突只能暗中进行。
在会议上哭泣或者针对不受欢迎的决定爆发怒火的人被视作没有职业态度，这样的人也通常会被视作在情绪上过于反复无常，因而得不到提升。在决定是否容忍难以控制的情绪时，请记住情绪对工作的干扰程序取决于人们对自己工作的关心程度。不让员工有任何情绪的简单办法就是招聘那些对工作不以为意的人。给项目配备激情四溢、关心自己所从事工作的人员才是成功之道。他们的激情有时会掀起怒火，但是破灭这类怒火是达成宏伟目标必须偿付的代价之一。

模式58.铁窗喋血

合理的冲突被解释成“沟通失败”。
把问题归咎于同事的打扰是一种错。我们一直在针对问题错误地寻找原因，最常见的形式是把所有未能达成和谐的情景都归咎于沟通不足。人们在宣称自己沟通技巧多么糟糕的时候，或许正是他们最善于表达自己想法的时候。下一次当你在组织里面听到有人把失败归咎于沟通时，请注意倾听弦外之音。那很有可能是“我非常了解你，但是我讨厌你说的话”。其中深层次的原因是认为在业务背景下面发生冲突会显得不够职业。当冲突被视为非常自然而且绝对职业时，各方注意力就转向有效解决冲突的技巧上，而不是大错特错地改进沟通。

模式59.按期交付，每回都不例外

团队总是按期交付项目版本。
在整个开发周期中，需要一直对优先级重新进行权衡并对资源重新进行分配，五种‘杠杆’：人；技术；范围；日程表时间；交付质量标准。随着项目进行，一些因素发生变化，因此需要针对五种因素调整它们的组合关系。当版本周期的后期发现了问题时，你往往会发现自己只有两个杠杆可以调节，日程表和交付质量标准。如果你承诺了按时交付，那么唯一可纠正的手段就是放宽你的交付质量标准。

模式60.食物++

项目团队成员定期在一起享用他们的食物，而且如果可能，整个团队会在一起筹划和准备这些食物。
《千与千寻》的制作过程，导演意识到除非团队加快速度，否则电影将会错误首映，从一天加班开始，每个晚上，团队里面的人会为大家准备一份晚餐，最后电影按时上映。围绕着食物的固定程序，准备、食用时的协作、清理过程，所有的参与者之间建立起了一种联系。当食物端上餐桌的时候，它是整个团队一起努力的结晶，对于长期在杂乱的项目上一起工作的团队，这是“项目中的项目”，可以快速地完成和品尝。分享食物，带来的亲密感使会议变得更有成效。可以利用这一过程中丰富的互动机会。

模式61.没人在意的交付物

没有人愿意为团队开发的一些项目产物掏腰包。
想想如果组织希望所有的项目都提交标准文档，其目的是鼓励设计方案的重用，并且让项目外部人士清楚项目的情况。然而开发团队的关键目标是在预算内按时完成交付，他们根本不需要这份文档就能达成目标。中央架构组在这种情况下可能会担任起资助人的角色。没人在意的交付物并没有清晰一致、经过验证的需求，换句话说，没有资助人。考虑一下每一个没人在意的交付物的价值。如果你发现没有人愿意为之付钱，而且项目也不需要他，就不要去开发。假如你认为它是个不错的想法，但却没人会为之付钱，那就找到一个资助人。

模式62.隐藏的美

项目的某些产品不是满足于尚可甚至优雅的标准……而是追求至善至美。
只有减少特性才能改善设计的美学品质。最好的设计都是简洁的、功能明确的、易于测试的，而且即使对其修改，也不会带来新的麻烦。在工作成果很大程度上不可见的情况下，设计人员会受到关注细节的经理的极大影响。如果你用心去欣赏某位设计人员的作品，可能就会进入另一个世界，从而发现以前未曾注意到的美妙细节，两个人因此也就有了默契。在设计人员的眼里，你也许就会从一个还不错的经理转变成“我会一直跟随的老板”。

模式63.我不知道

组织营造出能讲真话的氛围，即使讲真话意味着无法立即给予答复。
除了给予事实就是的回答，“我不知道”也能激起团队的协作氛围，鼓励每一个对问题有一定了解的人提供有帮助的信息。我们谈论的不是持续的无知状态，而是公开宣布的待填补的知识缺口。有的组织把开发流程看成是工厂中的流水作业线，宁愿保持着流水线的运转，也不愿生产过程出现停顿，这样组织中，人们既不知道答案，有没有安全感来坦承这一点。“我不知道”在有些组织中被视为说话者的怯懦标记，这类组织的文化是每个人都应该无所不知，这种闭目塞听的态度只会导致人们不愿意去寻求帮助。每当有人说“我不知道”，你就听到的就是信任的宣言。如果整个组织里面的人都觉得说出“我不知道”是安全的，这说明人们觉得寻求帮助是安全的。这一类组织真正是在各个层面上都鼓励协作，并获得由此而来的好处。

模式64.乌比冈湖儿童

经理给出的绩效排名不能有效地区分出执行力的强弱。
它揭示了撒谎的文化。有时为了与绩效糟糕的雇员进行有建设性的交流，经理得稍微变换一下角色。在绩效管理的早期阶段，经理处于教练的模式：解释、演示、协助、回答问题，尤其是要鼓励该雇员。等到了评估绩效和提供评定结果的时候，经理必须更多地扮演法官的角色。未能应对末尾绩效的另一个症状是“缩水的工作”，你会抽去他手头的某些事情，让其他同事来干，慢慢的他表面上的绩效就会改进到可以容忍的级别，那是因为他现在做的事情远远少于角色所要求的事情。这样对其他团队成员不公平。表扬那些做出贡献的人给出及其卓越的绩效评定。让绩效较差的雇员及早地意识到自己没有达到期望，接下来或许能够成功达到甚至超出期望。不要对评定处于中间位置的人撒谎。只有基于实际的平均水平，你才讲出了真正的事实。

模式65.相互教学

项目的利害相干人明白每个人都能从其他人那里学到很多东西。
在项目开始，期望每个人都准确知道理想的未来状态会是什么样子，这是不现实的。问题在于利害相干人不明白他们必须向其他人学习。在知道某些东西是否符合自己的需要和目标之前，我们很可能要先观看或者体验一下。有些组织在任何开发活动开始之前都要签署需求规格书，通常由主要的消费者签署，由于他对规格书全权负责，自然会去强行指定，这使得需求收集员退化成抄录员，阻碍了本应基于早期原型和探索性模型进行发现与学习的过程。学习最好在及早开始。随着项目进展，想法开始定型，期望更加不容易改变，曾经谈论的解决方案越来越富于预见性。创新就变得难上加难。有效的相互教学，需要一种通用语言——建模语言。

模式66.意气相投

组织允许特殊的团队来简化它们开发流程中的规则，甚至是那些最基本的规则。
由于缺乏称谓，我们把这些人称为“游击队”，它们看上去鲁莽大意，但却以惊人的速度取得了真正的发展，它们的做法会让你重新调整自己以往的那些价值判断，从而让你觉得软件开发流程中的很多部分其实没有必要非得那么正式。我们尽可能早的把需求整理正确，避免返工，然而软件的构建和验证太昂贵了，无法多次重复执行，但“游击队”能取得成功，是因为他们不属于这种通常情况，他们的速度如此之快，以至于他们在构建产品的时候，能够承担起抛弃大量代码的代价。他们肯定会对产品的第一个版本有效，擅长较新问题，但汲汲与创新，就像是没有安全措施的电动工具，可以有高效的生产率，也可以是惊人地富于破坏性，这取决于如何引领和指导他们。他们通常是围绕着一两位引人瞩目的领袖人物形成的。缓慢地吸纳新队友（因为他们标准很高），而且只在领袖的领导下，他们才会团结在一起。但一旦团队开始分裂，转眼就会消弭于无形。他们的规模很小，与其他团队合作也不是很好，尤其是远程团队。他们团队内部的凝聚力相当高。这个模式需要团队对外部的依赖非常松散才行。于是，他们不会成长得很大，他们不能被重新安置在其他地方，他们与外部的交往也不会太和谐。“游击队”在任何系统上很少会坚持到第五个版本，知道何时停止使用很重要。最后是，小心大量存在的滥竽充数者。

模式67.十字槽螺丝帽

惊人的是，显而易见的好想法不会很快被接受。
更新、更好并不足以保证立刻能被接受，那得一段时间，组织抗拒变化，或者在决策的延长期里面推迟变化。能推动一个想法付诸实施的人是倡导者，而那些历来总能提出新想法的人则是发明家，人们更愿意去接受由经过考验的发明家所提出的想法。

模式68.可预测的创新

团队在自身对创新的需求和老板对可预测性的需求之间做出平衡。
这种困境，就像走钢丝绳——既要给你的开发人员提供足够的时间，又要给老板和客户就何时完成提供精确地预测。可以采用迭代方法，前三个迭代集中用来对整个特性域进行探索，迭代一开发人员可以在任一方面自由发挥，迭代二一的结果可能在迭代二被抛弃，但他们的目标是澄清未知因素，减少开发工作的不确定性。前三次迭代可能会花6到12周，而后的那些迭代要把最终产品构建完毕。要想平衡创造性和预测性，就得在固定的开发周期里面，多次地对问题域中需要创新的那些领域进行探索，不一定会得出需要的好想法，但可以让我们在整个开发周期内规划一些创造性的迭代。

模式69.玛丽莲•明斯特（一部美国喜剧）

在有些组织中，开发人员就是君王，而在有些组织中，他们只是无名小卒。
有的公司依据的道理是：开发人员随处可见，并且水平也差不多，因此他们提供的服务就理应得到尽可能少的薪水。但是“开发人员为王”的极端也会带来麻烦，他们不顾及个人决定对其他人的影响，就去优化自己的工作或者编进进度表，项目就可能陷入麻烦。如果你雇佣开发人员，有必要扪心自问质量和创新对于组织成功有多重要，如果你想着尽量降低开发人员的成本，就意味着无法吸引和培养顶级天分的开发人员。而如果你是一名优秀的开发人员，一定会有其他的家庭给予你应得的赞赏，逃离这种不正常的环境吧。

模式70.布朗运动

在项目愿景尚不明朗的情况下，团队成员就被添加到其他项目里面。
在愿景变得清晰之前就往项目上加人，着只会适得其反。当太多人试图给项目划定计划，结果就会混乱不堪、逻辑不清。无论最后形成的团队规模多大，清晰的愿景只来源于一个人或者一个很小的团体。

模式71.大声地、清楚地

大声地、再三地清楚表达项目的目标。
组织中工作的人们通常会有与项目目标相冲突的个人目标。目标需要清晰表达、复审和优化，这样才能保证不同的资助人与利害相干人对于项目的期望真正地汇聚在一起。如果不时常拿项目的整体目标来提醒人们，人们很容易忘记那些目标。拥有正确的目标至关重要。让每个人都始终意识到自己的目标会给项目以及自己开发的产品产生巨大的影响。

模式72.安全阀

为了化解工作中的紧张气氛，团队发明了缓解压力的活动，并演化为团队生活的一部分。
我们需要一种休息，它与疲惫或者提神无关，是缓解工作的压力。此类活动可以是一些游戏，而且最有效且最受欢迎的都诞生于团队内部，这种活动无法强制推行，也不便由团队以外的人建言。如果你是经理，当你看到团队在安全阀活动上面花了一点时间，请不要反对这种做法，也无须鼓励去这样做，因为这是团队自己的娱乐时间，他们最清楚怎么利用这段时间。

模式73.巴别塔

项目未能开发出一种开发团队和利害相干人都能理解的通用语言。
组织是大型的、不断变化的矛盾有机体，术语在不同项目的上下文中有着不同的含义。被误解的风险随着任意一项与个体差异相关的因素而增加，比如领域知识、生活阅历、语言背景或者个体特征。发展这种语言意味着逐步给各种术语提供书面定义，以反映成员不断深入的理解，同意也意味着让团队中的每个人都非常易于接触和扩充那些术语。

模式74.惊喜

提供奖赏和奖励的经理听到了意料之外的回应。
组织向团队或者个人送出的奖励几乎不可能做到人人满意，哪怕它们真的只是一种象征，只是为了表达组织的感激之情而已。当组织习惯于使用奖金和奖赏来诱使行为发生改变，或者去维持一个无法持续的行为（比如每周工作六天），它们只会成功地激发大部分领受者的反抗情绪。死死抓住奖励和奖金模式的组织从来得不到奖励。

模式75.冰箱门

团队成员定期地把各自的工作成果展现给团队所有的人。
健康的团队在不同的项目角色之间共享：版本计划；本周或者当前版本的工作安排；燃尽图。也会共享如下这些需求产出：系统的上下文关系图；用例列表；包含了用例和领域类型的交叉结构图。项目产物的公开展示反应出团队成员之间的信任。没有什么会仅仅因为主观原因而隐藏起来。没有人会因为让其他人看到了未完成的事物或者进度拖延而担心。成员不会去“偏袒”或者粉饰自己的进度报告。同样帮团队省去了繁重的项目管理和文档分发。冰箱门式的信息展示有一种与生俱来的东西，提供了“团队就在这里”的信息，想想体育激励海报上印的老掉牙却让人热血沸腾的词汇的做法。

模式76.明天会是晴空万里

经理相信未来的平均进度会超过过去的平均进度。
急切的团队在自己能够完成的工作量上往往过于乐观，尤其是在开发周期的早期阶段。乐观到让人感觉有些危险，即使他不是天生的乐观主义者，项目的推动力也会鼓励他表现得像一位乐观主义者。如果他假设项目未来会遭遇平均程度的坏运气，他可能将同时考虑缩减范围和进度延期。未来的坏运气还没有发生时，他也无法证明他需要这么做。极限编程提供了一种方式（昨日天气）：下一个迭代的生产率被假定为不超过上一个迭代的实际生产率。

模式77.堆积

利害相干人宣称支持项目，然而却一直百般阻挠直到项目失败。
那些想要挫败新项目的人没有必要冒着风险真正站出来反对，他们可以通过提议数十个能够“帮助项目达成卓越目标”的附加特性和改进措施，给项目以最积极的信任投票。采用迭代的团队对于“堆积”不具有免疫力，但是在计划每个迭代的排列顺序时，按照从关键到“堆积”的级别来评估特性，制定优先级，如果下一个特性所承诺增加的收益少于增加的成本，项目或许就会宣告完工。“反现实”（Peter G.W.Keen 信息系统和组织变更）的种种变体非常普遍，如果你识别不了，那是因为你观察得不够仔细。

模式78.变更时节

在项目的整个过程中，范围变更的时机只出现在特定的时刻——通常是开发迭代的开始或者结束阶段。
为了在改进范围的需要与保持前行势头的需要之间取得平衡，很多团队把项目的开发过程分为多个短迭代，每个迭代都严格限制范围变更，团队成员不会被打扰。只有迭代持续时间较短时，本方法才有奏效。

模式79.造纸厂

组织通过迄今产出文档的重量和数量来衡量进度。
在“造纸厂”之中，每项活动都是以文档的产出作为标示的，项目的进度也是以产出文档的数量，而不是文档所包含的内容来衡量的。另一种形式是，不同文档的内容相互之间没有形式上的关联。这是有害的，这样的我们会停止思考，我们是否在从事有助于实现项目目标的工作。非“造纸厂”团队，没有去自动生成文档，而是考虑使用其他的方式来沟通进度，使用白板、电话会议、博客和原型作为沟通媒介，并把所有的项目制品保存到中央项目库，让所有需要这些制品的人都可以自由取得他们。关键在于每一份文档都应满足某些明确界定的要求，而且其包含的内容应该在整个项目的知识库中都可溯。

模式80.离岸荒唐事

领导们被低廉的工人薪资所吸引，启动了离岸开发计划，使得在各个开发地点之间沟通的难度剧增。
人们没有认识到不同地点之间沟通与迭代的高成本。症状：整个开发周期李米娜，每天早上召开例会，这样位于不同地点的开发人员可以同步进展；3个位于近地地点的人试图管理2个离岸开发人员的工作；第一线员工的直接经理位于4个时区以外的地点；离岸团队为六个产品开发特性，但自己却无法发布任何特性。建议：本地迭代，只要可能，就把需要快速迭代的工作的各阶段任务分派给单一地点的团队；要认识到最初几次利用离岸开发会比近地开发话费更长的时间，团队需要时间来适应；意识到离岸团队与近地团队在大多数方面没有任何区别；树立各个地点的目标。

模式81.作战室

使用专用的作战室，把项目列为重点。
作战室表明：大量面对面的交流对项目的成功至关重要。强调积极地展示工作产物对团队的凝聚与工作的引导尤为重要。也展示了利害相干人为了项目成功而大力投资的决心。

模式82.什么味道

组织中的人们无法察觉隐藏于表面之下的究竟是活力还是衰败。
无论你在组织内处于何种位置，你都无法靠自己判定组织的气味。你或许能够借助某个专业协会的本地分部，启动一个名为“Smell-Now:It’s-For-Facts”的计划。

模式83.不从教训中学习

团队认识到自己的错误，却又一次接一次地重蹈覆辙。
在项目之后不去检视项目成败的一个借口是自认为时间不充分。对于每个人都承认的失败，如果不想办法去改进，同样的失败会一再发生。在项目结束时候召开经验学习会议只是第一步，往往发现自己强调的问题，严格意义上都不是项目内部的问题，都源于外部给项目的约束，所以它们的解决方案可能会被认为是逾越了职权。回顾有时变成了单纯抱怨的会议。当经验学习的过程主要是以发泄而结束时，你会发现公布的结果都是人们的观察结果，而不是行动事项。关键在于坚持为每一个明确的问题制定具体行动方案。开这种会，还有一个操作上的小技巧，就是让每个人最少准备关于项目的一件好事和一件坏事出席会议。不仅仅是在结束阶段，是在每次迭代或者发布的结束阶段，主持中期的小型回顾同样很必要。

模式84.不成熟的想法神圣不可侵犯

团队愿意鼓励、呵护即使看起来不成熟的想法。
不成熟的想法应该需要保护和培育。只有团队成员对脱口而出的想法（虽然看起来欠考虑）感到安全时，头脑风暴和其他创新性的研讨会才能发挥作用。即使不成熟的想法，只要收到尊重并允许其存在，有时也会转变成有价值的商业产品。相对于发明新东西，人类更擅长改善已有的东西，而且几乎所有的想法都可以被优化——如果你能坚持下去。想法不应受到约束。除非时间极其短暂，否则为什么要急着摒弃那些不是立即可行的想法？团队所需要做的同样也是不加约束，形成一种使得团队成员觉得能够提议不成熟想法的文化。

模式85.渗漏

时间和金钱往往会从衡量密切的范畴“逃离”到衡量不那么密切的范畴。
幸运的你，也许会在工作分解结构（WBS）里找到一项尚未登记的任务，然后把你一个任务含糊的转移到这项任务成为渗透。渗透有两种：一种是在工作完成的时候，把它归到了错误的范畴；第二种是把工作的一部分推迟成后期的任务。后果就是无形之中给项目带来了延期。当工作从整个项目之中渗漏出去，后果就是交付之后仍需修复再修复的劣质产品。当困难的工作从早期活动之中渗漏出来后，难度的密度分布就随着时间不断累加，最后陷入那句常说的至理名言——项目最后5%的工作花去了远远多于5%的时间。

模式86.模板僵尸

项目团队使用模板——而不是对于产品交付所必需的、经过深思熟虑的流程——来驱动自己的工作。
在模板僵尸的世界中，格式为王，没有必要对文档的内容进行思考。模板不是一定不好，在检查列表和问题框架时提供了非常好的途径来传承经验。但当组织设想每一个项目都与之前的项目一模一样时，问题就出现了。模板僵尸们相信只要能把任何东西放入模板的所有区块里，他们就一定能成功。僵尸不是去直面棘手的现实，每个项目都是不同的，也不是只把模板视为指导项目的工具，而是屈从于把自己大脑掏空、把空白处填满的诱惑。

项目秘密

听上去无关痛痒的词句背后，是并不友善的深层含义。
当他们说… （他们的真正意思是…）
进度表有些激进 （我们有麻烦了）
我们将在接下来的几个迭代里面弥补延误 （我们还是有麻烦）
他真实独当一面 （他有麻烦了）
行动纲领 （充饥画饼）
高层次的 （脱离实际的）
快速组建团队 （根本不可能）
做特别项目的经理 （管理自己的桌子）
我们来自管理部门，来这里帮忙 （太直白了，不需要翻译）
工作继续进行 （我们一无所知）
时间会说明一切的 （我们无能，而且我们也承认这一点）
这是一次学习经历 （我们真的搞砸了）
我之前说… （我之前说的都是狗屎）
编码完成 （没有测试）
给你权利了 （你要为此事收到问责）
唾手可得的成果 （连[谁谁谁]都不会搞砸的事情）
让我们把它放在一边，继续前进 （跟政客说这句话时所表达的含义一样）
现在，听我的意见 （我等级比你高）
代码变得不可维护 （要是我，设计就完全不一样了）
我们还在万米高的空中 （它还在我的桌子上，未曾触及）
Bradley真实我们的全能手 （Bradley真是项目上的白痴）
达成一致意见 （照我的方法做）
最佳实践 （是由不在这里工作的人们发明的，所以比我们做的任何事情都要高明无数倍）
有效利用核心竞争力 （不要挑麻烦事做）
线下再讨论 （永远不再讨论）
你使用了新奇的方法 （你真是个白痴）
测试被证明是主要的瓶颈 （他们总是在找bug）
有限发布 （不包含功能的发布）
让我澄清我要什么 （新需求来了）
我们在考虑我们的选项 （只有一个）