模式一：《玩的就是心跳》
其中顯著的表現為：他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益(甚至不管有用沒有)，都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。
這種「心跳遊戲」型的行動是貿然的，思考極其的膚淺，其結果就是大部分工作都處在不斷變化，無法固定的狀態，需求永遠在變更的路上，沒有真正清楚要開發什麼，給誰用?盲目的去做，他們很明天就改變，緊迫性成為他們唯一的標準，沒有人嘗試按照重要性或者工作價值來給工作排定優先順序
對於「心跳遊戲」型組織，特效藥是不存在的，他們沒救了，除非取消那些令人心跳加速的任務，同時解雇經理，雇用那些明白「組織只有不再忙於處理突發事件才是最有效」的人。但是這很難，通常ceo希望看到組織長久的保持匆忙的狀態，工作匆忙會給人產生搞笑的幻覺。
所以我們不要把所有的事情都變成緊迫的，緊急的，專案組裡不需要所有的人都去關注緊迫的，緊急的事情，杜絕讓自己的團隊變成這種文化的團隊，因為在這種團隊中你很難不被感染。我們需要化緊迫性為優先順序與約束，必要的時候需要跟領導說「不」。
模式二：《快，趕上》
高效的團隊在會上就開始處理商定的事項，
高效的團隊認為立即動手反而更容易。
強團隊的表現：
1、他們對於時間的緊迫性有些內在的直覺
2、他們對個人和集體的能力非常有信心。
3、他們相信迭代的價值。
相比弱團隊的表現
1、要求完美的資訊，有些公司的文化把不犯錯
看的比完成任務還重。
2、弱團隊更傾向於推遲他們的決定和行動事項
3、未定事項會議組織雜亂，新想法層出不窮主題不斷變化，新問題源源不斷，但卻沒有乙個人有答案
4、條條大路通設計
5、開會安排額外的會議
模式三：《死魚》
從開工起，專案就完全不可能完成目標，專案團隊中的大多數人都很清楚這一點，卻默默無言。
很多組織過於看重成功，所有任何表達疑慮的人都不會因為說真話得到任何獎賞。事實上，如果誰在專案的前期階段就聲稱死魚的存在，管理層
的反應多半會如下：
「證明給我們看」，證明成功的可能性為零，或者拿其他成功的案例去睡服你，你必須用嚴密的邏輯與數學證明來告訴他，我們失敗無法避免。否則一旦你提出任何缺乏精確證據的東西，就會被指責為軟蛋或者是試圖逃避辛苦紮實的工作;你是軟蛋還是懶漢?你自己選吧。但是我懷疑你還能在這個奮鬥的組織裡待多久。
在這樣的環境裡，「努力」而無法完成任務比站出來說目標無法達到更安全。確實，有時候我們需要用於面對挑戰，在認輸之前真正的去拼搏一番。非常正確–但區別是，在又確定截止時間的艱難專案中，沒有人回熬到最後一刻才宣告情況的危急。那麼，我們每個人都要聞一聞專案有沒有出現什麼異味只要聞到一絲腥味，你就應該喊出來，因為你非常清楚，如果遇到「死魚」專案，不到最後時刻是沒有人說話的而「死魚」不僅給組織帶來破壞影響，其更加的挫傷了「死魚」專案圖案鬼成員和經理的士氣。無論組織文化如何，沒有人會覺得長期呆在發臭的「死魚」專案裡很舒服。嚴密封鎖「死魚」訊息的成本實在太高。
軟體專案管理 三 軟體專案範圍管理
專案範圍對專案的影響是決定性的，它確定了軟體專案工作內容的多少。有效的範圍管理可以保證專案只做必須做的事情，避免範圍蔓延和做無用功，同時也避免不清晰的需求所導致的嚴重的系統缺陷 需求獲取工作的任務就是收集專案干係人的需求資訊，為定義專案的範圍奠定基礎。需求獲取工作只能通過使用者與開發人員之間進行高度...
《專案百態 軟體專案管理面面觀》三模式總結
其中顯著的表現為 他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益 甚至不管有用沒有 都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。這種 心跳遊戲 型的行動是貿然的，思考極其...
《專案百態 軟體專案管理面面觀》三模式總結
專案百態 軟體專案管理面面觀 三模式總結 其中顯著的表現為 他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益 甚至不管有用沒有 都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。...