风险和机遇管理计划及跟踪表

项目风险管理

文件修订履历：

版本

日期

编写

批准

摘要

v1.0

2022.7.30

张三

EPG

v1.1

2022.7.30

李四

EPG

v2.0

增加机遇的识别处理

项目风险分类

1. 需求

需求没有文档化

[1] 是否仅有未成文的需求？

如果项目的需求只是通过口头表达，则需要考虑风险。

需求不稳定

[2] 需求是否正在变化或是已经确定下来了？

如果需求正在被增加、变更或是没有被确定下来，则需要考虑风险。

需求不完全

[3] 需求中所有项目是否都有详细说明？

如果需求中有未列出详细说明的项目，则需要考虑风险。

需求可读性差

[4] 需求文档的可读性如何？

如果需求文档的可读性差，则需要考虑风险。

需求不清晰

如果关键的需求是模糊的、不明确的，则需要考虑风险。

需求进度紧张

[6] 进度中是否安排了足够的需求分析时间？

如果需求分析阶段的进度紧张，则需要考虑风险。

需求分析能力有限

[7] 需求分析人员的能力是否有限？

如果需求分析人员的能力有限，则需要考虑风险。

需求无经验可借鉴

[8] 项目需求的关键部分是否有以往的经验可以借鉴？

如果需求的关键部分无法借鉴以往项目的经验，则需要考虑风险。

需求不可行

[9] 是否存在在实现时有技术困难的需求？

如果不能确定某一项需求在所用的开发语言环境中实现的方法，则需要考虑风险。

需求不可跟踪

[10] 是否有计划在设计、编码和测试阶段对需求进行跟踪？

如果需求与开发过程出现偏差，或是在各个阶段没有被把握住，则需要考虑风险

2. 设计

设计的算法有问题

[11] 是否存在没有满足需求或是仅仅部分满足需求的算法？

如果算法有可能是错误的、不完整的，或是太复杂，则需要考虑风险。

设计难度大

[12] 是否存在难于设计的需求或是功能？

在某些时候，如一个复杂的树的查询可能需要很多的精力来设计，则需要考虑风险。

设计难度偏大过偏小

[13] 设计中的任何一部分是否是基于不切实际的或是乐观的假设？

如果对需求的设计太乐观或者太悲观，则需要考虑风险。

设计的接口定义不完全

[14] 是否内外部接口都已经很好的定义了？

如果在系统内部或是系统间存在复杂的、大量的联系，则需要考虑风险

设计不易测试

[15] 软件是否易于测试？

如果在测试产品时有很大的复杂性，则需要考虑风险。

设计有硬件约束

[16] 开发或是运行硬件是否对满足需求有限制？

如果在硬件速度、容量、可用性和功能方面有限制，则需要考虑风险

设计有软件复用性要求

[17] 是否存在软件复用？

需要考虑复用软件时的修改可能导致比设计新软件更多问题的风险。

3. 编码和单元测试

编码和单元测试的可行性

[18] 产品中是否有某些部分没有在设计说明书中被完全定义？

如果没有在设计时跟踪需求就编码，则需要考虑风险。

[19] 设计说明书是否有足够的细节描述代码？

如果设计处于太高的层次，则需要考虑风险。

编码进度偏差

[20] 是否存在充分的时间进行编码？

如果在进度表中没有安排充分的时间进行编码，则需要考虑风险。

[21] 是否对项目组在编码时间和工作量方面的估计有意见？

如果过于低估你的工作量，则需要考虑风险。

[22] 编码的实际进度是否与计划相比有比较大的偏差？

如果编码的实际进度与计划相比有比较大的偏差，则需要考虑风险。

测试进度偏差

[23] 是否存在充分的时间进行全部的单元测试？

如果在进度表中没有安排充分的时间进行测试，则需要考虑风险。

[24] 如果进度出现问题，是否会妥协，对单元测试进行调整？

考虑谁将妥协，在什么模块，考虑什么可能被遗漏。

[25] 是否对项目组在编码时间和工作量方面的估计有意见？

如果过于低估你的工作量，则需要考虑风险。

[26] 测试的实际进度是否与计划相比有比较大的偏差？

如果测试的实际进度与计划相比有比较大的偏差，则需要考虑风险。

编码工具问题

[27] 开发语言是否适合开发的软件产品？

如果开发语言不适合开发的软件产品，则需要考虑风险。

[28] 项目组是否在开发语言、开发平台或是开发工具方面有足够的经验？

如果项目组在开发语言、开发平台或是开发工具方面没有良好的开发经历，则需要考虑风险。

编码缺乏配置管理

[29] 是否有代码的配置管理计划？

如果没有版本控制或是代码修改不受控，则需要考虑风险。

4. 集成和测试

集成和测试硬件支持不足

[30] 是否有足够的硬件做充分的集成和测试工作？

