災(zāi)難拯救

前言

　　前言　　幾年前，我聽了這樣一個故事。一個俄國人、一個法國人、一個日本人和一個美國人不幸被食人族抓住了。在被扔進沸水鍋之前，酋長告訴他的俘虜，每人可提一個請求，而他會滿足他們在這世上的最后要求。　　俄國人請求喝最后一杯伏特加，法國人請求讓一位年輕的本地姑娘給他最后一吻，日本人說他請求做最后一次關(guān)于質(zhì)量的演講。最后輪到了美國人說自己的請求，他說：“請先把我扔進沸水鍋吧，這樣我就不必再聽一次關(guān)于質(zhì)量的演講了！”　　什么事都要講個時機和場合。當(dāng)一個軟件項目陷入嚴峻的困境時，軟件開發(fā)機構(gòu)最想聽到的是他們應(yīng)怎樣扭轉(zhuǎn)敗局，使項目進行下去。然而此時，并沒有可遵循的PMI、IEEE、SEI或ISO標準幫助他們拯救項目。PMI、IEEE、SEI和ISO這些組織提供了預(yù)防項目失敗的方案，而沒有提供拯救項目于危難的辦法。當(dāng)項目迫近“被扔入沸水鍋”的結(jié)局之時，它最后的請求是“救我”，而不是“再告訴我一次如何避免陷入困境”?！　”緯且槐?ldquo;救治”之書。本書探討了如何拯救面臨失敗的軟件項目使之回到正軌，雖然其中也偶有內(nèi)容論及災(zāi)難預(yù)防。本書描述了拯救（或解救）面臨失敗的軟件項目（或稱軟件項目災(zāi)難）的10個步驟。本書有廣泛的目標讀者群，包括軟件開發(fā)人員、項目經(jīng)理、高級管理人員以及軟件項目利益攸關(guān)者（同軟件項目之間存在很大利益關(guān)系的人）?！　”緯仓荚诔蔀橐槐窘滩?。在本書每一章的末尾，都有本章小結(jié)，并提供了習(xí)題?！　”緯杏械膬?nèi)容要求讀者具備一些軟件工程知識，不過這樣的內(nèi)容很少，具備軟件工程知識并不是使用本書的必要條件。本書對于缺少管理知識的軟件工程師和對于缺少軟件開發(fā)知識的項目管理人員一樣有用?！　”緯舶?3章：　　第1章為緒論。本章介紹了災(zāi)難拯救的概念，探討了軟件項目何時需要拯救行動的介入。在本章中，還對本書中使用的幾個基本術(shù)語進行了闡釋。　　第2章論述了判斷項目災(zāi)難來臨的方法。對于遇到麻煩的項目來說，本章是決定是否需要對它采取后面各章中描述的拯救步驟的一章?！　〉?章至第12章描述了災(zāi)難拯救過程的10個步驟（每章描述一個步驟）。　　第13章為結(jié)束語，標題是“把最后的拼圖放入位置”。在本章中，有些內(nèi)容是關(guān)于災(zāi)難預(yù)防的。本章綜覽之前各章描述的10個步驟，并闡述了如何進行時間安排以使全部拯救過程在兩周時間里完成。　　本書所介紹的拯救過程中，很多步驟之間存在交疊，且每一步驟都依賴于它前面的步驟，因此，本書不適合隨興翻到哪里看哪里、“東一榔頭西一棒槌”的閱讀方式。如果讀者從頭到尾地了解了整個拯救過程，就更容易理解每個拯救步驟。因此，強烈建議您在實施拯救過程之前從頭到尾學(xué)習(xí)本書全部內(nèi)容。不過，您也不必因為我的上述建議而氣餒，本書每一章都有“本章小結(jié)”，您可以僅仔細閱讀與正在實施的拯救步驟有關(guān)章節(jié)而對其他各章只閱讀“本章小結(jié)”的簡化方式來學(xué)習(xí)。　　本書內(nèi)容偏重實踐而非理論。本書在介紹很多方法和技術(shù)時，并未說明其理論基礎(chǔ)。不過，本書中提供了大量的參考書目，以饗對理論背景感興趣的讀者。參考書目信息見本書末尾部分?！　≡诒緯霭嬷埃幸恍╆P(guān)于項目災(zāi)難局面能否扭轉(zhuǎn)的討論，也就是說，當(dāng)我們想拯救一個項目的時候，將這個項目稱為災(zāi)難是否合適。對于任何一名在大型技術(shù)公司工作過并聽到過某位沮喪的高級經(jīng)理說“這個項目是個災(zāi)難！”的人來說，答案都是很明顯的。如果災(zāi)難局面不可扭轉(zhuǎn)，那么，項目在彼時彼地就會被放棄了，但是，高級經(jīng)理接下來通常會說的是：“我們需要馬上使它回到軌道！”是的，這正是本書所要論述的。　　我在摩托羅拉公司和其他一些技術(shù)公司從事了多年的軟件項目管理工作，并對數(shù)百家軟件開發(fā)機構(gòu)的軟件項目開發(fā)數(shù)據(jù)進行了收集和分析，這是形成本書中“拯救”概念的基礎(chǔ)。在本書之前，我曾寫過一篇同名的論文，這篇論文發(fā)表在了美國國防部出版的軟件工程期刊CrossTalk上?！　「兄x埃米爾（Amir）在本書問世過程中給予的極大幫助，他的貢獻和評論是無價的?！　. M. Bennatan　　2006年1月

