项目百态——深入理解软件项目行为模式（三）
模式四十一 同事预审
组织让将来与应聘人共事的员工也参与到招聘过程中来。当团队在招聘过程中能拥有话语权的时候，就出现了多赢的局面。从经理的角度上讲，同事预审在雇佣团队组长的问题上同样有效。
模式四十二 浮潜与水肺潜水
不同形式的分析活动贯穿项目的整个生命周期：自下而上，自上而下以及先中间后两边。成功的项目团队在项目的整个过程中会把浮潜和水肺潜水两种方式结合起来使用，在特定的时刻明智的选择合适的方法，从而有效的利用时间。
浮潜是一项很好的技术，项目团队可以用它来弄清楚需要研究多少领域，以理解问题和达成目标，而深度潜水的发现常常会改变浮潜阶段所作出的假设。本模式的迹象之一是团队在做广度考察（浮潜）的同时，也会针对特定问题进行具体的工作（水肺潜水）。关键的是团队在项目的整个过程中应用广度与深度研究技巧的能力。在广度上知晓的越多，就越能识别出高风险与高收益的领域。
模式四十三 一切都是该死的接口
项目团队成员毫不妥协的强调接口——既在产品里面，也在人与人之间。洞悉该模式的团队会早早的对付接口，在提交所有的组件代码之前，他们构建了一系列的程序来检验接口。他们早早地集成个人代码，频繁地测试。请记住康威定律(Conway's Law):产品反映了制造该产品的组织结构。对于接口，这一点尤为正确：项目中复杂的人类接口容易导致复杂的产品接口。
模式四十四 蓝色区域
团队至少有一位成员经常性越职。经理在分派任务的时候会设定任务的范围：一方面要考虑到团队成员的能力，另一方面也保证了接受者拥有足够的自由度来完成任务。同时，经理也避免分派的任务产生重叠或者冲突。把项目的分派分为三个权限区域，那么绿色是任务安排中明确定义需要完成的事，而红色区域则是明确排除在任务范畴之外的事，蓝色区域则介于红色和绿色之间。此时记住：绝对的服从可能是有害的，而某些善意的无序反而是有益的。
模式四十五 消息美化
坏消息在组织里面没有准确的向上表达。消息美化是一种破坏型模式，因为它使决策者得不到所需要的信息，这又可能导致错误的决策（或者贻误了决策），结果反而更糟。当你在项目中观察到这个模式，最典型的症状是出现意外，典型的后果就是延误了一个又一个截止日期，从而达不到期望的结果。刻意隐瞒坏消息可能使得可以解决的问题变得无法解决。
如何才能改进组织的能力，使之能快速，准确向上传达坏消息呢？大部分的解决方案在于你——经理。你不能仅仅在口头说希望即时得到坏消息，你还得那样去做。最起码的，这意味着你得把坏消息的反应分为两部分：决定如何处理以及弄清楚它的发生。记住：坏消息可以被解决，但不能被美化。
模式四十六 慢慢地道出事实
公司文化迫使人们把令人不安的消息埋在心底，但是要慢慢的把事情道出来，因为他们不希望对自己公布的问题负责，他们对自己将会被问到的后续问题没有答案，他们在等待其他的人揭露更大的问题，这样他们就能隐瞒自己的问题。
模式四十七 残局游戏
团队在整个开发过程中定期地使用交付标准检验构建中的产品。采取”残局游戏“方法的团队在项目早期就制定了交付标准，然后开发出验证产品是否满足交付标准的测试。这些测试在每次开发迭代结束之后都会执行，然后就是一个小型的就绪度审查会议。
模式四十八 音乐制作人
在IT组织里面，拥有音乐才华的人所占的比例超出了在平常群体中的比例，有时还会更多。技术的数字本质与音乐的模拟本质之间的对比可能是非常的奇妙，又抑或只是个巧合，不过用音乐进行工作的放松确实是个不错的抉择。
模式四十九 记者
记者是指那些把准确报告这个目标与让项目成功这个目标完全分开的项目经理。项目经理知道他们必须理解项目的真实状态，然后基于那些情况准确地作出报告。项目经理首先要保障项目安全、准时”着陆“正确目的地，随之而来的准确报告只是达成这些目标的一种手段，却无法替代这些目标。
模式五十 空椅子
很多项目没有真正成功，只因为缺少一个人专门负责确保最终的业务流程——从用户的角度来看——尽量顺利开展。这个人关注的是整个项目对于客户而言的最佳结果，一直到最细微的细节。我们说的这个人不是项目经理，也不是团队的总领导。这个人可能没有任何人直接向他汇报，他也几乎肯定不需要为预算或者计划负责，他全部的关注点只在于产品如何与目标环境交互，特别是产品的最终用户交互。
空椅子在那些需要集成原有系统的项目中甚至更为常见。
模式五十一 我的堂兄文尼
团队成员争吵不休——群情激昂却了无敌意——去评价和改良他们的主张。团队中有意义的争论能够改善构建中的系统。为得到最佳解决方案而争论的团队成员会互相尊重，甚至说他们惺惺相惜也不为过。争论的时候，团队成员知道对自己的主张的讨论和剖析并不是针对个人攻击，而只不过是想通过有效的方式交付最优秀的产品。
模式五十二 特性汤
产品夸耀自己繁多的零碎特性，其中很多对于解决客户真正的业务需求几乎毫无帮助。避开特性汤的组织有着很多的共同点：尽可能干脆、尽可能早定义项目目标和非项目目标；声明项目范围，并以精确定义输入/输出数据的形式时刻保持更新；坚决拒绝那些对声明的目标没有积极效应而又明显超出项目范围的需求；新需求的添加遵照被核准的，可追溯的变更管理流程进行，同时使用项目声明的目标对它们进行评估。
避免特性汤时刻牢记：你们是整个项目团队，而不是零散特性的请求者。
模式五十三 数据质量
数据质量经常会糟糕透顶，遗憾的是，解决这个问题的常见做法是寻求更好的软件来处理数据。指出数据可能会被破坏是值得的，而且在这种情况下，至少有一些半自动化的方法能够通过恢复更早的备份版本来抵消造成的破坏。数据质量随着时间推移而逐渐下降的主要原因是变更，此时只能通过手工修复。
模式五十四 本
对于有些人而言，工作条件太好了，或者项目太有趣，又或者产品太酷，以至于他们对工作的热爱大于对薪水的热爱。本，不需要密切的督管，本的经理的角色就是引导本区从事他感兴趣的工作，从而保证他这个高度胜任并热爱这个工作的员工以饱满的热忱去完成它。
模式五十五 礼数小姐
人们认为质疑同一个团队的成员的主张是不礼貌的。批评变得委婉，变成各种含蓄的说辞，比如述评或者评估。礼数小姐的组织里面都是假面孔，没有真面目。身处其中的人们被迫整天带着面具。
模式五十六 全神贯注
在单一的项目上投入全部的时间，可以改进个人的绩效。
模式五十七 ”棒球不相信眼泪“
组织文化不鼓励人们表露情绪，进而使得冲突只能在黑暗中进行。在决定是否容忍难以控制的情绪时，请记住情绪对工作的干扰程度取决于人们对自己工作的关心程度。给项目配备激情四溢，关心自己所从事工作的人员才是成功之道。他们的激情有时会掀起怒火，但扑灭这类怒火是达成宏伟目标必须偿付的代价之一。
模式五十八 铁窗喋血
合理的冲突被解释成”沟通失败“。下一次当你在组织里听到有人把失败归咎于沟通时，注意倾听弦外之音。把它称为沟通失败，就把所有人的注意力从问题的真正根源——合理的冲突——转移开，反倒集中精力到错误的根源上面，结果就是浪费了更多的精力去沟通早已被断然拒绝的信息。
模式五十九 按期交付，每回都不例外
在整个开发周期中，需要一直对优先级重新进行权衡并对资源重新进行分配。一般来说，组织运作项目有以下五种主要的”杠杆“手段：人，技术，范围，日程时间表，交付质量标准。当版本周期的后期出现了问题时，你往往会发现自己只有两个杠杆能够调节：日程时间表和交付质量标准。如果你确实承诺了严格的按时交付，并且每次都不例外，你剩下的唯一可行手段就是：降低交付质量标准。
模式六十 食物++
项目团队成员定期在一起享用他们的食物，而且如果可能，整个团队会在一起筹划和准备这些食物。一起吃饭并不能保证你的团队就会成功，就像不再一起吃饭也无法得出项目失败的结论一样。然而，我们观察到很多成功的团队喜欢一同准备和食用食物，他们恰恰利用了这一过程中丰富的互动机会。
