[it專案風險管理之道：小心使得萬年船]
引言
有一首詩歌能夠很形象地描述風險的特徵：「輕輕的我走了,正如我輕輕的來，
。」「風險」一詞的由來，最為普 遍的一種說法是，在遠古時期，以打魚捕撈為生的漁民們，每次出海前都要祈禱，祈求神靈保佑自己能夠平安歸來，其中主要的祈禱內容就是讓神靈保佑自己在出海 時能夠風平浪靜、滿載而歸;他們在長期的捕撈實踐中，深深的體會到「風」給他們帶來的無法**無法確定的危險，他們認識到，在出海捕撈打魚的生活中，「風 」即意味著「險」，因此有了「風險」一詞的由來。
現代意義上的風險一詞，已經大大超越了「遇到危險」的狹義含義，而是「遇到破壞或損失 的機會或危險」，可以說，經過兩百多年的演義，風險一詞越來越被概念化，並隨著人類活動的複雜性和深刻性而逐步深化，並被賦予了從哲學、經濟學、社會學、 統計學甚至文化藝術領域的更廣泛更深層次的含義。無論如何定義風險一詞的由來，但其基本的核心含義是「未來結果的不確定性或損失」，也有人進一步定義為「 個人和群體在未來遇到傷害的可能性以及對這種可能性的判斷與認知」。
風險有兩種定義：一種定義強調了風險表現為不確定性;而另一種定義則強調風險表現為損失的不確定性。
若風險表現為不確定性，說明風險產生的結果可能帶來損失、獲利或是無損失也無獲利，屬於廣義風險，金融風險屬於此類。而風險表現為損失的不確定性，說明風險只能表現出損失，沒有從風險中獲利的可能性，屬於狹義風險。
廣義的風險展現出來的是機會，雖然這種機會可能讓我們的專案變得顆粒無收，但是如果一旦機會有利於專案，則可以大賺一筆，風險投資家們心中的風險正是廣 義的風險，所以風險才會吸引他們投入巨大的資金。而作為專案管理者來說，風險對他們意味著失敗的危險，因此必須將任何風險扼殺於搖籃之中。
it專案風險的特徵
由於軟體本身的特點，而導致it專案與傳統專案有很大的差異，因此it專案的風險管理難度要比傳統專案大。
1、 需求不穩定
軟體專案的需求多變已經成為了軟體業界的共識，正因為需求的多變，才讓瀑布模型一直遭受到軟體工程界的抨擊，因此而誕生了原形模型。在ibm的rup和眾多的敏捷方**中，一直將需求不確定列為軟體專案的最大特點，因此而出現了擁抱變化一說。
當乙個it專案已經開始在實施的時候，如果客戶連他需要做什麼，要實現一些什麼功能都不能確定的話，那麼做軟體實施的工程師他們又如何能夠知道自己要開 發乙個什麼樣的軟體系統出來呢?所以他們只有在漫長的等待過程中，不斷遭受到客戶的「批評」，在經歷了「九九八十一次磨難」之後，才恍然大悟，原來就是要 做乙個這樣的系統啊!
這有點像乙個盲人走路一樣，盲人根本就不知道前面是什麼，因此他往前走一小步，如果不是路，則向左旋轉一點點，再 次用腳探探前面，如果是路的話，則可以往前邁一步，
管理資料 《
it專案風險管理之道：小心使得萬年船
》()。如果這個盲人運氣不好的話，第一腳就在懸崖邊上踏空，那麼他將跌入萬劫不復的深淵。我們的專案也如同這 個盲人，稍有不慎就可能讓自己走向失敗，這是乙個多麼大的風險阿。
考試大收集整理
2、 專案規模估計不準確
當老師給我們布置作業的 時候，如果他多布置了幾個題目，下面的同學便會大聲地噓嘆，開始私下的嘟嚕：「又要做乙個多小時了!」。學生們在很短的時間內就能夠準確的估計作業量大不 大，他們的估計憑藉著他們每天一次的做作業的經驗和那一瞬間對題目的印象，雖然他們並沒有做過剛布置的這些題目，但是估計得仍然是那麼的準確。
任何乙個建築工程的專案經理都能夠對自己的專案進度掌握的很準，在他們的眼中，只要錢沒有問題，則進度就完全是小兒科，可以輕易的得到保證。工地需要多 少人，什麼時候需要開始進行什麼工序的施工，什麼時候需要加班，這些都在他們的心中掌握著。錢就是他們最大的風險，只要錢到位了，一切工作都好開始了。
而軟體專案與之不同，在軟體專案開始後，很少有缺錢的。只看到過資金沒有到位的「爛尾樓」，但是從來就沒有看過由於專案資金沒有到位的問題而導致未完成的軟體專案，就算是缺錢也是因為簽合同的時候要少了。
就算是再優秀的軟體專案經理，他也無法預計好自己的專案什麼時候能夠完成，因為在他進行估算的時候，客戶的需求還沒有搞清楚呢!再乙個，建築工程的可以 通過預算很準確的計算整個建築的工程造價，而軟體專案卻很難，因為不管是**行估算法，還是功能點方法，都遠不及「我猜，我猜，我猜猜猜」中猜得準確，這 些方法很多時候甚至不如算命先生算得準。
3、 人的因素對專案影響很大
人可以說是整個軟體專案的靈魂，軟體專案不需 要鋼筋、水泥和沙石，也不需要任何的施工機械。軟體專案的原材料就是人的思想和智慧型，而計算機和case軟體則是專案的施工工具。通過鍵盤和滑鼠，無數的 程式**在程式設計師的手中誕生了。如果要問軟體專案最大的成本在**，那麼答案只有乙個，就是人力成本。
乙個優秀的程式設計師的工作效率要遠遠大於乙個蹩腳的程式設計師，乙個程式新手甚至根本就不能夠產生任何生產效率。不僅如此，新手的錯誤行為，將讓熟練員工犧牲很多時間來幫助新手糾正他們的錯誤，最後下來，甚至可能導致降低軟體開發的效率。
雖然軟體專案已經實施角色分工和管理，但是相對於其他工程的分工來說則分工比較單一。軟體專案中，一般就分有，系統分析師、架構師、設計師、程式設計師、測 試工程是及配置管理人員和專案經理等。這樣的分工並不能有效的降低他們工作內容的複雜度。如果能像建築工程中的砌牆、澆注混凝土、搭腳手架那樣分工細緻的 話，則培訓軟體藍領也不會需要費如此大的力氣了。
小心駛得萬年船
將意外全數來避免，能夠全避免
古語話唯有小心，小心駛得萬年船
經常可以見到有人不小心，踩到或者碰到什麼東西而摔倒的情況。相反，盲人卻很少會因為自己的疏忽而摔倒。他們總是很小心的走著每半步路，對於前面的未知世界，他們總是要探了又探，在確認能夠行走的情況下，才小心的邁出半步。
由於軟體專案的太多不可確定性，因此管理軟體專案，猶如盲人走路一般。在未來還不確定的情況下面，可以將自己的經驗列出來，如在什麼時候最可能出現什麼 風險。盲人在聽到汽車聲音的時候，總是會更加小心，當軟體專案中開始出現一些問題的時候，我們需要考慮這些問題背後所隱藏著的更深的威脅。發現危險總是需 要憑藉自己的靈敏的直覺與豐富的經驗。
聰明的經營者，絕對不會是技術方面的專家，因為越是技術專家，就越不能容忍技術方面的缺陷。而經營者所需要考慮的不是技術是否無可挑剔，而是在乎專案是不是賺錢，讓別人去承擔風險，讓自己來享受利潤，是聰明的經營者的決策指南。
〔it專案風險管理之道：小心使得萬年船
〕隨文贈言：【受惠的人，必須把那恩惠常藏心底，但是施恩的人則不可記住它。——西塞羅】
專案風險管理
風險管理活動就是設法最小化由不可 因素導致的專案失敗的可能性。對專案的成功產生不利影響的條件和事件，都可以認為是專案風險。風險的發生是有概率性的 一旦發生，對專案的影響是不利的或有害的 風險是可能發生的，潛在的，對專案實施有影響的事情 問題issue 是當前時間窗之內已經發生或者已經確定一定會發生的...
專案風險管理
專案是為完成某一獨特的產品或服務所做的一次性努力。專案的最終交付成果在專案開始時只是乙個書面的規劃，無論是專案的範圍 時間還是費用都無法完全確定。同時，專案創造產品或服務是乙個漸近明細的過程，這就意味著專案開始時有很多的不確定性。這種不確定性就是專案的風險所在。風險一旦發生，它的影響是多方面的，如導...
專案風險管理
第7章 風險管理 1 7.1 介紹 1 7.2 風險管理規程 2 7.2.1 目的 2 7.2.2 角色與職責 3 7.2.3 啟動準則 3 7.2.4 輸入 3 7.2.5 主要步驟 3 step1 風險識別 3 step2 風險分析 3 step3 風險減緩 3 step4 風險跟蹤 3 7.2...