內(nèi)容概要

　　Jolt大獎素有“軟件業(yè)之奧斯卡”的美稱，本叢書精選自Jolt歷屆獲獎圖書，以植根于開發(fā)實踐中的獨到工程思想與杰出方法論為主要甄選方向。本書是作者在幾十年軟件項目管理實踐經(jīng)驗的基礎(chǔ)上寫成的，從軟件項目是否需要拯救的判斷到具體拯救的步驟，面面俱到，為拯救陷入災(zāi)難的軟件項目提供了一套易理解且便于操作的有效方法。

作者簡介

作者：（美國）本拿塔（Bennatan E.M.） 譯者：侯艷飛，侯玉芳，李萌  本拿塔，E.M.Bennatan擁有豐富的管理實戰(zhàn)經(jīng)驗。這些經(jīng)驗源自他在摩托羅拉公司多年擔(dān)任高級主管的經(jīng)歷。在任期間，他帶領(lǐng)團隊開發(fā)了很多大型軟件系統(tǒng)，并領(lǐng)導(dǎo)過多個跨國設(shè)計中心。他還曾是米德威公司（Midway Company）的工程副總裁，任職期間管理著數(shù)百名軟件和硬件工程師。Bennatan先生經(jīng)常在軟件項目管理方面做演講。他還是《在預(yù)算范圍內(nèi)按時完成：軟件項目管理、實踐和技術(shù)（第三版）》（On Time Within Budget:Software Project Management,Practices and Techniques,Third Edition）一書的作者。Bennatan先生目前是先進項目解決方案公司的總裁以及波士頓Cutter聯(lián)合公司（Boston Cutter Consortium）的高級顧問。

書籍目錄

第1章 緒論
 1.1 災(zāi)難拯救過程概述
 1.1.1 案例研究
 1.1.2 做出拯救決定
 1.1.3 拯救過程
 1.2 一些調(diào)查數(shù)據(jù)
 1.3 一些提示
 1.4 本章小結(jié)
第2章 確定項目是否陷入災(zāi)難
 2.1 進度
 2.1.1 設(shè)置進度警報器
 2.1.2 調(diào)整進度警報器
 2.1.3 監(jiān)視延長后的時間表
 2.2 預(yù)算
 2.2.1 設(shè)置預(yù)算警報器
 2.2.2 其他需考慮的事項
 2.3 質(zhì)量
 2.3.1 問題列表警報器
 2.3.2 顧客滿意度警報器
 2.4 學(xué)會利用經(jīng)驗
 2.5 本章小結(jié)
 習(xí)題
第3章第1步——停止
 3.1 停止項目
 3.1.1 為什么停止項目
 3.1.2 誰來停止項目
 3.1.3 項目停止程序
 3.2 準備下一步
 3.3 開展團隊行動
 3.4 處理反對意見
 3.5 可能出現(xiàn)哪些問題及如何解決
 3.6 本章小結(jié)
 習(xí)題
第4章第2步——選定評估者
 4.1 該選誰——合格評估者的素質(zhì)要求
 4.2 案情陳述
 4.2.1 應(yīng)包含的內(nèi)容
 4.2.2 管理者的承諾
 4.2.3 評估者的承諾
 4.3 大型軟件項目
 4.4 可能出現(xiàn)哪些問題及如何解決
 4.5 本章小結(jié)
 習(xí)題
