流程帮App风险评估

一、 存在风险

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

转载于:https://www.cnblogs.com/blackDuck/p/10747836.html