常見風險與對策

管理風險	項目周期太長，成員積極性、主動性下降	1、根據公司的有關制度，制定獎勵和懲罰措施。 2、劃分項目為多個階段或多個疊代。每個階段或疊代結束後舉行慶祝活動。 3、盡量不安排開發人員加班。 4、合理設定項目裡程碑及其目标，通過裡程碑的達成展現項目的階段性成果。
管理風險	項目組成員異地辦公	1、制定溝通計劃，規格化溝通内容和方式，利用技術手段減低溝通的影響。 2、建立遠端工作共享平台。 3、預算時考慮溝通問題所帶來的成本和影響。 4、建立項目組内部的 QQ 群，及時溝通。 5、建立項目組的 wiki。 6、分割異地團隊時，考慮工作和階段的獨立性。
技術風險	采用未驗證的新技術、新工藝、新方法、新物料	1、組織人員提前進行技術預研。 2、仿真、模拟實驗。 3、做好備用方案。 4、專家會審。 5、與客戶溝通，明确存在的風險，争取更寬松的預算和合作機制。 6、組織教育訓練與技術交流會，加強技術溝通。 7、增加代碼評審的力度。 8、增加熟悉技術的開發人員到項目 9、調整相關任務到非關鍵路徑。 10、疊代開發，第 1 個疊代做 spike。
技術風險	非功能性需求設計不充分	1、在需求文檔中明确定義非功能需求。 2、對非功能需求采用 QFD 方法跟蹤設計。 3、在編碼之前完成對非功能性需求的測試用例。 4、收集整理産品線 / 産品非功能需求的具體名額，固化到需求文檔模闆。
人員風險	人員能力不符合要求，或經驗不充分	1、對員工執行周期性業務與技術能力教育訓練。 2、能力與經驗欠缺的員工安排非重點任務。 3、每天下班之前安排經驗教訓的交流。 4、對新員工的工作進行同行評審。 5、協調外部專家加入項目，進行技術評審等支援。 6、為新員工指定指導老師。
外包風險	外包廠家開發的軟體品質比較差	1、對外包方投入的開發人員進行面試 2、在合同中定義外包方的品質投入與産出要求，安排 QA 進行過程中的監督。 3、在開發初期與外包方對設計的原則、代碼風格等達成一緻意見。 4、盡早介入對外包軟體的測試 5、進行階段性驗收，盡早對外包廠家的品質提出整改意見。、 6、使用長期合作的外包商。 7、派駐甲方的項目經理實時監督。
需求風險	需求模糊不清或有遺漏	1、需求文檔化，與客戶确認，以确認後的需求為驗收依據。 2、加強需求小組評審。 3、項目采用增量開發或疊代開發，先開發清晰的需求 4、采用快速原型法來挖掘需求，需求階段安排原型人員配合需求調研。 5、選擇有經驗的需求人員進行需求調研。 6、需求評審邀請業務專家的參與。 7、與客戶确認每個需求的驗收标準。 8、短周期疊代的進行已完成需求的示範和确認。 9、設定需求經理：需求的細化、傳遞、管理、确認。 10、引入合适的需求管理系統。
品質風險	重複性的測試工作降低了測試人員對缺陷的敏感性	1、進行交叉測試。 2、組織一些活動，提高每個人的工作熱情。 3、加大自動化測試的比例，減少測試人員的重複勞動。
品質風險	提供給測試的需求文檔太簡單	1、測試人員參與需求的開發、需求的評審。