第5章第3步——評估項目現(xiàn)狀
 5.1 評審
 5.1.1 軟件項目評審概述
 5.1.2 評審面臨失敗的軟件項目
 5.2 項目狀態(tài)信息的來源
 5.2.1 口頭的狀態(tài)信息
 5.2.2 操作性的狀態(tài)信息
 5.2.3 文檔類信息
 5.3 評估大型軟件項目
 5.3.1 大型項目有何不同
 5.3.2 評估團隊
 5.3.3 評估大型項目的指導(dǎo)方針
 5.4 拼拼圖
 5.5 可能出現(xiàn)哪些問題及如何解決
 5.6 本章小結(jié)
 習(xí)題
第6章第4步——評估項目團隊
 6.1 一般原則
 6.2 評審團隊整體
 6.3 評審項目管理
 6.4 評審團隊成員
 6.5 整合信息
 6.6 可能出現(xiàn)哪些問題及如何解決
 6.7 本章小結(jié)
 習(xí)題
第7章第5步——確定最低目標
 7.1 項目目標和拯救過程
 7.1.1 區(qū)分目標、具體目標、需求和交付成果
 7.1.2 項目目標由誰制定
 7.1.3 同目標監(jiān)督者結(jié)成同盟
 7.2 目標最低化的準則
 7.2.1 降低目標的過程
 7.2.2 一個降低目標的案例
 7.2.3 處理反對意見
 7.3 大型項目的目標最低化
 7.4 可能出現(xiàn)哪些問題及如何解決
 7.5 本章小結(jié)
 習(xí)題
第8章第6步——確定最低目標能否實現(xiàn)
 8.1 可實現(xiàn)的目標
 8.1.1 可行性分析方法
 8.1.2 被拯救項目的可實現(xiàn)目標
 8.1.3 如果目標不可實現(xiàn)
 8.2 中期報告
 8.3 可能出現(xiàn)哪些問題及如何解決
 8.4 本章小結(jié)
 習(xí)題
第9章第7步——重建項目團隊
 9.1 回顧團隊評估
 9.2 識別問題
 9.3 重建團隊
 9.3.1 應(yīng)對變更
 9.3.2 實施變更
 9.3.3 處理反對意見
 9.4 重建大型項目團隊
 9.5 可能出現(xiàn)哪些問題及如何解決
 9.6 本章小結(jié)
 習(xí)題
第10章第8步——風(fēng)險分析
 10.1 風(fēng)險分析概述
 10.2 風(fēng)險分析過程
 10.2.1 預(yù)測問題
 10.2.2 分析階段
 10.2.3 實施風(fēng)險行動方案
 10.3 風(fēng)險分析的一個例子
 10.4 可能出現(xiàn)哪些問題及如何解決
 10.5 本章小結(jié)
 習(xí)題
第11章第9步——修改計劃
 11.1 軟件項目計劃制定綜述
 11.1.1 軟件項目計劃概念
 11.1.2 軟件項目開發(fā)計劃
 11.1.3 項目計劃制定工具
 11.2 制定一個被拯救項目的計劃
 11.2.1 為被拯救項目制訂計劃的指導(dǎo)方針
 11.2.2 其他需考慮的事項
 11.3 可能出現(xiàn)哪些問題及如何解決
 11.4 本章小結(jié)
 習(xí)題
第12章第10步——創(chuàng)建早期預(yù)警系統(tǒng)
 12.1 早期預(yù)警系統(tǒng)的組成要素
 12.2 開發(fā)數(shù)據(jù)收集
 12.2.1 項目開發(fā)數(shù)據(jù)的作用
 12.2.2 重啟后項目的數(shù)據(jù)收集
 12.3 定期項目現(xiàn)狀評審
 12.4 項目報警機制
 12.5 啟動校正行動
 12.6 后續(xù)行動
 12.7 可能出現(xiàn)哪些問題及如何解決
 12.8 本章小結(jié)
 習(xí)題
第13章 尾聲：把最后的拼圖放入位置
 13.1 項目結(jié)束后的總結(jié)回顧
 13.2 人為因素
 13.3 災(zāi)難拯救的時間表
 13.4 最終報告
 13.5 案例分析
 13.6 結(jié)束語
參考書目
術(shù)語表

章節(jié)摘錄

