這篇文章準備講講風險管理的一些基本原則和應對方法
首先總結一下我在我們專案中遇到的風險以及應對方法
風險名稱
風險描述
發生概率
影響應對方案
例子其他
人員風險
專案人員的能力與專案的要求之間的差距
專案人員的流動低高
1，對於重要的專案，選用能力強的開發人員
2，引入高階開發人員對設計和**的review，可以預防由於開發人員能力問題引起的設計不恰當以及當人員流動的時候有個相對熟悉專案的人能及時地補充
3，加強開發人員之間的經驗分享傳承，同時文件記錄下來。
4，輪流做不同的專案從而保證大家的工作積極性和技能的增長，減少由於人員變動引起的專案停滯
技術風險
使用了以前沒有使用的技術引起的技術問題
中依專案情況而定
1，對於重要的專案盡量使用熟悉的技術實現 (當然對於一些對時間要求不是那麼嚴格的專案可以讓專案人員使用新的技術以提高他們的工作積極性和技能)
2, 對於有技術風險的專案，引入技術專家review
需求變化風險
不斷變化的需求會大大延遲高高
1，盡早的需求review
2，團隊積累對需求和業務的理解，積累歷史需求的問題以及經驗教訓，對於每個需求盡量了解業務背景和**
3，ccb控制需求的變更
4，靈活的技術架構設計，快速響應需求的變更
5，如果可以的話，需求的迭代開發盡早交付給業務部門做驗證，比如把需求按優先順序劃分為小的需求採用敏捷的開發方法
6，和業務部門約定好乙個需求模板
7，比較業務部門發給開發的需求文件以及發給客戶的資料變更描述，如果有不一致則盡快與業務部門確認
開發工具和環境的風險
開發環境的不穩定低中
1，備選的開發環境，比如準備一套虛擬機器上的開發環境
2，總結開發環境問題清單，能快速定位問題同時反饋給維護小組
今天先寫這些，圖表的更改太不靈活了，下面的空行先留著吧，以後再繼續更新
軟體開發管理
scrum感言 軟體流程的名稱太多，rup,v model,iso9000，cmm等等不一而足。最近接觸了scrum，收穫良多，與諸位同仁分享。自從有人類社會活動以來，就形成了各種各樣的組織和制度，上到社會體制下到家庭環境，西方到東方，社會風尚 工廠流程 等等，這些東西都具有一種共同的特點 都是為了...
創業期的軟體開發管理 二
決策者對軟體開發可能一知半解，他們會想當然地認為軟體開發過程比較 簡單 從市場上找乙個技術帶頭人，然後組建乙個開發隊伍，其餘的事就是下達需求，你給我開發出軟體來。這對於技術主管來講面臨的局面會非常尷尬，即需要向領導非常困難地解釋一些他們根本不能理解的問題。又需要承擔起巨大的壓力。先天不足 的需求也是...
初級軟體開發管理
負責團隊一線管理工作的，大多是做而優則仕，在程式設計上表現優異，被提拔成組長，是否具備管理才能，是否適合做管理，一般不會被公司特別考慮，更別說管理經驗了，新官上任三把火，剛剛被授予管理權力的開發人員，在管理上很積極，但由於缺乏經驗，也常常做出過猶不及的事情來，這麼多年工作中，遇到過下面幾種情況 老好...