《项目百态》——Tom Demarco / Peter Hruschka / Tim Lister / Suzanne Robertson / Steve McMenamin / James Robertson #24
Comments
thzt
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
优先级总是变化不休，所有事项都是“昨天”就要，总是没有足够的时间交付项目，所有项目都是紧迫项目，紧迫的项目源源不断。
每个人都忙得焦头烂额，永远如此。
这些组织里面的人不会从战略层次上思考问题，只是按照紧迫程度来完成工作。
除非“忙乱指数”非常高，否则它通常都会被忽略——尽管它很有可能会带来显著的长期优势。
人们会一直对其不闻不问，直到它突然（绝对出乎意料的）变得非常紧迫。
“玩的就是心跳”分子相信最好的工作方式不是先谋而后动，而是竭力追赶时间。
这种组织文化认为紧迫性越高的项目，绩效也越高。
那些为了某个短得可笑的期限而加班到深夜的程序员被视为英雄（根本不在乎他们交付的程序质量）。
每个周末，团队的所有成员都照常上班，以保持他们的工作量，这样做的团队比不这样做的团队更受人赞许。
大部分的“玩的就是心跳”型组织满腔热情的拥护客户服务的理念，他们错误的认为对紧迫事件的响应就是值得赞赏的响应。
当客户提出了一个请求，不管是否存在潜在的利润（甚至有效性），该项请求都会立即转化成一个项目，而且通常截止日期都会短得可笑。
很多这一类组织都（错误的）认为这就是敏捷的全部。
紧迫性是唯一的标准，没有人尝试按照重要性或者工作价值来对工作排定优先级。
高层领导，通常是CEO，希望看到组织长久的保持匆忙的状态，因为工作匆忙让人生出一种高生产率的幻觉。
“玩的就是心跳”型组织并不是总会失败，他们当中有一些在多年里一直保持着匆忙的节奏。
但是，它们都不可能构建重大的东西——那需要稳定性和计划。
亢奋型行为不可能扩展——由一些相对较少的人在没有方向，也没有战略指导前提下，光凭借非常，非常忙碌的工作所能达到的效果十分有限。
当然了，任何组织内部都会遇上紧迫的事情，也需要一些角色去关心紧迫任务。
但是，不是所有的事情都是紧迫的，也不是所有角色都要关心紧迫的任务。
除非化紧迫性为优先级和约束，否则，这种“玩的就是心跳”的治愈希望是微乎其微了。
快，赶上：当项目团队决定谁在何时该做什么事情时，呈现出明显的紧迫感，并迫不及待的想立即采取所有必要的行动。
死鱼：自打开工起，项目就完全不可能完成目标，项目团队中的大多数人都很清楚这一点，但却都缄口不言。
很多IT项目的目标可以被扼要的概括为：我们要在截止日期之前，完成这一系列功能，达到这样的准确度，并且保证足够的健壮性。
一个天大的秘密是项目团队中没有一个人相信项目最终能成功。
通常看来，如果其他目标不做修改，截止日期是无法达到的。
不可思议的是，没有人指出失败的阴影正如一只散发恶臭的大死鱼一样把项目变得臭不可闻。
很多组织是如此的汲汲于成功，以至于任何表达疑虑的人不会因为讲出由衷的意见得到任何奖赏。
事实上，如果谁在项目的前期阶段就声称死鱼存在，管理层的第一反应多半如下，
“证明给我们看。给我们证明成功的可能性只是零。不要拿以前项目的死鱼经验来唬人。现在的项目不一样。用严密的数学证明来告诉我们失败无法避免。”
一旦你提出任何缺乏精确证据的东西，就会被指责为软蛋或者是试图逃避朴实的辛勤工作。
在这样的环境里，“努力”而无法完成比站出来指出目标无法达到更安全。
确实，有时需要勇于承担有挑战性的项目，在认输之前真正的拼搏一番。
非常正确——但区别是，在有确定的截止日期的艰难项目中，没人会捱到最后一刻才声明情况的危急。
欢乐的鼓掌会议：是否表现出高涨的士气成为个人绩效的评价因素。
保姆型项目经理：项目经理拥有的技能与传统的英式保姆有很多共同之处。
牵涉性疼痛：项目治愈了外部的病状，却没有根治内部的病因。
牵涉性疼痛这个术语通常是指疼痛不是表现在病源位置，而是表现在身体的其他部位。
在项目立项的时候，人们往往会解决显式的问题——最明显的，客户疼痛感最强的问题。
但是，如果只盯住牵涉性疼痛，项目交付的产品——一旦交付了——最终就会变成极大的浪费，因为它对于真正的需求几乎没有任何帮助。
我们可能倚重自己所具备的技术，用与我们所熟知的解决方案最契合的方式来看待问题。
是否在处理牵涉性疼痛，一个强烈的信号是临时补丁。
允当目前系统需要做一些修正的时候，这些补丁就会骤然出现。
临时补丁用来修正问题的外部情况，而没有去修正主要的系统。
临时补丁如同创可贴，很少（甚至从不）能帮助解决问题的根本原因。
但是，当一条补丁看上去有效，更多的补丁就会被采用，有时甚至每个补丁上面都是一层又一层的临时补丁。
集中精力研究真正的需求，解决真正的问题，总是能事半功倍。
紧迫感是实际行动的催化剂。
如果事情不再紧迫，它在今日待办事宜的列表上就会被排到后面。
其他事情的紧迫性就更为显著，今天就应该处理所有那些需要几天才能完成的事情。
“明日”是这样的一种状态，意识到自己需要负责完成工作，但却没意识到如果期望成功，自己就必须从现在开始。
大规模的项目通过让大多数人保持对时间窗的关注，来避免“明日”的影响。
他们把工作转化成在90天之内——通常在30天内——能够交付的具体任务。
但是，要小心，关键在于每个时间窗都必须产出真正的交付物。
只有进度是远远不够的。
警惕“明日”的另一种特殊变体，耗费大量的时间来准备开始。
项目前期阶段的时间并没有像结束阶段的时间一样被仔细的对待，
使行动开始的最佳方式就是不等“明天”，今天就开始动手。
现在，还是痛痛快快的承认吧，如果项目的成败对你性命攸关，你难道会不想把所有的项目成员都安置在一个地方，让他们可以在视线范围之内看到对方？
而且，工作越紧急，团队成员就越有必要在一起。
当所有的全职的，专注的项目成员处在同一个屋檐下工作时，会产生一些很神奇的效果。
他们了解彼此的需要和能力，而且随着了解的增多，他们会调整自己的行为方式，以获得最佳的整合效果。
有一种无形的信息交流使得人际之间的合作变得顺畅，而这依赖于人们在地理位置上的接近度。
类似的，在开发团队里面有一些关键的信息交流对于紧密的合作也非常必要，其中最重要的是信任的给予和获取。
中间横亘着距离，双方很难相互信任。
同样，也很难察觉语言上的微妙之处，信心，某些讽刺和挖苦，真实意图，信服程度，无望感和无能为力感，轻重缓急以及话外之音。
缺乏了这些潜台词，沟通就变得脆弱。
目光接触能提升交流的效果。
情绪戒指管理：经理不是基于摆在项目面前的风险，决策和问题来汇报项目状态，而是基于团队的活动，付出和热情。
忠实信徒：个体把某种思想派系作为真理来膜拜，与圣典稍有偏差即被认为是亵渎神灵。
几乎所有流行的软件工程方法学都来源于软件从业者的经验，而不是基础性研究。
与很多业内领先的流程设计者交流之后，我们得知他们中的大部分人承认。
（1）他们的方法来源于一定的领域或者项目大小。
（2）他们的方法从来没有期望如同描述的一样用在所有可能的环境中。
项目上的忠实信徒会让工作止步不前，他们不去专注于内容，反而为方法争执不休。
称职的专业人士有一项令人钦佩的地方，在于能够根据待解决问题的实际情况来裁剪解决方案，而不是把问题往个人或者团队久经检验的技能上生搬硬套。
一旦出现了好的新思路，他们能够比较各自的优势，非常明智的决定使用最合适的方法。
要放弃长期坚持甚至精通的技术并不容易，但灵魂的出租者能够忍受暂时的不适。
他们知道相对于问题，现有的技术已经绰绰有余，但他们也清楚某项新技术也许能提供更多的东西。
虽然他们并非追赶最新技术潮流的狂热分子，但他们也愿意放弃现在熟捻于心的工作方式，去考虑其他真正的先进技术的优势。
他们的态度是着眼未来，而非从现状中寻求安慰。
诚然，任何组织都不能任意更改自己选用的技术。
它需要在开发语言，开发方法，技术基础设施，以及其他方面保持一定程度的稳定性。
但我们这里讨论的是态度。
当组织决定对新技术不断研究的时候，它打造了一副金字招牌，吸引着最好的和最聪明的雇员。
新的并不一定就是好的。
当新技术（编程语言，建模技巧，方法学或软件工具）问世，颇具说服力的宣传通常也随之而来。
而且在很多情况下表现为大肆炒作，广告轰炸。
能够把问题本身跟解决方案区分开来是称为灵魂出租者的第一步。
第二步则是要弄明白无论技术多优秀，明天总会有更优秀的出现。
如果流程很少照顾到项目的实际需要，照搬流程也许能让项目早点开工，但却无法早点完工。
项目经理不定制流程，就像厨师严格遵循菜谱来烧菜。
那样的话，他永远不会成为一个好的主厨。
当然，即便是好的主厨，也是从学徒工开始，从他们的师傅那里学习菜肴烹饪的基本技能，模仿他们师傅的菜谱。
但一旦他们掌握了基本技能，停止按照标准菜谱烹饪，他们就能脱颖而出，大放异彩。
清空“板凳”：组织变得如此精简，以致于失去任何一个关键人物都会演变成一场灾难。
面对面：分布式团队通过各地之间大量的面对面交流，以建立使远距离团队合作成为可能的熟悉感和可靠感。
在计算机学会会议上，总能听到年轻的程序主管声称他们更喜欢一个小型的，由一流人员组成的尖峰团队，而不是由几百个——同时也意味着平庸的——程序员组成的项目团队。
我们都这样认为。
这才是构建软件的最佳方式。
通常都是精明的年轻人来销售软件工具，他们对工具在生产率方面的效果，以及给使用者带来的能力上面夸下海口。
大多数客户都看穿了销售人员的大言不惭，但是有时候IT经理不胜其烦，失去了区分现实与幻象的能力。
这些经理承担了交付的压力，而他们却几乎没有人手来做到这一点。
自动化工具有时看上去就像是一条救生绳。
在某一个绝望的时刻，工具购买者忽视了工具用户必须具备适当技能的观念。
工具的成本不仅仅是工具的价格。
工具出现在桌面上，给人一种开发人员能力很强，生产率很高的感觉。
但是，工具本身并不能改变任何事情，生产率不会自动提升，报告的错误率仍然居高不下，让人郁闷，而士气也依旧十分低下，令人失望。
虽然事与愿违，但生产率瓶颈可以通过开支票购买工具来打破的信念依然顽固。
当然，工具是有用的，它们在合适的人手中能带来令人惊讶的生产率提升，
并且可以完成那些离开了这些工具就不可能完成的事情。
但是正如工具的构造者所告诉你的，拥有恰当的技能去使用工具，这一点才是最关键的。
所谓凿子，在米开朗基罗拿起它之前，只是拥有锋利边缘的铁块而已。
最好的团队使用主面板，让大家把精力集中于在正确的时间做出最重要的决定和采取最重要的行动。
弱团队则使用主面板以责备其他人或者转移其他人的责备（通过着重强调好消息）。
团队的前进动力并非缘于对成功的一腔热情，而是对批评心有余悸。
在很多项目团队看来，根本就没有最终决定一说。
表面上服从决定，随后却继续发出反对的声音。
这种行为导致最糟糕的后果是把项目最宝贵的资源——时间——白白挥霍掉了。
其实，无休止的争辩的根源在于团队的领导者。
只要领导者容忍一天，不认同决定的团队成员就会争辩一天。
这取决于领导者是否认识到该在何时结束这种争辩，勇敢的做出决定。
成熟而专业的组织的一项特点就是拥有有效的决策流程，里面包含了决策制订和后续事宜处理的规则。
美国海军陆战队关于军事理论的简明出版物，就包含了一系列被充分理解的决策规则。
在指挥官做出决定之前，每位下级都有责任有义务诚实的提出个人的专业意见——即使这些意见可能会和上级的不一致。
但是，一旦决定做出，每位下级都应该把它当做自身的决定，毫不迟疑的遵守。
服从决定和认同决定二者之间存在区别。
费劲的说服别人去认同自己的看法是没有意义的。
如果人们抱有不同的看法，即使某个人做出了决定，也无法改变他们的看法。
但遵守决定意味着无论认同与否，每个人都应该采取规定好的行动，而不是把精力放在抗议决定上面。
避免无休止的争辩需要有一个适合具体项目的决策流程。
当人们认为只有经过他们同意才能让他们遵守决定的时候，无休止的争辩就产生了。
这时，项目经理应该站出来，建立规范让人们遵守决定。
而且让人们认识到，一旦决定作出，就必须无条件的接受。
要想组织停止沦为老员工（或者“非常老”员工）之家，最明显的办法是雇佣年轻人。
但这并不是每个人都能做到的，首先，必须有空缺职位，然后，必须愿意在新员工身上投资。
无论如何，招聘一些兼职的大学生总是非常容易的。
况且，还有大量的暑期实习生呢。
更何况还有课后工作的高中生呢。
对于如何纠正他所发现的缺陷，他也不提出任何建设性的意见，只是一味的对你们处理事情的方式表示忧虑。
所有影评人都有一个共同的特征，他们相信即使自己所处的项目失败了，他们也能成功。
实际上，他们已经悄悄的与项目团队背道而驰。
一些项目的运作原则是每一件事的责任都由所有人共同承担。
这样的想法表面看起来非常值得赞叹。
但毫无悬念，这种方法很少奏效。
每个人都需要操心（或干涉）每一件事，却无法把其中任何一件事情做好。
之所以能够进行单一问责，是源于这样的一种自信，即人们清楚的认识到其他人对自己的期望。
苏式风格：交付的产品包含了客户要求的功能，但却不受客户待见，很快就被搁置一边了。
自然权力：能力吸引权力。
知识工作与生产工作极其不同。
在生产环境中，工人们追求一个共同的，简单定义的目标，完成任务所需的技能对于所有人都是一样的。
老板通常是技术精通者，而且对生产线以及生产线工作机制的理解也最深刻。
因此，在需要决策的时候，老板很自然是做出决策的那个人。
知识工作则是另一种情形。
技能是多方面的，从不同角度看问题得到的结论也不同。
如果决策牵涉到一个或多个团队成员的知识领域，那些成员才应该是真正的决策者。
如果决策影响到团队之外的其他人，具备相关领域知识的团队成员至少需要参与到决策制订的过程之中。
在特定领域学识渊博的人被认为是权威，而某人主管某一项工作则被认为是掌权。
权威很可能没有掌权，掌权的人却可能不是权威。
良性的模式是——无论身为权威的人是否手握权力，都应该由他们来做出每一个决策。
同时，可能是由掌权的人负责监督决策的实际执行，而不是决策。
与该模式相反的形式同样显而易见，决策的制订流程遵循组织结构，而不是遵循知识和技巧。
身居更高职位的人负责做出大部分决策，有时甚至都不咨询一下那些对问题有更深刻理解的人。
另一种情形是组织基于价格因素来做出技术的决策，即费用更贵的决策由职位更高的人来制订。
违背自然权利的流动规律，听上去很像是在滥用职权，仿佛全部都是经理的过错。
但在某些情形下，相关领域的专家也应该感到脸红。
经理会放任自流，为所欲为，以致自食其果。
而拥有重要的和必要知识的人们只是坐在一起，闷闷不乐的默许别人在眼前做出错误的决策。
除非被特别要求，否则他们不会提出任何意见。
这是对责任的放弃，因为沉默即同意。
对于错误的决策，沉默的专家与无知的经理们都要负上同样的责任
万籁俱寂的办公室：办公室太安静了，凸显出团队已经失去了活力源泉。
白线：项目团队借用网球场上的“白线”，来界定需求的范围。
很多项目都没有白线。
人们试图借助于特性列表或者目标声明来区分哪些需求属于系统范围之内，哪些需求则不属于。
然而这两种做法都不够精确，无法成为实用的白线。
你是在通过声明需要修改的系统/业务领域与直接交互的外部世界之间的每个接口来定义项目范围。
一旦该工作完成，系统范围就不再有任何的歧义，你已经借助于接口绘出了白线。
如果组织内部产生了不满，这些不满经常是集中于那些没有达成一致理解的隐式承诺上面。
承诺被误解的情形通常是，一方表达了需求，然后另一方点头示意明白。
前者把这种情形理解成一项承诺，后者则视为痴人说梦。
“沉默即同意”式的承诺对每个人都不利。
双方不可避免的给工作定义出不同的优先级，最终的结果必然是惨淡收场。
要使隐式承诺易于管理，一个行之有效的方法是公开声明少量的重要承诺，把它们写下来，然后共享给所有的相关人士。
承诺书没有必要，短短的承诺列表即可。
上面列出承诺者的姓名，承诺达到的确切结果和确切日期。
在这种情形下，承诺者必然把公开承诺的优先级调的高于自己台面上的其他工作。
客户之所以弄不清楚自己想要什么，是因为他们对自己所能得到的东西一点概念也没有。
最好的分析师从来不会试图去分析了客户的所有问题后，再拿出解决方案。
他们分析得出一些理解，对解决方案的整体或者部分作出最小的投入，然后把解决方案快速交给客户，寻求客户的反馈。
人们天生就是高效的改进者，而只有极少数会愿意从零开始。
最好的稻草人模型可能甚至包括一些有意为之的错误。
分析师故意弄错模型，以保持客户的警惕性，同时释放出一种信号——针对模型畅所欲言的批评都会被完全无保留的接受。
无论人们何时迭代式的寻求解决方案，稻草人建模都是非常有效的。
“稻草人”的哲学是尽早犯错，频繁犯错，这样你将会尽快得到正确的结果。
很多人自认为已经在使用“稻草人”的策略，但是否曾有人指着你的模型大加嘲笑？
那才是“稻草人”。
如果按照慎重的估算得到的时间完成项目，那么多余管理层而言，项目的成本就太高了。
于是，虽然每一个有判断力的参与人员都说项目需要两年时间，但疯狂的管理层还是把计划时间定为一年。
要识别是否属于伪造的紧急性，我们需要仔细查看项目可能产生的收益。
如果收益千真万确，十分可观，那时限一年的计划安排绝对意味着头脑发热的冒险行为，兴许头脑太过于热了。
假如果真能得到如此重要的收益，为什么不多分派一些时间认真的去做这件事呢？
更普遍的现象是，所谓的收益其实只是微不足道的，这也解释了为什么组织没有投入全部的精力。
明显冒进的计划安排实际上只是制约开销的策略。
伪造的紧急性会引发伪造风险。
项目惨淡收场，但这还不是最坏的情况。
最坏的情况是组织没有抓住真正的商业机会去从事高价值的项目，而那些项目的风险都是值得去尝试的。
经理在项目初期的决定对项目的影响很大。
当为期10个月的项目刚开始2个月时，增加一个开发人员和一个测试人员也许还有助于准时交付完整的功能。
然而，当项目仅仅剩下2个月时，再增加开发人员和测试人员恐怕就于事无补了。
事实上，这样可能还会给团队带来负作用。
时间也会在“下一个发布版本应该包含哪些特性”的问题上做出短时的决定。
“哪些应该算作核心功能？”这个问题的答案很简单，“迄今为止所有完成的功能都算”。
基于这个结论，你可以得出等式，“完成的功能=核心功能”。
既然该功能已经完成，那它必须包含在此次发布里面。
你不由得啼笑皆非。
它们分配一些预算对问题域进行探索，以判定可能发生的情形，以及针对该问题域启动项目的切实可行性。
项目团队中的探索者从抽象的角度来开展探索工作。
他们不关心谁在处理什么，或者涉及了哪些机器和个人。
相反，他们检查各种条件，看能引发什么点子，产生什么机会，以及该工作未来可能是什么情形。
他们寻求着机会和点子，这些机会和点子一旦被证实，将会给探索的发起机构带来最可观的潜在收益。
对于组织而言，保持与竞争对手一样低水平的费用开销是至关重要的。
很显然，太多的成本削减会导致组织缺乏竞争力，最终甚至引起成本的增加。
我们需要区分成本削减和组织的贪欲。
作为经理，你应该抑制住操纵节奏或者通过加快节奏以提高生产率的欲望。
团队建立起自己的节奏，驱动着团队进行有规律的交付。
无论艰巨任务还是日常事务，如果能够按照持续的节奏去做，它们都会变得易如反掌。
想想翻越高峰的目标，采取有规律的步调建立起属于你自己的节奏。
经理们，特别是年轻的经理们，都很乐意看到手下的人把额外的空闲时间投入到项目上。
他们把这视为一种信号，表明自己在团队鼓舞和个人激励方面做得很好。
每个人正如预期的一样，都是态度坚决的把项目带回家。
但是，这也有可能源于人们在工作中产生的无望感，早期的，持续的加班很可能表示项目团队正处于恐惧之中。
对于组织中平时不常打交道的人而言，培养他们之间的私人关系对于组织中的重要工作可以起到润滑剂的作用。
仅仅是文档通过语法完备性检查并不能说明它就复合了目标。
拥有错误质量关卡的组织关注交付物的语法和形式，却忽视了内容。
如果你使用的是错误的质量关卡，就会发现质检过程传回来的大多数反馈都是关于交付物的形式，而不是交付物的内容含义。
该模式把时间浪费在不具备产出性的步骤上面，而且更为严重的是，与内容相关的缺陷却溜进了最后的产品之中。
早期测试的目的是给后来阶段的测试提供精准的标准以衡量解决方案。
在测试阶段之前的测试意味着在最开始的项目讨论时期就引入质量控制。
在采用早期测试的项目中，早期的交付物在下一步骤开始之前都会被测试检查，看是否值得继续。
这种早期测试的关键在于尽可能早的揭晓尽可能多的错误概念，误会，冲突，不现实的期望等。
“苹果酒屋规则”的问题在于制订规则的人并不在苹果酒屋里面居住，也没有任何搬进去住的想法，却反而由她来给住在酒屋里面的人制订规则。
一些开发组织也制订了类似的苹果酒屋规则。
没有参加项目实际工作的人给那些参加项目实际工作的人制订规则。
这样的组织往往存在着一个流程改进部门，或者成为标准组，又或者叫做质量部门，它们的工作就是规定工作的流程或者方法。
这些部门兴许还会为项目选择工具，或者为项目的交付物制订标准。
这些都是由外行来制订规则指导项目团队应该怎样工作，而他们对于工作甚至都没有一点靠谱的理解。
书写把对话持久化下来，而记忆不可能做到这一点。
用书面方式交流决定，可以为那些没有在场或者忘记细节的人们保存决策制订的对话过程。
在这个成本削减和雇员缩减的年代，涌现出了一种舆论，它认为公司并没有全力开发足够多的软件，因而失去了建立真正战略优势的机会。
如果你对这一舆论颇以为然，不妨花几分钟反过来想想，也许IT公司正在开发太多的软件。
在21世纪，似乎所有的事情都应该在昨天完成。
接受超出团队处理范围的工作是管理层怯懦的表现。
为了避免个人遭受指责，却亲手把团队置于不可能成功的境地之中。
最终，团队会饱受超负荷工作之苦，在组织里面受到的尊重度下降，就因为你没有勇气在第一时间说“不”。
怎么做才能逆转这种恶性循环呢？
给工作任务排定优先级，只做你最大能力范围之内的事情。
把低价值的工作放在一边，先完成高价值的工作。
承担超出最大能力范围的工作是变得迟缓的罪魁祸首。
大家无视这个问题解释了为什么如此多的组织因为试图完成大量的工作而让自己慢到几乎停滞。
作为一个名副其实的领导兼经理，她没有给团队的其他成员安排任何重要的领导或管理工作。
结果自然就是她没有把它们作为领导来培养。
信息冗余导致注意力涣散。
当吸引注意力的信息量太多时，我们会处在超负荷的状态之中。
即使信息再多，又有何用？
如果在你的组织里面，所有人都需要知道所有的事情才能完成工作，那你可就前景不妙了。
太多的信息可能是一件坏事，这一点无论如何强调都不过分。
但更大的问题在于首先理解为什么我们让自己承担如此之多。
至于我们给自己加上信息的重枷，一个更常见的原因是信息焦虑——害怕自己不知道别人知道的东西。
知道多少信息是和自己的信息餐碟，不仅仅是一项好的策略，而且是成长的一部分。
同事预审：组织让将来与应聘人共事的员工也参与到招聘过程中来。
浮潜与水肺潜水：不同形式的分析活动贯穿项目的整个生命周期，自上而下，自下而上以及先中间后两边。
在相同的时间内，浮潜潜水员可以游历更宽阔的水域，而水肺潜水员则能潜游得更深入。
成功的项目团队在项目的整个过程中会把浮潜和水肺潜水这两种方式结合起来使用，在特定的时刻明智的选择合适的方法，从而有效的利用时间。
浮潜是一项很好的技术，项目团队可以用它来弄清楚需要研究多少领域，以理解问题和达成目标。
当潜水员感觉到一些有趣的东西，陌生的事物或者更深的细节信息需要考察时，他会进行较深的水肺潜水。
深度潜水的发现常常会改变浮潜阶段所作出的假设。
本模式的反例是团队要么沉迷于细节，要么惧怕细节。
并且，人们谈论起“更高层次”和“细节”就好像它们是独立的东西，与正在从事的项目无任何关联。
优秀的开发人员不会画地为牢，它们即可以浮潜，也能水肺潜水。
他们依据自己需要考察的对象来选择技术。
侦察的时候，浅层潜水就已足够，但如果审察，就需要更深的潜水了。
康威定律：产品反映了制造该产品的组织结构。
对于接口，这一点尤为正确，项目中复杂的人类接口容易导致复杂的产品接口。
绝对服从可能是有害的，某些善意的无序反而是有益的。
在有些组织里面，坏消息从来不上报。
更为普遍的是，坏消息在一级一级往上传达的过程中被美化了。
消息美化是一种破坏性模式，因为它使决策者得不到所需要的信息，这又可能导致错误的决策，结果反而更糟。
如果信息流动更为有效，那么许多众所周知的错误决策原本可以避免。
当你在项目中观察到这个模式，最典型的症状是出现意外，典型的后果就是延误了一个又一个截止日期，从而达不到期望的结果。
刻意隐瞒坏消息可能使得可解决的问题变成无法解决的问题。
那些原本能对意外的延误有所作为的少数人——控制着资源，给项目设定外部期望的高级经理——得不到采取纠正举措的机会。
如果他们可以在足够早的时候就知道待完成的工作与可用的资源和时间之间的关系不对等，他们就能在足够早的时候提供更多的资源，或者重新调整范围，或者延长计划时间，以避免在最后关头出现延误。
送来坏消息的人会吃到苦头，消息美化就变得不可避免。
团队成员在他们能够证明之前，就知道项目陷于困境。
在有些文化之中，声称达到预定日期有问题的团队成员很有可能会遇上那个臭名昭著的质疑，“你怎么这么肯定你们无法做到？”
由于不想被视为悲泣者或者懦夫，团队成员就此缄口不言，直到灾难已经无可置疑（而且通常也是无可避免）。
经理不能仅仅在口头说希望即时得到坏消息，还得那样去做。
最起码，这意味着把坏消息的反应分成两个部分。
（1）决定如何处理（2）弄清楚它是怎么发生的。
首先关注第一部分，不要马上清查为什么坏事情会发生。
相反，把精力放在督促团队上面，提出“改进”计划，然后落实到行动。
许多文化都会传达出这种信号，那就是——如果你发现了杂乱不堪的现象，你就得负责清理。
指出问题，却又不立刻提出改进措施——这会被认为是在发牢骚。
在很多组织里面，发牢骚的职业生涯是有限的。
对于每个人都承认的失败，如果不想办法去改进，去汲取教训，那么同样的失败会一再发生。
在项目结束的时候召开经验学习会议是朝着正确方向迈出的一步，但它还不够。
很可能即便仔细检视了以往的行为，却依然无法获得回报。
项目结束之后举行回顾会议的项目往往发现自己强调的问题，在严格意义上都不是项目内部的问题。
这些问题根源于外部给项目强加的约束。
因为这些问题都超出了团队的范围，它们的解决方案可能会被认为是僭越了职权。
虽然我们忙得焦头烂额，但是要把完全处于团队范畴之内的变更落实到实处，其实难度很可能非常大。
怪不得回顾有时变成了单纯的抱怨会议，也没有严肃的意愿来改变任何事情。
当经验学习的过程主要是以发泄而结束时，你会发现公布的结果都是人们的观察结果，而不是行动事项。
关键在于坚持为每一个明确的问题（不论是团队权力范围之内还是之外）制订具体的行动方案。
把找出来的每一件没有帮助到团队或者曾经阻碍过团队的事情，与将在下一次迭代或者版本（又或者下一个项目）中付诸实践的某一项行动事项关联在一起。
这样就把经验学习的团队带入了建设性设计的模式。
开这种会时，还有一个操作上的小技巧。
那就是让每个人最少准备关于项目的一件好事情和一件坏事情出席会议。
一个相似的技巧能够帮助团队在回顾时成功激发变更。
坚持至少有一项行动方案完全属于团队范畴之内，并且至少有一项行动方案是部分或者全部属于团队之外。
每一项行动事项都应该指出将如何修改某些方法，任务，人机界面或者强加的约束以避免下一次出现同样的问题。
行动方案必须明确，而且它们必须拥有一个特定的目标指引变化的进行，让变化落实到那个目标。
The text was updated successfully, but these errors were encountered: