流程帮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

持续的进行用户调研;

以迭代的方式进行开发,每一轮产生的原型都交付用户使用,收取反馈意见,进行下一轮的调整;

流程帮App风险评估

上一篇:Domain logic approaches


下一篇:Domain Logic approaches