一、 存在风险
此处罗列出了我们开发小组可能遇到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 | 持续的进行用户调研； 以迭代的方式进行开发，每一轮产生的原型都交付用户使用，收取反馈意见，进行下一轮的调整； |