「只要參與過一兩個軟體專案，就一定對書中介紹的情景深有感觸，也必然會從中得到經驗教訓」這是《軟體隨想錄》的作者joel spolsky對這本書的感受。
以下我也結合自己實際的工作體驗對這本書中的模式場景說一下自己的感受：
模式「玩的就是心跳」大概介紹的就是這樣一種場景，在工作中永遠都是緊迫的專案，在專案中永遠都是緊迫的功能，專案組永遠處於緊迫忙碌的狀態中，試問這樣團隊怎樣能有高質量的產出？
對於這種模式我深有體會，就拿我所在的研發部門引入敏捷開發的第一年來說，我們部門接手了乙個大專案，先說說它的規模：分為web端，通訊伺服器，客戶端。模型：客戶端<--->通訊伺服器<--->資料庫，web端<--->資料庫，web端包含公共模組和對九個子產品的管理審計功能，客戶端也會有九個子產品需要開發，其中還有分級支援，外圍管理工具等等......。整個部門十幾號人都參與進這個專案。起初，定的計畫是半年完成框架的構建和四個子產品的研發並且推向市場，說心裡話，除了上層外，估計大多數人都認為這是不可能完成的任務，於是隨之封閉開發和加班幾乎佔據了我們的生活，很累，很累。但是半年並沒能完成任務，我們的問題總結：前期有需求定位錯誤和技術選型錯誤。於是又把推向市場的時間往後推4個月，而這時對子產品的要求增加到完成六個，依然很緊迫，往往有這種情況，在敏捷中的乙個兩周節點平均兩個人就要完成乙個子產品（針對web端，通訊伺服器，客戶端的人員構成上來說），雖然有些子產品有基礎，可是試想一下，在半個月完成乙個將要推向市場的子產品？乙個節點往往乙個小組要承擔自己任務的概要設計，詳細設計，評審，編碼，測試，於是大家按照任務分配拼命加班，而且節點與節點之間也很少有調整期，最後從完成度和完成質量來看，都不理想，於是緊迫的任務又得往後推，接著又是下一輪緊迫，而且即使在計畫內，也會突然冒出其他專案的緊迫任務要某些人處理（通常都是推向市場的要求）。這種心跳玩的太過於頻繁，但是效果並不好，通常會因為軟體質量問題而阻礙推向市場，從我們大家的心理和身體狀態而言也是種惡化和透支，雖然，專案在某些方面取得了成功，但是這種「頻繁心跳」後的代價就是讓大家對專案的緊迫度產生懷疑？讓大家對接踵而來的緊迫任務疲於應對!
怎麼**這種「玩的就是心跳」呢，書中給出了這種建議：作為乙個管理者要有方向，要有戰略指導，任何組織內部都會遇上緊迫的任務。但是，不是所有的事情都是緊迫的，也不是所有的角色都要關心緊迫的任務。除非化緊迫為優先順序和約束，否則，這種「玩的就是心跳「幾乎不可能被**。
yaocoder
《專案百態》讀感系列」蘇式風格「
有些人問了，為什麼交付的產品包含了使用者要求的功能，卻不招使用者待見，很快就被擱置一邊了。喬幫主會這樣回答你，蘋果的產品能俘獲眾多使用者的心是因為注重使用者體驗，關注細節。在我們每個人的專案實踐中多多少少都會更關注需求，功能的實現，而忽視了使用者體驗。但是，請諸位先換位思考下，現在我是使用者，對於乙...
《專案百態》讀感系列」玩的就是心跳「
只要參與過一兩個軟體專案，就一定對書中介紹的情景深有感觸，也必然會從中得到經驗教訓 這是 軟體隨想錄 的作者joel spolsky對這本書的感受。以下我也結合自己實際的工作體驗對這本書中的模式場景說一下自己的感受 模式 玩的就是心跳 大概介紹的就是這樣一種場景，在工作中永遠都是緊迫的專案，在專案中...
《專案百態 軟體專案管理面面觀》三模式總結
其中顯著的表現為 他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求，不管是否能帶來收益 甚至不管有用沒有 都會立即轉化成專案，且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔，使他們更加手忙較短，無限重複在緊急的過程中。這種 心跳遊戲 型的行動是貿然的，思考極其...