一、 存在風險
此處羅列出了我們開發小組可能遇到8種的風險。
| 編號 |
風險名稱 |
內容 |
發生概率 |
損失（人周） |
危險度（周） |
| 1 |
計划編制風險 |
對所要使用技術不熟悉，可能導致無法交付； 每個模塊的實現一定程度上依賴於其他模塊的完成，可能導致長延期交付。 |
50% |
3 |
1.5 |
| 2 |
組織與管理風險 |
計划制定與實際操作脫節； PM無法有效的調動成員積極性； PM任務分配不合理； |
20% |
3 |
1.5 |
| 3 |
開發環境風險 |
小組成員擅長的開發環境不同，統一成相同的開發環境，需要重新學習； |
15% |
1 |
0.5 |
| 4 |
最終用戶風險 |
交付的產品與用戶預期差距較大，無法滿足目標人群的實際需求。 |
15% |
3 |
1.5 |
| 5 |
人員風險 |
小組成員交流不暢，或者產生矛盾； 某一重要環節成員遇到突發情況，無法完成所負責任務； 小組成員懈怠，交付的產品質量過差； |
5% |
1 |
0．5 |
| 6 |
需求風險 |
對目標人群的使用習慣和需求概括不清晰 |
10% |
2 |
1 |
| 7 |
產品風險 |
對不同移動端的兼容性差； 測試時間短，可能會出現未測試到的異常情況； 在不需要的功能上花費太多時間；
|
5% |
2 |
1 |
| 8 |
設計與實現風險 |
設計文檔不清晰，實現起來困難； 技術難度超出預期； 開發的各個模塊無法有效集成。 |
50% |
5 |
2．5 |
二、 風險優先級
對風險的優先級進行排序，集中精力解決最“危險”的風險，達到效率最大化。
| 編號 |
危險度 |
| 8 |
2.5 |
| 2 |
1.5 |
| 1 |
1.5 |
| 4 |
1.5 |
三、 風險的化解
在此，針對“刺頭”們，我們小組提供了相應的控制方法。
| 編號 |
控制方法 |
| 8 |
重視設計文檔的設計，統一建模語言； 對各模塊實現難度進行評估，對實現難度較大的方法及性能更改； 模塊以便於集成為前提進行划分； |
| 2 |
對各項任務進行評估，采用自主選擇兼以PM分配的形式分配任務，盡量使任務符合各成員技能點； |
| 1 |
任務分配后，預留一周學習時間； 理清每個模塊的相互依賴關系，設置中期驗收時間和最遲交付時間； |
| 4 |
持續的進行用戶調研； 以迭代的方式進行開發，每一輪產生的原型都交付用戶使用，收取反饋意見，進行下一輪的調整； |