一个主要的风险管理工具就是主要风险清单。它指明了项目在任何时候面临的最大风险。
简单地列一张当前风险清单，可以使项目经理的头脑中保持着风险管理的意识。
项目组应当在开始需求分析之前就初步地列一张风险清单，并且直到项目结束前不断更新这张清单。
重要的是它应当定期“维护”。项目经理、风险管理负责人和项目经理的上司应当每隔一周左右就回顾一次这张清单。这种回顾应包含在他们两周一次的计划进度表之中，否则就可能被遗忘。
更新风险清单，给这些风险排优先顺序，并更新风险解决情况，可以使他们经常思考这些风险，并对这些风险的严重程度的变化保持警惕。
表11-1 “主要风险清单”的示例
要为主要风险清单中的每一种风险制订详细的风险应对计划。
它们不需太冗长，每种大概占1-2页。
【为解决“逐渐增加的需求”制订的风险应对计划】
主要从以下六个方面来制订：为什么？怎么做？采用的方法？谁来做？何时做？所需代价？
1、为什么?
经过分析我们发现项目中的需求泛滥会达到40%左右，我们需要控制逐渐增加的需求，以防止项目中出现超出控制的额外开销和时间拖延。
2、怎样做?
通常，我们应首先做好收集需求的工作。争取消除需求变更产生的根源。然后。我们要保证只允许那些绝对必要的需求变更。
3、什么方法?
我们针对这个风险提出三种具体方法：
1）在项目启动时就使用用户界面原型，以保证能收集到高质量的需求我们还要不断地给用户看这些原型，精练它们，再次给用户过目，直到用户对我们构建的软件完全满意为止。
2）我们要将需求规约置于明确的变更控制之下。当我们完成用户界面原型，并收集好其他需求时，就将这些需求作为基线确定下来。以后的需求变更必须通过一个更正式的变更过程，其中在接受每一个变更之前，都要仔细评估该变更对成本、进度表、质量以及其他方面的影响。
3）我们将运用分阶段交付的方法来保持较短的交付周期，这将减少在一个周期内发生变更的必要性。若有需要，我们可以在各个阶段之间变更软件特征。
当出现以下情况时，我们需要将风险等级提升：
1）经过一定时间，用户仍不能接受我们的用户界面原型;
2）在需求基线被确定之后的最初30天内，我们收到变更请求所涉及的需求已经超过了需求基线的5%;
3）在整个项目生存周期的任何时候，我们已被迫对需求作了5%以上的变更。
4、谁来做?
1）工程负责人对用户界面原型负责；
2）变更委员会负责将需求置于变更控制之下；
3）项目经理负责按时完成分阶段交付的计划进度表。
5、何时做?
1）要在4月15日之前完成UI原型。如果到了6月1日仍未完成，我们就要将风险级别提升到“项目紧急问题”；
2）需求规约要在5月15日之前确定基线。若是到了6月15日仍未完成，我们要将风险级别提升到“项目紧急问题”；
3）第一阶段的交付要在7月15日之前完成。若是到了8月15日仍然未果，风险也要被提升到“项目紧急问题”。
6、所需代价?
1）我们估计UI原型将要花去一个工程人员6个月的时间。
2）标准的开发步骤中包括明示的变更控制，所以不增加任何项目成本。
3）分阶段交付的方法会使开销增加5%左右，因为软件要被反复发布，增加了工作量。但另一方面它也减少了集成风险和生产错误产品的风险。
4）结果，唯一增加的只有项目真实成本的透明度。因此，与其说是花费还不如说是净效益。
原文始发于微信公众号（豆豆知识杂谈）
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/249451.html
