IT專案啟示錄——來自泰坦尼克號的教訓（第一篇）（轉）
中國網通 趙軍/譯
由於詹姆斯·卡梅隆執導的著名電影《泰坦尼克號》的原因，以及電視中很多的探索或歷史頻道中有過關於Titanic方面的記錄片，許多人對泰坦尼克的故事幾乎耳熟能詳。這些故事都重點展現了此次航行的最後兩天行程以及災難出現後最後幾個小時船上的情況。但是，這個為期4年的巨輪專案的建造細節究竟是怎樣的？這個專案本身有什麼樣的重大意義？在專案中到底出現了哪些情況導致泰坦尼克號最終遭受了如此的劫難呢？審視我們今天的IT專案，我們能夠從泰坦尼克號獲得什麼樣的教訓呢？
讓我們追溯到1909年，審視白星公司White Star的業務經營情況。當時，白星公司White Star老化的客輪航線已經不足以與日益強大的競爭對手進行抗衡。針對這一情況，白星公司著手製訂了一項戰略，即投資新興技術並用來製造三艘超級巨輪。這筆投資非常關鍵，因為這些客輪可能要用上至少20年。使用這些巨大投資來製造的客輪可能至少要服務20年。因此對於設計者，正確的設計至關重要。相對於速度而言，他們的設計戰略更關注豪華。如此一來，所設計客輪的二等艙相當於其它客輪的一等艙，三等艙相當於其它客輪的二等艙。
為了與豪華或“功能需求”這個目標相匹配，在“非功能需求”上的投資也不能少，所有這樣的支援功能包括諸如效能、安全、容量。但是從一開始，如同許多專案一樣，白星公司的專案小組就該專案投資的支出重點引發了一次爭論，最後經營戰略戰勝了其它的考慮因素。爭論犧牲的結果就是，本來應該屬於諸如安全系統這樣的非功能需求的新興技術的花費被省掉了。按照原來的設計，安全系統本應包括一個雙層外殼（底部被劃分成73個水密室），15個有著電動門的防水壁艙，48艘救生艇以及具備高階的抽水機技術。
現在既然重點主要放在功能需求上，非功能需求只能逐步妥協。不過，非功能需求看起來不太明顯，因此這種“切角”現象不被人注意。諸如，建造一個寬大舞廳這樣的功能需求導致有4個防水壁艙無法伸展到頂部的甲板，嚴重破壞了輪船容納海水的能力。這不僅是業務執行官，特別是負責這個專案的主管布魯斯.伊斯梅的責任，還有技術人員包括白星公司的造船專家以及Harland-Wolff的建造師對這一妥協負有不可推卸的責任。
專案建造階段臨近收尾時，大多出於安全效能的要求都由於這樣或者那樣的原因被“妥協“掉了。船上有些地方防水艙的高度僅僅高過吃水線10英尺。對這些白星的設計師做出了似乎合理的解釋，即Titanic號的綜合安全措施足以保護泰坦尼克抵禦任何自然災難。
在專案結束的時候，該專案團隊認為船的安全效能仍然維持在最初設想的較高水平。如此，人們對處女航充滿了信心。更為自大的觀點是認為泰坦尼克本身就是一艘巨大的救生艇。直到最後，泰坦尼克的專案團隊仍錯誤地沉浸在最初的設計假想中，並且沒有進行足夠地測試。在專案結束的時候，人們對這艘輪船如此信賴，以至於連災難修復和業務持續計劃都被認為是多此一舉。
簡而言之，那些本職工作未盡職的設計者們默許了安全上的隱患。當這艘船即將航行時，人們都認為即使有意外出現，該船也有足夠的安全保護能力。正因為這樣，船上全體工作人員及乘客們都逐漸形成一種共識：這艘船將永不沉沒。難怪會有53 個百萬富翁上了這條船！
不過，JP Morgan，這個當時世界上最富有的人在前一晚取消了他的行程。在經歷了倉促的“試航”後該船出發了，前方佈滿了無數的風險。在到達冰原地帶時船一直在持續的加速。安全方面的“妥協”在操作中一步步產生：由於“冰桶”測試進行得粗製濫造，無線電冰情警報未能及時傳達到船橋，以及守望員人數太少並且沒有雙眼望遠鏡。該輪船的指揮人員由於未能計算出冰原的實際面積，因此沒有意識到當反饋系統出錯時所帶來的巨大危險。
回到今天，對比我們的現代IT專案，整個IT專案從設計到執行等諸多方面與泰坦尼克號都有很多的可比性。它與現代IT專案有許多相似之處，例如，在IT專案完成及投入執行後的幾天、幾個月甚至幾年內都會出現問題。
IT專案可能在展開時顯得非常成功，並且還透過了一系列所謂的“標準”測試（系統、效能以及認知度），然而在實際執行時它仍然會慘遭失敗。畢竟，只有25%的IT專案是成功的，這個數字已經是得到了多個調查結果證實的（根據Standish Group公司1994、1996和1998的調查報告，所有的IT 專案中僅有25%在預期時間內完工、沒有超出預算並且所有特點和功能都符合最初的設想）。
看一個IT專案是不是成功，不能光看部署使用，而是應該在解決方案投入執行一段時間後再仔細衡量。衡量的標準要考慮所有業務可能遭遇到的所有影響因素。泰坦尼克號的故事有助於我們更好地理解功能和非功能需求之間的關係、專案各競爭要素之間的妥協關係、以及造成執行情況出錯的原因。
未完待續
IT專案啟示錄——來自泰坦尼克號的失敗教訓（第二篇）[@more@]
由於詹姆斯·卡梅隆執導的著名電影《泰坦尼克號》的原因，以及電視中很多的探索或歷史頻道中有過關於Titanic方面的記錄片，許多人對泰坦尼克的故事幾乎耳熟能詳。這些故事都重點展現了此次航行的最後兩天行程以及災難出現後最後幾個小時船上的情況。但是，這個為期4年的巨輪專案的建造細節究竟是怎樣的？這個專案本身有什麼樣的重大意義？在專案中到底出現了哪些情況導致泰坦尼克號最終遭受了如此的劫難呢？審視我們今天的IT專案，我們能夠從泰坦尼克號獲得什麼樣的教訓呢？
讓我們追溯到1909年，審視白星公司White Star的業務經營情況。當時，白星公司White Star老化的客輪航線已經不足以與日益強大的競爭對手進行抗衡。針對這一情況，白星公司著手製訂了一項戰略，即投資新興技術並用來製造三艘超級巨輪。這筆投資非常關鍵，因為這些客輪可能要用上至少20年。使用這些巨大投資來製造的客輪可能至少要服務20年。因此對於設計者，正確的設計至關重要。相對於速度而言，他們的設計戰略更關注豪華。如此一來，所設計客輪的二等艙相當於其它客輪的一等艙，三等艙相當於其它客輪的二等艙。
為了與豪華或“功能需求”這個目標相匹配，在“非功能需求”上的投資也不能少，所有這樣的支援功能包括諸如效能、安全、容量。但是從一開始，如同許多專案一樣，白星公司的專案小組就該專案投資的支出重點引發了一次爭論，最後經營戰略戰勝了其它的考慮因素。爭論犧牲的結果就是，本來應該屬於諸如安全系統這樣的非功能需求的新興技術的花費被省掉了。按照原來的設計，安全系統本應包括一個雙層外殼（底部被劃分成73個水密室），15個有著電動門的防水壁艙，48艘救生艇以及具備高階的抽水機技術。
現在既然重點主要放在功能需求上，非功能需求只能逐步妥協。不過，非功能需求看起來不太明顯，因此這種“切角”現象不被人注意。諸如，建造一個寬大舞廳這樣的功能需求導致有4個防水壁艙無法伸展到頂部的甲板，嚴重破壞了輪船容納海水的能力。這不僅是業務執行官，特別是負責這個專案的主管布魯斯.伊斯梅的責任，還有技術人員包括白星公司的造船專家以及Harland-Wolff的建造師對這一妥協負有不可推卸的責任。
專案建造階段臨近收尾時，大多出於安全效能的要求都由於這樣或者那樣的原因被“妥協“掉了。船上有些地方防水艙的高度僅僅高過吃水線10英尺。對這些白星的設計師做出了似乎合理的解釋，即Titanic號的綜合安全措施足以保護泰坦尼克抵禦任何自然災難。
在專案結束的時候，該專案團隊認為船的安全效能仍然維持在最初設想的較高水平。如此，人們對處女航充滿了信心。更為自大的觀點是認為泰坦尼克本身就是一艘巨大的救生艇。直到最後，泰坦尼克的專案團隊仍錯誤地沉浸在最初的設計假想中，並且沒有進行足夠地測試。在專案結束的時候，人們對這艘輪船如此信賴，以至於連災難修復和業務持續計劃都被認為是多此一舉。
簡而言之，那些本職工作未盡職的設計者們默許了安全上的隱患。當這艘船即將航行時，人們都認為即使有意外出現，該船也有足夠的安全保護能力。正因為這樣，船上全體工作人員及乘客們都逐漸形成一種共識：這艘船將永不沉沒。難怪會有53 個百萬富翁上了這條船！
不過，JP Morgan，這個當時世界上最富有的人在前一晚取消了他的行程。在經歷了倉促的“試航”後該船出發了，前方佈滿了無數的風險。在到達冰原地帶時船一直在持續的加速。安全方面的“妥協”在操作中一步步產生：由於“冰桶”測試進行得粗製濫造，無線電冰情警報未能及時傳達到船橋，以及守望員人數太少並且沒有雙眼望遠鏡。該輪船的指揮人員由於未能計算出冰原的實際面積，因此沒有意識到當反饋系統出錯時所帶來的巨大危險。
回到今天，對比我們的現代IT專案，整個IT專案從設計到執行等諸多方面與泰坦尼克號都有很多的可比性。它與現代IT專案有許多相似之處，例如，在IT專案完成及投入執行後的幾天、幾個月甚至幾年內都會出現問題。
IT專案可能在展開時顯得非常成功，並且還透過了一系列所謂的“標準”測試（系統、效能以及認知度），然而在實際執行時它仍然會慘遭失敗。畢竟，只有25%的IT專案是成功的，這個數字已經是得到了多個調查結果證實的（根據Standish Group公司1994、1996和1998的調查報告，所有的IT 專案中僅有25%在預期時間內完工、沒有超出預算並且所有特點和功能都符合最初的設想）。
看一個IT專案是不是成功，不能光看部署使用，而是應該在解決方案投入執行一段時間後再仔細衡量。衡量的標準要考慮所有業務可能遭遇到的所有影響因素。泰坦尼克號的故事有助於我們更好地理解功能和非功能需求之間的關係、專案各競爭要素之間的妥協關係、以及造成執行情況出錯的原因。
未完待續
IT專案啟示錄——來自泰坦尼克號的失敗教訓（第二篇）[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-954750/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- IT專案啟示錄——來自泰坦尼克號的教訓（第二篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第三篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第四篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第八篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第九篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第十一篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第十二篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第七篇）（轉）
- IT專案啟示錄——來自泰坦尼克號的教訓（第十篇）（轉）
- 單人專案管理的心得和教訓專案管理
- 機器學習專案實戰----泰坦尼克號獲救預測(二)機器學習
- 【決策樹】泰坦尼克號倖存者預測專案
- 來自10位 IT 大牛的23條經驗教訓
- 來自10位成功IT人士的23條經驗教訓
- 2019來自網際網路職場的教訓
- 經驗&教訓分享：我的第一個機器學習專案機器學習
- XXX管理平臺系統——專案教訓
- 成功專案經理的經驗教訓——鼓勵靈活的體制和行為（轉）
- 泰坦尼克生還預測：完整的機器學習專案(一)機器學習
- 作為專案經理的7個經驗教訓總結
- Struts 開發之 血的教訓 (轉)
- 一保健品專案運作失敗的原因和啟示（轉）
- 《卓有成效的管理者》培訓分享——來自專案管理群的討論專案管理
- JavaEE 啟示錄Java
- 專案管理辦公室的未來（轉）專案管理
- 如何啟動專案?(轉)
- 自動駕駛「黑手黨」十年啟示錄自動駕駛
- 專案管理經驗談——來自專案管理群的討論專案管理
- 手把手教SVN鉤子自動更新專案
- dir 顯示目錄檔案和子目錄列表(轉)
- 從1100多個專案中吸取的教訓：為什麼軟體專案需要英雄？
- 我的第一次專案管理--一次慘痛的教訓專案管理
- 搭橋啟示錄之二：專治各種不服的ICU
- 《啟示錄》筆記筆記
- Java EE啟示錄Java
- 專案管理經驗談——來自專案管理群的討論薦專案管理
- 來自程式設計“老者”們的須時刻謹記的七大教訓金典程式設計
- python 分析泰坦尼克號生還率Python