典型錯誤中有人員方面的。如：對有問題的員工失控、挫傷積極性、人員素質低、英雄主義、專案後期加入人員、開發人員與客戶之間發生摩擦、不現實的預期、缺乏有效的專案支援、缺乏各種角色的齊心協力、政治高於物質、充滿想像等…

典型錯誤中有過程方面的。如：過於樂觀的計劃、缺乏足夠的風險管理、缺乏計劃、在壓力下放棄計劃、在模糊的專案前期浪費時間、前期活動不合要求、缺少管理控制、缺少質量保證措施、魯莽編碼等…

典型錯誤中有技術方面的。如：過高估計了新技術或方法帶來的節省量、專案中間切換工具、缺乏自動的原始碼控制手段等…

.

b、列出自己的最差實踐：

注意典型錯誤，建立自己的最差實踐列表，可以避免在以後的專案中犯同樣的錯誤。

c、列出專案中的最差實踐：

組織機構和其他專案組總結經驗，學習他們的錯誤中得到的經驗。和其他組同事交流專案開發中的磨難，學習他們的經驗。列出潛在的錯誤，看到它我們就會盡量避免今後犯同樣的錯誤。

打個適當的比喻，典型錯誤好比我們學車時教練講的經驗，自己的最差實踐就像我們在實際開車當中出的問題，而專案中的最差實踐就是我們學車前的筆試的書。

公司在發展的同時，也會積蓄一些各方面經驗。列出所有的經驗，按其分類。系統分析中的經驗提供給系統分析，設計人員中的經驗提供給管理人員，技術中的經驗提供給開發員。這樣我們就會有更多的時間花在新的錯誤的防範上面。開發出來的系統就會一個比一個好。

2.2、風險管理：
下面先看一下來自一段網上的文章吧！

“一般認為賭博是在冒險。拉斯維加斯老機的設計者將老虎機的最大賠付率定為97%，即你花一天時間，往老虎機裡塞進100元，最多隻能贏回970元。

但是，如果比起軟體開發所冒險，拉斯維加斯的賭博簡直就可以稱為“安全的冒險”了。軟體專案所面臨的不斷變換的使用者需求、糟糕的計劃與估算、不可信賴的承包人、欠缺的管理經驗、人員問題、傷筋動骨的技術失敗、效能欠佳…..等等不勝列舉的風險，使大型專案按時完成的機率幾乎為0，大型專案被取消的機率和賭博一樣成敗參半（Jones 1991）。”

所以專案開發中對風險進行控制管理就大大提高了軟體開發的成功性。軟體風險管理工作就是在風險成為影響軟體專案成功的威脅之前，識別、著手處理並消除風險的源頭。一般我們可以在幾個層次上定位、管理風險。

1）危機管理---救火模式，就是在風險已經造成麻煩後才著手處理它們。

2）失敗處理---察覺到了風險並迅速做出反應，但只是在風險發生之後。

3）風險緩解---事先制定好風險發生後的補救措施，但不做任何防範措施。

4）著力預防---將風險識別與風險防範作為軟體專案的一部分加以規劃和執行。

5）消滅根源---識別和消除可能產生風險的根源。
1、2、3項都是被動進行的，亡羊補牢，為時以完。所以我們應當著力於預防風險，更好的是消除風險根源。

風險管理由風險評估和風險控制。而風險評估由風險識別、風險分析和風險優先順序組成：

l 風險識別：就是提出一個潛在破壞專案進度的風險列表，就像生成錯誤列表一樣。

l 風險分析：評估每一個風險出現的可能性及其影響，判定風險的級別。

l 風險優先順序：按風險影響大小排出一個風險優先順序，這個風險列表將作為風險控制的基礎。

風險控制由風險管理計劃，風險化解和風險監控組成。

l 風險管理計劃：制定一個應對每個重要風險的方案，同時就確保每一個單獨的風險管理計劃之間以及與整體專案計劃之間相一致。

l 風險化解：每個重要風險所對應計劃的執行。

l 風險監控：就是對解決風險的過程進行監控，風險監控還可以包括識別新的風險並將其反饋到正在進行的風險管理程式中等方面的工作。

現在以我以前做的專案來說明一下我是怎樣進行風險管理的。

接到專案對專案進行調研工作，在調研中就要注意到刻服錯誤列表中的錯誤。調研完成後，寫需求說明書初稿（一般根據情況至少給出二個以上的方案），為客戶進行講解，結合客戶意見再次進行修。把修改後的說明書和同士進行討論，再次進行修改。在此期間寫出總體設計的初稿（大的框架）。最後再為客戶講解，再次修改少量的功能。客戶確定需求滿足後就可進行總體設計了。在生成需求分析的同時，注意列出需求中存在的風險。如：需求改變問題、需求定義欠佳等風險。在進行總體設計時，多和客戶交流。因為在總體設計中修改需求比在詳細設計中修改要容易比在編碼階段修改就更加容易了。之後生成總體設計說明書。同時在總體設計中也要對一些不定的因素進行風險監控。列出風險列表。根據總體設計說明書就可以開始詳細設計了。在詳細設計中除了要考慮系統設計外還要考慮一些技術風險問題。把很難預見的問題列到風險列表中。注意，從需求分析到詳細設計，隨著系統開發的進行度。以前不明的因素將會慢慢顯露。同時也會出現新的不明因素。這樣就讓我們必須在整個設計開發過程中進行風險監控、風險識別、風險分析和風險化解工作。同理，在編碼中也同樣處理。在開發過程中根據分析不同，把風險按階段分為需求分析階段風險、總體設計階段風險、詳細設計階段風險和編碼階段風險。並交由此階段的人員進行監控和化解。同時，如果在化解安全區（規定解決問題的時間段中）內無法完成解決，則提交專家組（包括到外請的專家顧問）解決( 我們一般是在週五下午的討論會上進行)。當然軟體開發中所碰到的風險是很多的。但不可能完全同時進行風險監控的。通常是把風險列表中認為最會發生的風險乘損失的大小後的最大數進行嚴格的監控起來。隨著開發進度，風險是在變化的，所以風險列表可能會增加也可能會減少。只要風險管理好了。系統就成功了一大半。 [@more@]

談談軟體專案管理的重要性2（轉）

相關文章