常见风险与对策

管理风险	项目周期太长，成员积极性、主动性下降	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、测试人员参与需求的开发、需求的评审。 2、安排需求人员给测试人员讲解需求。 3、测试人员在开发过程中就进行功能测试。 4、测试人员编写测试需求，熟悉业务、理解需求。