軟體項目的核心風險

風險在所有的項目中都是存在的，在這些風險中有些是項目失敗的罪魁禍首，下面列舉五種最常見的，對項目的成敗有著巨大影響的風險。

 

1.          從一開始進度的安排就是錯誤的。

人們總是傾向於樂觀的估計，常常無視那些“可能需要作”的工作，儘管你可能對項目規模作了認真的估算，但是估算的結果仍可能太小，這也就直接導致進度的安排常常比應有的更緊張，在這種情況下能夠產出的成果也很有限。但是人們常常被這種看上去激勵人的進度安排所蒙蔽，失去了對這項風險的警惕。

儘管對項目規模作完全的估算並不能保證進度的安排是準確的，但是起碼不會使它和實際相差太遠。對那些無法估算出的工作量作好準備能是你在風險出現時不至於手忙腳亂。

對於大型項目來說，進度安排失誤的風險比較小，因為大型項目一般都對項目規模作了大量的估算，再者，這樣的項目更有機會重新進行估算，調整進度。

 

2.          需求膨脹或變化。

從項目的角度來說，需求總是向著膨脹的方向發展，即使是去掉已有功能的要求也是一種膨脹，因為這增加了工作量。我們總要“擊中移動的目標”，那種在項目一開始就試圖將需求固定下來，不允許任何變動的想法無異於刻舟求劍。例如一個為期兩年的項目，可能在開發的過程中使用者的業務發生了變化，我們就必須對軟體作出相應的改動。

我們需要有一個可以接受的變化的範圍，這樣在客戶要求變更需求的時候，我們能夠確定將增加多少工作量，對進度產生多大的影響，告訴客戶他將增加多少成本，得到什麼樣的結果。

 

3.          項目人員流失。

常常會有成員在項目進行過程中離開，也許他沒有留下任何文檔，也許除了他沒有人掌握項目的某些細節，也許新人不能很快的掌握項目所需的知識。對付這項風險的最好的辦法就是留住團隊成員，人腦比任何文檔都精確，更高效。如果你不能作到這一點，就要讓知識在團隊中廣泛的傳播。而過去，我們總是認為有了足夠的文檔就可以使每個開發人員都是可替換的。

 

4.          規約崩潰。

這種風險不同於其他幾種，它要麼不發生，要麼發生，直接導致項目失敗，不會對項目產生不同程度的影響。

在項目啟動的時候，雙方會坐在一起確定需求的範圍。如果在這個過程中大家談不攏，那麼最好取消，這樣雙方都不會有什麼損失。但是，這樣的情況很少發生，很多時候，雙方得到的是一個可以勉強接受的結果，於是項目帶著一個不明確的，含混的目標開始了。      

被掩蓋的問題雖然一時不會打擾你，但不會是永遠。當交付一個帶有缺陷，含糊不清的產品時，雙方付出的時間，金錢都已經無法挽回，當任何一方已不再有耐心繼續下去時，項目就只有死路一條。也許這還是好的，更糟糕的是雙方在進行了多次的修改和談判後項目依然無法走出泥潭。當認識到“缺乏共識”是根本原因時，項目已經無藥可救。

 

5.          生產效率低下。

開發人員的工作效率存在著很大的差異。如果從團隊的角度看，這種差異將會有某種程度的弱化。很少情況下，這種風險會對項目產生致命的影響，更多的是對項目進度產生影響。

 

可以看到，在這五種風險中，真正和效率有關的只有第五種，而且，很明顯的，前面四種風險對項目產生的影響要大的多。所以，不能認為風險管理導致了低效率，而是認識到這些風險的存在，為這些不確定因素作好準備，預留好足夠的資源，真正敢於直面困難，而不是為自己的逃避尋找借口。