《项目百态》

# 项目是为提供某项独特产品、服务或者成果所做的临时性努力。

模式1：玩的就是心跳。 --组织相信忙乱的工作象征着高效的生产力。

模式2：快，赶上。 --当项目团队决定在何时该做什么事情时，呈现出明显的紧迫感，并迫不及待地想立即采取所有必要的行动。

模式3：死鱼。 --自打开工起，项目就完全不可能完成目标，项目团队中的大多数人都很清楚这一点，但却都缄口不言。

模式4：欢乐的鼓掌会议。 --是否表现出高涨的士气成为个人绩效的评价因素。

模式5：保姆型项目经理。 --项目经理拥有的技能与传统的英式保姆有很多共同之处。

模式6：牵扯性疼痛。 --项目治愈了外部的病状，却没有根治内部的病因。

模式7：明日复明日。 --每个人都有时间窗，提醒自己立即采取行动并持之以恒，直至工作完成。逾出时间窗的交付日期不会导致任何紧迫感，因此也就产生不了行动的动力。

模式8：眼神交流。 --当任务紧迫而且复杂的时候，组织往往会把项目成员安置在一起工作。

模式9：情绪戒指管理。 --经理不是基于摆在项目面前的风险、决策和问题来汇报项目状态，而是基于团队的活动、付出和热情。

模式10：忠实教徒。 --个体把某种思想派系作为真理来膜拜，与圣典稍有偏差即被认为是亵渎神灵。

模式11：出租灵魂。 --从业者愿意放弃长期练就的技能或者技术。

模式12：系统开发旅鼠周期。 --虽然组织流程很明显地需要进行定制，但项目团队依旧盲从于未定制的标准。

模式13：清空板凳。 --组织变得如此精简，以至于失去任何一个关键人物都会变成一场灾难。

模式14：面对面。 --分布式团队通过各地之间大量的面对面交流机会，以建立使远距离团队合作产生可能的熟悉感和可靠感。

模式15：我给了你凿子，可你为什么不是米开朗基罗。 --经理购买工具，潜意识里希望它们可以赐予团队技能。

模式16：主面板。 --强团队和弱团队都在使用主面板，但普通团队则不然。

模式17：无休止的集体会议。 --允许无休止地争辩，最终肯定无法达成任何一项决定。

模式18：幼犬和老狗。 --拥有很多年轻人的组织比充满老员工的组织更富有生气。

模式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：一切都是该死的接口。 --项目团队成员毫不妥协地强调接口，既在产品里面，也在人与人之间。

模式44：蓝色区域。 --团队至少有一位成员经常性越职。（绝对的服从可能是有害的，某些善意的无序反而是有益的）

模式45：消息美化。 --坏消息在组织里面没有准确地向上传达。（刻意隐瞒坏消息可能使得可解决的问题变成无法解决的问题）

模式46：慢慢地道出事实。 --公司文化迫使人们把令人不安的消息埋在心底。

模式47：残局游戏。 --团队在整个开发过程中定期地使用交付标准检验构建中的产品。

模式48：音乐制作人。 --在IT组织里，拥有音乐才华的人所占的比例超出了在平常群体中的比例，有时甚至还会大很多。

模式49：记者。 --记者是指那些把准确报告这个目标与让项目成功这个目标完全分开的项目经理。

模式50：空椅子。 --没有人为整体用户体验的概念一致性负责。

模式51：我的堂兄文尼。 --团队成员争论不休，群情激昂却了无敌意，去评价和改良他们的主张。

模式52：特性汤。 --产品夸耀自己繁多的零碎特性，其中很多对于解决客户真正的业务需求几乎毫无帮助。

模式53：数据质量。 --数据质量经常会糟糕透顶。遗憾的是，解决这个问题的常见做法是寻求更好的软件来处理数据。

模式54：本。 --对于有些人而言，工作条件简直是太好了，或者项目太有趣，又或者产品太酷，以至于他们对工作的热爱大于对薪水的热爱。

模式55：礼数小姐。 --人们认为质疑同一个团队的成员的主张是不礼貌的。

模式56：全神贯注。 --在单一的项目上投入全部的时间，可以改进个人的绩效。

模式57：“棒球不相信眼泪！” --组织文化不鼓励人们表露情绪，进而使得冲突只能暗中进行。（给项目配备激情四溢、关心自己所从事工作的人员才是成功之道）

模式58：铁窗喋血。 --合理的冲突被解释成“沟通失败”。

模式59：按期交付，每回都不例外。 --团队总是按期交付项目版本。

模式60：食物++。 项目团队成员定期在一起享用他们的食物，而且如果可能，整个团队会在一起筹划和准备这些食物。

模式61：没人在意的交付物。 --没有人愿意为团队开发的一些项目产物掏腰包。

模式62：隐藏的美。 --项目的某些产品不是满足于尚可甚至优雅的标准......而是追求尽善尽美。（美到极致不是增无可增，而是减无可减）

模式63：我不知道。 --团队营造出能讲真话的氛围，即使讲真话意味着无法立即给予答复。

模式64：乌比冈湖儿童。 --经理给出的绩效排名不能有效地区分出执行力的强弱。

模式65：互相教学。 --项目的干系人明白每个人都能从其他人那里学到很多东西。

模式66：意气相投。 --组织允许特殊的团队来简化它们开发流程中的规则，甚至是那些最基本的规则。

模式67：十字槽螺丝帽。 --惊人的是，显而易见的好想法不会很快被接受。

模式68：可预测的创新。 --团队在自身对创新的需求和老板对可预测的需求之间做出平衡。

模式69：玛丽莲.明斯特。 --在有些组织里，开发人员就是君王；而在有些组织中，他们只是无名小卒。

模式70：布朗运动。 --在项目愿景尚不明朗的情况下，团队成员被添加到项目里面。

模式71：大声地、清楚地。 --大声地、再三地清晰表达项目的目标。

模式72：安全阀。 --为了化解工作中的紧张气氛，团队发明了纾解压力的活动，并演化为团队生活的一部分。

模式73：巴别塔。 --项目未能开发出一种开发团队和干系人都能理解的通用语言。

模式74：惊喜。 --提供奖赏和奖励的经理听到了意料之外的回应。

模式75：冰箱门。 --团队成员定期地把各自的工作成果展现给团队所有的人。

模式76：明天会是晴空万里。 --经理相信未来的平均进度会超过过去的平均进度。

模式77：堆积。 --干系人宣称支持项目，然而却一直百般阻扰直到项目失败。

模式78：变更时节。 --在项目的整个过程中，范围变更的时机只出现在特定的时刻，通常是开发迭代的开始或者结束阶段。

模式79：造纸厂。 --组织通过迄今产出的文档的重量和数量来衡量进度。

模式80：离岸荒唐事。 --领导被低廉的工人薪资所吸引，启动了离岸开发计划，使得在各个开发地点之间沟通的难度增剧。

模式81：作战室。 --使用专用的作战室，把项目列为重点。

模式82：什么味道。 --组织中的人们无法察觉隐藏于表面之下的究竟是活力还是衰败。

模式83：不从教训中学习。 --团队认识到自己的错误，却又一次又一次地重蹈覆辙。

模式84：不成熟的想法神圣不可侵犯。 --团队愿意鼓励、呵护即使看起来不成熟的想法。

模式85：渗漏。 --时间和金钱往往会从衡量密切的范畴逃离到衡量不那么密切的范畴。

模式86：模板僵尸。 --项目团队使用模板，而不是对于产品交付所必需的、经过深思熟虑的流程来驱动自己的工作。