**響了。
「我們想這週完成需求的規格說明書。你能過來看看可以做些什麼嗎？」
「規格說明書怎麼了？」
「我們很急，所以新招了許多人來寫規格說明書。我們覺得他們完全不清楚自己在做什麼。」
「如果由我們來指導他們編寫需求，效率不是更高嗎？」
「但是我們這週就需要規格說明書。」
「好吧，我明天過來。」
兩個小時之後。
「你能過來看看我們的預估結果嗎？」
「規格說明書怎麼辦？」
「我們沒時間了。我們就照現有的需求規格說明書進行。老闆要求今天就把預估結果交上去……」
你可能已經發現這一類「心跳遊戲」（adrenaline junkie）型組織的特點了：優先順序總是變化不休，所有事項都是「昨天」就要，總是沒有足夠的時間交付專案，每個專案都是加急專案，而且加急專案還在不斷出現。每個人都忙得焦頭爛額……永遠如此。
這些組織裡面的人不會思考戰略層次的問題，只是按照緊迫程度來完成工作。除非「忙亂指數」非常高，否則該指數通常都會被忽略——儘管重視它很有可能會帶來顯著的長期優勢。人們會一直對其不聞不問，直到它突然（絕對出乎意料地）變得要緊了。「玩的就是心跳」分子相信最好的工作方式不是先規劃再行動，而是越快行動越好。
這種文化認為緊迫性越高的專案，收穫也越大。如果身處這種文化之中，你很難不受感染：越緊迫越好。因為給專案的時間短得荒謬而通宵加班的程式設計師被視為英雄（根本不在乎他們交付的程式質量）。每個週末，團隊的所有成員都照常上班，以保持他們的工作量：這樣做的團隊比不這樣做的團隊更受人讚許。此外，如果你不是一直都過度加班，或者沒有發瘋一般忙碌，就會被貼上「局外人」的標籤，你不是保障組織運轉流暢的大忙人之一。非英雄行為是絕對不能接受的。
絕大部分的「心跳遊戲」型組織至少存在乙個瓶頸，就是那位英雄。他是所有設計的決策者，是全部需求的唯一**，也可能包辦整個架構。他扮演了兩個角色：一是讓自己表現出常人無法想象的忙；二是引發決策僵局，他的決策一旦公布，就會導致組織的其他部分更加忙亂。
大部分的「心跳遊戲」型組織滿腔熱情地擁抱服務客戶的教條：他們混淆了對緊迫事件的響應和值得讚賞的響應。只要客戶提出了請求，不管是否能帶來收益（甚至不管有沒有用），都會立即轉化成專案，而且通常截止日期會短得可笑。（更多討論，請參閱模式38。）這個新專案自然會加重已經在超負荷工作的英雄們的負擔，使他們更加手忙腳亂——永不停歇的需求讓組織變得異常忙碌。很多這類的組織都（錯誤地）認為這就是敏捷的全部。
「心跳遊戲」型的行動是貿然的，而不會經過思考。其結果就是大部分工作都處在不斷變化、無法固定的狀態，沒有什麼可以固定下來，也沒有什麼可以保持較長的時間。這種不固定的狀態一直延續：需求規範不固定——沒人真正清楚要開發什麼；設計和計畫也不固定——它們很可能明天就會改變。緊迫性是唯一的標準，沒有人嘗試按照重要性或者工作價值來給工作排定優先順序。
對於「心跳遊戲」型組織，特效藥是不存在的。他們沒救了，除非取消那些令人心跳加速的任務，同時解雇經理，雇用那些明白「組織只有不再忙於處理突發事件才最有效率」的人。但是這樣的人事變動根本不可能被採納，因為高層領導，通常是ceo，希望看到組織長久地保持匆忙的狀態，工作匆忙會給人高生產率的幻覺。而且，如果公司的經理們迷信「玩的就是心跳」，專案團隊也會效仿。
「心跳遊戲」型組織並不是總會失敗，他們當中有一些在多年裡一直保持著匆忙的節奏。但是，它們都不可能構建重大的東西——那需要穩定性和計畫。亢奮型行為不可能擴充套件——由一些相對較少的人在沒有方向，也沒有戰略指導的前提下，只憑藉非常、非常忙碌的工作，成果十分有限。
當然了，各種組織內都有緊迫的事情，也需要有一些角色去關心緊迫的任務。但是，不是所有的事情都是緊迫的，也不是所有的角色都要關心緊迫的任務。除非化緊迫性為優先順序和約束，否則，這種「心跳遊戲」的**希望是微乎其微了。
從開工起，專案就完全不可能完成目標，專案團隊中的大多數人都很清楚這一點，卻緘口不言。
很多it專案的目標可以被扼要地概括為：我們要在截止日期之前，完成這一系列功能，達到這種準確度，並且保證足夠的健壯性。於是專案團隊組建起來，專案目標和約束條件落實為詳細的需求和設計，然後發布。
天大的秘密是，專案團隊中沒有乙個人相信專案最終能成功。通常看來，如果其他目標不作修改，期限是不夠的。難以思議的是，並沒有人指出，失敗的陰影正如散發惡臭的大死魚，把專案變得臭不可聞。
於是希臘式悲劇拉開帷幕，專案進行得步履維艱。毫無意外，在預期交付日期之前的幾周，所有的專案成員、專案經理、專案經理的上司以及任何與專案沾點邊的人，要麼——
(1) 對於專案沒有按照即將到來的發布日期進行，表示震驚、氣餒、詫異；
要麼——
(2) 保持低調，除非被點名問到，否則對任何事情都保持沉默。
為什麼如此多的組織裡面有如此多的人會用除臭劑掩蓋實情，而不是直接指出「專案現在的方式不是我們所希望的方式，死魚就在那兒」呢？
很多組織過於看重成功，所以任何表達疑慮的人都不會因為說真話得到任何獎賞。事實上，如果誰在專案的前期階段就聲稱死魚的存在，管理層的第一反應多半如下。
「證明給我們看。給我們證明成功的可能性是零。不要拿以前專案的死魚經驗來唬人。現在的專案不一樣。請用嚴密的數學證明來告訴我們失敗無法避免。」
一旦你提出任何缺乏精確證據的東西，就會被指責為軟蛋或者是試圖逃避辛苦紮實的工作：
「你是軟蛋還是懶漢？自己選擇吧。但是我們懷疑你還能在這個奮進的組織裡面待多久。」
在這樣的環境裡面，「努力」而無法完成比站出來說目標無法達到更安全。確實，有時我們需要勇於面對挑戰，在認輸之前真正地拼搏一番。非常正確——但區別是，在有確定截止時間的艱難專案中，沒人會挨到最後一刻才宣告情況的危急。如果專案是給只有18個月後就要發射的通訊衛星開發軟體（你知道如果錯過了這次發射時間，就只能再等16個月），那麼，你們每個人每天都要聞一聞專案有沒有出現什麼異味。只要聞到一絲腥味，你就應該喊出來，因為你非常清楚，如果遇到「死魚」專案，不到最後時刻是沒人說話的。
非常清楚的是，「死魚」不僅給組織帶來破壞影響，而且挫傷了「死魚」專案團隊成員和經理的士氣。無論組織文化如何，沒有人會覺得長期呆在發臭的「死魚」專案裡很舒服。嚴密封鎖「死魚」訊息的成本實在太高。
獻給「蒙特•派森」①迷們：
「專案還沒死，它正在附住峽灣！」
「專案沒有死，只是在蛻皮！」
「這專案已死。它已經駕鶴西去了。」
「現在上場的是完全不同的模式……」
monty python，英國喜劇六人團，出演了系列電視喜劇片。——譯者注在傳統的英式文化中，保姆受僱於某個家庭，負責照看孩子。保姆通常要具有教師、**和廚師的技能，全面負責孩子的體格、心靈、社交、創造性和智力發展。在每天的日常活動中，保姆要確保孩子遠離傷害，保證孩子們得到足夠的新鮮空氣與鍛鍊，吃到有營養的食物，加深對世界的理解，掌握更多在世界上生存的技巧。除了照看孩子，保姆還需要促進孩子天賦的發展，並與家長溝通對孩子成長方面的顧慮。保姆要建立出安全的環境，使孩子能適當冒險並從中學到新知。
經理們如果擁有這些與保姆類似的才能，就能通過鼓勵和培養員工的天賦，從員工那裡獲得更多、更好的工作成果。
迄今為止，我為之工作過的最好的經理是peter ford。這再明顯不過了，比如他讓員工在工作時各盡其能。舉個例子，我們在一大間開放式設計辦公室工作，這不是最好的思考環境，於是他設法為團隊弄到一些隔音屏風，並保留了幾間「靜音室」。所有的這些，還有他為我們做的其他事情，要用到談判能力和手腕，卻不讓我們知道。他鼓勵我們在系統開發的時候多閱讀並討論新的想法。他為團隊買來書籍和雜誌，並安排時間讓我們聚在一起討論。當我們覺得不開心或者不舒服的時候，他會注意到這一點，跟我們交談，幫助我們。他保護我們不受組織其他人和事的干擾，但如果他對我們不滿意，他會讓我們知道。他辦公室的門很少關著。peter就是我們的保姆。
——sqr
你所在的組織或許已經有一些「保姆型」經理，如果你留意，會發現這些現象：不必預約就能見到你的頭兒，或者不必在瑣碎和令人生厭的管理工作上花費太多時間。周圍是開放的氛圍，人們暢所欲言，互相學習。這種經理認為培訓或進修非常必要，而不是視之為燒錢。他們還會專門安排時間（比如早晨咖啡閒談或者周五下午閱讀**），讓大家在一起討論新想法。
只要有人聚在一起，總會有流言蜚語、小道八卦和一些磨洋工的情況。然而，在被經理細心呵護的辦公室裡面，這類浪費時間的事情極少，因為經理確保團隊成員對於實際發生的事情都非常清楚。人們不需要去打聽小道訊息來了解組織內發生的事情。與之相反，他們覺得自己充分知情和受到信任，把精力都放在本職工作上面。
類似於保姆的經理會把自己看成是工作的催化劑。傳統保姆的工作滿意度來自於看到孩子能力的發展，「保姆型」經理的工作滿意度則來自於看到每個團隊成員在個人角色方面得到發展、生產率得到提高，並對自己的工作更加滿意。
這個模式的反面是這樣的：經理關心的是爭權奪利、發號施令、制定流程，逢迎上級；繪製、調整pert圖和甘特圖比與團隊成員交談更重要；還有一些經理自己做了太多的實際開發，而沒有解決好團隊的需求。
你們的組織如何看待經理的角色？他們會因為「催化」了工作受到讚揚嗎？你們僱傭的是「保姆」還是「管理者」？
《專案百態 軟體專案管理面面觀》三模式總結
其中顯著的表現為 他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益 甚至不管有用沒有 都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。這種 心跳遊戲 型的行動是貿然的，思考極其...
《專案百態 軟體專案管理面面觀》三模式總結
專案百態 軟體專案管理面面觀 三模式總結 其中顯著的表現為 他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益 甚至不管有用沒有 都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。...
簡化的軟體專案管理
1.角色定義 a 專案經理 b 需求人員 c 設計師 d 開發人員 e 配置人員 f 測試人員 g 資料庫管理人員 2.軟體開發的各個階段 a 需求分析 b 概要設計 設計系統架構,以及業務相關的基礎框架 c 詳細設計 1.編寫詳細設計文件,包括ui，uml類圖，操作流程說明，相關sql,資料庫表說...