《專案百態：軟體專案管理面面觀》三模式總結
其中顯著的表現為：他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益（甚至不管有用沒有），都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。
這種「心跳遊戲」型的行動是貿然的，思考極其的膚淺，其結果就是大部分工作都處在不斷變化，無法固定的狀態，需求永遠在變更的路上，沒有真正清楚要開發什麼，給誰用？盲目的去做，他們很明天就改變，緊迫性成為他們唯一的標準，沒有人嘗試按照重要性或者工作價值來給工作排定優先順序
對於「心跳遊戲」型組織，特效藥是不存在的，他們沒救了，除非取消那些令人心跳加速的任務，同時解雇經理，雇用那些明白「組織只有不再忙於處理突發事件才是最有效」的人。但是這很難，通常ceo希望看到組織長久的保持匆忙的狀態，工作匆忙會給人產生搞笑的幻覺。
所以我們不要把所有的事情都變成緊迫的，緊急的，專案組裡不需要所有的人都去關注緊迫的，緊急的事情，杜絕讓自己的團隊變成這種文化的團隊，因為在這種團隊中你很難不被感染。我們需要化緊迫性為優先順序與約束，必要的時候需要跟領導說「不」。
高效的團隊在會上就開始處理商定的事項，
高效的團隊認為立即動手反而更容易。
強團隊的表現：
相比弱團隊的表現
從開工起，專案就完全不可能完成目標，專案團隊中的大多數人都很清楚這一點，卻默默無言。
很多組織過於看重成功，所有任何表達疑慮的人都不會因為說真話得到任何獎賞。事實上，如果誰在專案的前期階段就聲稱死魚的存在，管理層
的反應多半會如下：
「證明給我們看」，證明成功的可能性為零，或者拿其他成功的案例去睡服你，你必須用嚴密的邏輯與數學證明來告訴他，我們失敗無法避免。否則一旦你提出任何缺乏精確證據的東西，就會被指責為軟蛋或者是試圖逃避辛苦紮實的工作；你是軟蛋還是懶漢？你自己選吧。但是我懷疑你還能在這個奮鬥的組織裡待多久。
在這樣的環境裡，「努力」而無法完成任務比站出來說目標無法達到更安全。確實，有時候我們需要用於面對挑戰，在認輸之前真正的去拼搏一番。非常正確–但區別是，在又確定截止時間的艱難專案中，沒有人回熬到最後一刻才宣告情況的危急。那麼，我們每個人都要聞一聞專案有沒有出現什麼異味只要聞到一絲腥味，你就應該喊出來，因為你非常清楚，如果遇到「死魚」專案，不到最後時刻是沒有人說話的而「死魚」不僅給組織帶來破壞影響，其更加的挫傷了「死魚」專案圖案鬼成員和經理的士氣。無論組織文化如何，沒有人會覺得長期呆在發臭的「死魚」專案裡很舒服。嚴密封鎖「死魚」訊息的成本實在太高。
《專案百態 軟體專案管理面面觀》三模式總結
其中顯著的表現為 他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益 甚至不管有用沒有 都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。這種 心跳遊戲 型的行動是貿然的，思考極其...
軟體專案管理面面觀之「玩的就是心跳」
響了。我們想這週完成需求的規格說明書。你能過來看看可以做些什麼嗎？規格說明書怎麼了？我們很急，所以新招了許多人來寫規格說明書。我們覺得他們完全不清楚自己在做什麼。如果由我們來指導他們編寫需求，效率不是更高嗎？但是我們這週就需要規格說明書。好吧，我明天過來。兩個小時之後。你能過來看看我們的預估結果嗎？...
《專案百態》讀感系列」蘇式風格「
有些人問了，為什麼交付的產品包含了使用者要求的功能，卻不招使用者待見，很快就被擱置一邊了。喬幫主會這樣回答你，蘋果的產品能俘獲眾多使用者的心是因為注重使用者體驗，關注細節。在我們每個人的專案實踐中多多少少都會更關注需求，功能的實現，而忽視了使用者體驗。但是，請諸位先換位思考下，現在我是使用者，對於乙...