版權(quán)頁：   插圖：   6.不相關(guān)信息（好像有來自其他拼圖玩具的拼圖） 這里，好消息是知道信息是不相關(guān)的，這本身就是成功的一半。這樣問題就降為了一個在將信息排除之前對它進行重新評價的問題：該信息確實是不相關(guān)的嗎？（例如，對一項功能的描述，該功能最初被認為是屬于該項目的，但是審查后被排除了出去。） 若對信息的不相關(guān)程度有所疑問，那么在將它排除出去之前，向項目的主要人員（項目經(jīng)理、市場代表、客戶或者拯救發(fā)起人）進行咨詢。不過，不要將不相關(guān)信息拋棄；以后你可能會改變對其價值的看法。 一般來說，與不合適的拼圖相關(guān)的多數(shù)問題能夠通過口頭方式解決和澄清。主要的挑戰(zhàn)通常在于找出擁有正確信息或缺失信息的人。在評估過程開始時，準備好一個項目信息主要擁有者列表是很有用的。在項目重要成員（高級經(jīng)理、項目經(jīng)理、客戶代表、市場代表，等等）的幫助下編制這個列表。 5.5 可能出現(xiàn)哪些問題及如何解決 本章所介紹的指導(dǎo)方針旨在提高成功完成評估的可能性，但顯然，事情還是有可能出錯。未雨綢繆是一種好的策略。實際上，做好準備是最好的預(yù)防方法之一。 下面介紹了一些較常見的導(dǎo)致評估過程失敗的原因，并提出了應(yīng)對之道。 缺乏合作 在評估陷入困境的項目時，缺乏合作是很常見的，特別是在評估開始后的最初幾天里，這種現(xiàn)象尤為常見。對局外人懷有敵意或猜疑，擔(dān)憂工作安全，或者對面臨失敗的項目興趣下降，是出現(xiàn)缺乏合作問題的原因。 行動建議：答案在于高級管理層發(fā)出對拯救過程的強有力且看得見的支持信號。一個有效的解決辦法是在拯救發(fā)起人、評估者以及不合作的人或團體之間召開一次三方會議。 項目復(fù)雜 對于外部評估者來說，項目可能太復(fù)雜，難以在可利用的有限時間內(nèi)充分理解它。如果不能在合理的時間內(nèi)（通常是2～3天）找到一名專家顧問，那么問題就會變得特別嚴峻。 行動建議：這通常是一個優(yōu)先級的問題。提高尋找專家這項工作的優(yōu)先級。給專家增加薪金，或者從另一個項目中抽調(diào)一位專家。專家成本應(yīng)視未能拯救項目將會帶來的損失而定。 評估過程延期 當(dāng)評估過程費時過長時，不去尋找步伐緩慢的原因（即不去解決作為步伐緩慢原因的問題）是一種常見的行為趨向，因為尋找原因也會花費時間。但是，若有跡象表明評估過程會使整個項目拯救過程延期不止一天兩天，那么就需要立即去尋找步伐緩慢的原因。注意，這并不意味著延期一兩天是可以容忍的；實際上，這樣的延期會將拯救過程置入危險的境地。 可能是前面提到的兩個問題中的一個（缺乏合作或者項目非常復(fù)雜）導(dǎo)致了評估過程延期，也可能是由于所選的評估者不合適，導(dǎo)致了評估過程延期。 行動建議：如果步伐緩慢是前面提到的兩個問題中的一個造成的，那么應(yīng)用前面講到的相應(yīng)辦法解決。如果步伐緩慢問題與評估者有關(guān)，那么拯救發(fā)起人就需要采取行動了，有可能需要更換評估者。如果步伐緩慢是由其他原因引起的，那么高級管理層應(yīng)參與到解決問題行動中來。

編輯推薦

《災(zāi)難拯救:讓軟件項目重回軌道》榮獲2007年Jolt世界圖書大獎，適用于軟件項目經(jīng)理和高級經(jīng)理，也可供軟件開發(fā)人員和與軟件項目有關(guān)的其他人員參考，還可作為軟件工程和項目管理方面的教材?！稙?zāi)難拯救:讓軟件項目重回軌道》是一本“救治”之書。它探討了如何拯救面臨失敗的軟件項目使之回到正軌，雖然其中也偶有內(nèi)容論及災(zāi)難預(yù)防?！睹枋隽苏?或解救)面臨失敗的軟件項目(或稱軟件項目災(zāi)難)的10個步驟?！稙?zāi)難拯救:讓軟件項目重回軌道》有廣泛的目標讀者群，包括軟件開發(fā)人員、項目經(jīng)理、高級管理人員以及軟件項目利益攸關(guān)者(同軟件項目之間存在很大利益關(guān)系的人)。。在每一章的末尾，都有本章小結(jié)，并提供了習(xí)題。

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

    災(zāi)難拯救 PDF格式下載

---