如果没有足够的硬件资源，则需要考虑风险。

集成和测试进度紧张

[31] 是否有足够的产品集成方面的说明，是否安排了充分的时间做集成工作？

需要考虑满足进度和足够测试覆盖率要求的风险。

5. 验收和维护

产品验收标准不一致

[32] 是否对全部需求的验收标准都已经达成一致？

如果不确切明了什么是用户所期望得到的，则需要考虑风险。

产品的可维护性不好

[33] 产品设计和相关文档是否可以充分满足另外一个组维护代码的要求？

如果产品设计和相关文档不能充分满足另外一个组维护代码的要求，则需要考虑风险。

6. 团队

员工经验不足

[34] 在项目组中是否有很多新员工？

如果新员工比较多，则需要考虑风险。

[35] 项目经理和开发组长的工作经验是否丰富？

如果项目经理或开发组长在以往没有相应的工作经验，则需要考虑风险。

员工流动性大

[36] 项目组成员在项目结束前是否有流动的可能性？

如果项目组成员在项目结束前有流动的可能性，则需要考虑风险。

内部缺乏交流

[37] 在项目组中是否缺乏方便的、有效的交流？

如果进度表与项目会议冲突，则需要考虑风险。

[38] 是否和上级缺乏有关项目的方便、有效的交流？

在缺乏完整的信息情况下，需要考虑工作产品的质量风险。

项目组内部合作缺乏氛围

[39] 项目是否以前合作过？

如果项目组不能很好的合作，或是以前没有很好合作的经历，则需要考虑风险。

[40] 项目组是否对任务有清楚的认识？

如果项目组内存在分歧，则需要考虑风险。

7. 成本

缺乏成本管理和跟踪

[41] 是否对成本有测量和跟踪？

如果没有对成本进行测量和跟踪，则需要考虑风险。

[42] 预算偏差

如果实际成本和预算有比较大的出入，则需要考虑风险。

8. 组织和管理

组织缺乏管理

[43] 组织是否有专门的人员负责管理？

如果组织没有人负责管理，则需要考虑风险。

决策者能力有限

[44] 管理层是否有威信，是否果断，决策人是否有很高的素质？

如果管理层没有威信，处理事务优柔寡断，素质不高，则需要考虑风险。

项目风险和机遇列表

ID

时间

风险状态

风险类别

风险描述

识别时间

风险发生概率

风险影响
程度

风险系数

风险等级

识别机遇描述

收益

成本

收益回 率

评估等级

风险措施

机遇措施

对应人

对应时间

处理结果情况

应急计划

对应人

对应时间

关闭时间

处理结果情况

1

第1周

识别

组织和管理

对项目的规模、难度估计是否比较正确

2019/10/25

3

5

15

中

3

2

1.50

低

运用历史数据，随着项目进展，加强监控，调整计划

2019/10/25

调整估算结构，加强项目监控

2

第1周

关闭

组织和管理

进度安排是过于紧张，是否有合理的缓冲时间

2019/10/25

1

3

1.8

低

合理安排

2019/10/25

赶工、加班完成项目进度

加强项目的监控，调整计划

3

第2周

识别

团队

人员的辞职、流动

2019/10/30

0

4

0.4

低

加强预见性，关键人员采用助理制度进行互相备份

2019/10/30

未发生

4

第3周

识别

团队

上级领导是否随时会抽调本项目的资源用于其他“高优先级”的项目

2019/10/30

0

4

0.4

低

加强项目优先级管理

2019/10/30

未发生

5

第4周

关闭

需求

需求无法有效控制，导致变更频繁、混乱

2019/12/20

0

4

1.2

低

加强需求变更的控制能力，严格按照OSSP执行

2019/12/20

有效的控制需求的变更

6

第5周

关闭

编码和单元测试

开发小组是否采用统一的编程规范

2019/12/26

1

4

2

低

采用代码走查，统一编程规范

2019/12/26

统一编程规范

7

第6周

关闭

编码和单元测试

是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）

2020/12/26

1

4

2

低

坚持做技术评审

2020/12/26

全部完成同行评审

8

第7周

识别

组织和管理

本项目的合作部门的态度不积极

2020/10/30

0

4

0.4

低

向上级反映

2020/10/30

未发生

风 险 测 量

风险类别（分布）

需求

1

验收和维护

0

设计

0

团队

2

编码和单元测试

2

成本

0

组织和管理

3

风险状态（数目）

风险优先级（分布）

识别

4

高 ≥ 20

0

处理

0

中 ≥ 10 ＜ 20

1

关闭

4

低 ＜ 10

33

转化成问题

0

风险总量（数目）

8

风险状态

高

中

低

识别

处理

关闭

转化成问题

合计

0

0

0

机遇状态

高

中

低

识别

处理

关闭

合计

0

0

0