模式二十一 苏式风格
交付的产品包含了客户要求的功能，但却不受客户待见，很快就被搁置一边了。我们需要发掘产品的非功能性需求，成功的团队会把系统性捕获非功能性需求当作流程中的特殊路径对待。避免构建苏式风格的产品，首先，保证你的项目计划中明确包含了非功能性需求。除了持续关注之外，对于能够获取用户好感的非功能性需求，要尽量使用早期项目原型以得到有价值的反馈。
模式二十二 自然权力
权力往往会追逐能力，聚集在能力周围。违背自然权力的流动规律，听上去像是在滥用职权。
模式二十三 万籁俱寂的办公室
办公室太安静了，凸显出团队已经失去了活力源泉。
模式二十四 白线
目标的达成取决于系统内部行为和外部直接活动的联合作用。声明项目目标往往是值得的，但这样的声明并没有明确界定什么属于新系统范围之内，而什么又超出了新系统的边界。所谓“系统”和“业务领域”的本质：它们都是由转换数据的流程组成。这些流程通过修改数据的一组属性，从而更新数据的状态，然后再把数据传递给下一个流程。通过声明（更准确的说，建模）每一个跨越系统边界的数据项集合，你其实在强调：边界的这一边生产数据，而边界的另一边则使用数据。从另一个角度来说，你是在通过声明需要修改的系统/业务领域与直接交互的外部世界之间的每个接口来定义项目范围。一旦该工作完成，系统范围就将不再有任何的歧义，你已经借助于接口绘出了白线。
模式二十五 沉默即同意
沉默即同意式的承诺对每个人都不利。双方不可避免地给工作定义出不同的优先级，最终的结果必然是惨淡收场。理论上，问题看上去是容易解决的：人们必须学会说“不”。
模式二十六 稻草人
稻草人不是一个抽象模型，而是一个解决方案。它可能没有完整实现，或者还不正确，但团队仍然有意的把它提供给客户，征求他们的意见。稻草人模型则是一种需求钓饵，甚至可能包括一些有意为之的错误。稻草人的哲学是尽早犯错，频繁犯错，这样你将会尽快得到正确的结果。
模式二十七 伪造的紧急性
伪造的紧急性会引发伪造的风险。项目惨淡收场，这并不是最坏的情况，最坏的情况是组织没有抓住真正的商业机会去从事高价值的项目，而那些项目的风险都是值得去尝试的。
模式二十八 时间清除了你的手牌
时间是位拙劣的项目经理。所有优秀的项目经理都知道何时需要亮出自己的牌，好让时间无法赢过他们。
模式二十九 Lewis 与 Clark
项目团队在前期投入精力，探索领域并发掘潜能。Lewis与Clark型项目把资源慎重的分配到针对业务领域的预先探索上面，以判定项目的可行性。在现实中，有些探索行动的结果显示没有行动能有效改善情况。这样的发现是一种红利，它阻止了不必要的项目损耗宝贵资源。
模式三十 短铅笔
连续不断的成本消减开始影响到组织完成任务的能力。太多的成本消减措施会导致组织缺乏竞争力，最终甚至引起成本的增加。
模式三十一 节奏
团队通过定期交付，建立起工作的节奏。每一步都会让你更接近顶峰，不要只是盯着最高点，反之，要集中精力，采取有规律的步伐，找到一个稳健的节奏，然后保持住——你就能攀登到顶峰。节奏的周期长度并不重要，只要人们能够感觉到节奏的存在即可。按照节奏工作是一种自我强化的行为——团队成员遵照节奏的要求进行生产，与此同时，他们发现越来越容易跟上节奏，保持节奏的压力成为了一种积极的推动力。
模式三十二 加班预兆
早期的、持续的加班很可能表示项目团队正处于恐惧之中。恐惧文化的存在可能基于以下原因：基于恐惧的管理（有些组织彻底依靠恐惧来维持运转）；惧怕为了消减成本而强行裁员；惧怕个人失败（对自己是否有能力完成任务没有信心的团队成员）；惧怕项目失败（团队成员对按照计划成功完成没有信心）；确信项目会失败，但惧怕个人承受责备。
加班通常看上去像是被工作热情和专业精神所驱动，但真正的驱动力却可能是出于恐惧。早期以及长期的加班预示了并不尽人意的项目结果，包括团队变得精疲力尽、雇员背叛、计划延期，甚至会因为对质量妥协而最终损害产品的完整性。
模式三十三 扑克之夜
来自组织各个部门的雇员聚在一起，参加与工作角色无关联的活动。互相熟悉可以使彼此互相信任，也可以使彼此更有耐心。无论做什么，无论这些条件如何形成，无论你如何看待人们和活动，绝对不要去驱迫他们。
模式三十四 错误的质量关卡
项目中的质量保证工作着眼于格式检查，而这些工作根本不能给真正的产品质量带来任何改善。在抵达里程碑或者结束迭代之前，很多组织都会对项目的产出结果执行规定的质量检查，通常包括两部分：一是检查计划制品的完成状态和格式，二是检查制品的内容。第一步是确保预期交付物按照预定的格式完成，第二步则是检查各项交付物是否恰当，准确，是否充分达到了项目要求的目标。然而，如果缺失了第二步，那么第一步则沦为舍本逐末。
如果你使用的是错误的质量关卡，就会发现质检过程传回来的大多数反馈都是关于交付物的形式，而不是交付物的内容含义。该模式把时间浪费在不具备产出性的步骤上面，更为严重的是，与内容相关的缺陷溜进了最后的产品中。
模式三十五 测试之前先测试
测试不仅仅是测试！早期测试，也就是说，在测试阶段之前测试，用来确保项目的计划交付物一旦开发出来后，其正确性能够经受测试。如果需求本身就没有经过测试，需求又如何能被软件测试人员信任呢？早期测试的目的是给后来阶段的测试提供精确的标准以衡量解决方案。
在测试之前测试意味着在最开始的项目讨论时就引入了质量控制，也意味着对影响最深远的交付物进行测试，自然使你的测试付出收到最佳回报。
模式三十六 苹果酒屋规则
酒后请不要操作磨床或榨汁机，请不要在床上抽烟，也不要使用蜡烛，酒后请不要上屋顶，尤其是在夜间，上屋顶时请不要带酒瓶——苹果酒屋规则
项目团队成员罔顾或者绕过那些由项目工作无关人士制订的规则。成功的项目绝不可能是完全混乱无序的，肯定要一些规则和定义好的流程，但是，规则制定者眼中的世界和规则遵守者栖息的世界必须存在耦合的地方。当规则恰当时，项目团队就会遵守它们，这些规则都是非常有用的，合理的，以及看上去是有意义的。
模式三十七 说，然后写下来
项目团队在交谈间得出了决定，然后立刻用书面形式记录下来以供交流。用书面方式交流决定，可以为那些没有在场或者忘记细节的人们保存决策制定的对话过程。
模式三十八 项目中贪多求全
接受超出团队处理范围的工作是管理层怯懦的表现。为了避免个人遭受指责，却亲手把团队置于不可能成功的境地之中，最终，团队会饱受超负荷工作之苦，在组织里面受到的尊重度下降。逆转恶性循环的办法就是给工作任务安排优先级，只做你最大能力范围之内的事，把低价值的工作放在一边，先完成高价值的工作。承担超出最大能力范围的工作是变得迟缓的罪魁祸首。如果你是一位允许本模式继续存在的经历，你实际上是把项目置于不必要的巨大风险之中。
模式三十九 巨神阿特拉斯
团队领袖（几乎）擅长于一切事情，使潜在的领袖们都没有被作为领袖培养。
模式四十 所有人都穿着衣服是有原因的
完全公开的政策让进度慢慢停下来、停下来……最终完全停下来。太多的信息可能是一件坏事，这一点无论如何强调都不过分，但更大的问题是在于首先理解为什么我们让自己承担如此之多。知道多少信息适合自己的信息餐碟，不仅仅是一项好的策略，而且是成长的一部分。