日常工作中，很多人容易把风险产生的原因当作是风险本身。这样理解的话，问题虽然不大，但却会因为风险计划清单过长，给人一种“项目风险太多，还要不要继续”的错觉。严重地，甚至会导致产品或项目延迟上市等。

基于此，我们应该就不难理解，一份合理的、符合实际情况的风险管理计划书，在项目实施过程中，发挥着多么重要的作用了。

那么，风险管理计划怎么写呢？

下面，我们就以软件测试项目中，常见的风险为例，来制订一份风险管理计划。

1）项目风险

例如：当测试执行时间被压缩，测试不够充分，产品就发布上线的情况下，目前已经出现的风险有哪些（列举）；后期可能出现的风险有哪些（列举）。

2）造成原因（可能有以下的原因，按照实际情况去写）

（1）产品需求给出得晚，而且也不完善、清晰，多次反复评审的时间挤占了研发时间；

（2）开发自测不充分，导致提测的版本质量不高，影响正常的测试计划进度；

（3）Bug修复速度慢，阻碍了完整的新功能测试和较后的回归测试；

（4）中、后期频繁变更需求，或者新增需求，导致测试资源被分散。

3）优化方案（可参照下述的内容去反馈，按照实际情况操作即可）

（1）制定测试包的可接收标准，编写ATC，没达到可提测标准的一律退回。采取这种倒逼的方式，促使开发人员提高自测质量；

（2）在进行测试任务量评估时，预留10%～15%的缓冲量，用于应对需求变更和临时新增需求；

（3）优化测试用例的设计，减少冗余的和无效的测试用例，同时提高自动化脚本的覆盖率，节省相应的人力用于新功能的验证测试；

（4）和开发负责人明确缺陷修复的要求，每天几点之前要日清当天新的缺陷。同时，测试任务包尽可能拆解得小一些、独立一些。在某些模块里出现阻碍性缺陷时，可以略过，先测试其他模块。