項目行爲模式

模式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）
有限發佈 （不包含功能的發佈）
讓我澄清我要什麼 （新需求來了）
我們在考慮我們的選項 （只有一個）