风险识别方法——检查表法

风险管理在质量体系中的地位很重，不管是GJB9001C还是GJB5000，都对风险管理提出很高要求。

进行风险管理，首先就要进行风险识别。实施GJB9001C的，还知道使用故障树来分析产品风险，很多实施GJB5000的，风险识别还一团浆糊，不知道如何着手。

实际上，风险识别有很多方法。比如头脑风暴法、流程分析法、故障树分析法等，这些方法都比较复杂不太好操作。这里介绍一种简单的易操作的风险识别方法——检查表法。

使用检查表识别风险的方法，就是把项目各阶段可能发生的风险罗列在一个表上，供识别人员进行检查核对，以判断当前阶段是否存在表中所列的或者类似的风险。

PS：有些成熟度三级的组织建立了风险库，项目组可以根据风险库中所列的风险来识别项目的风险，这也是另一种检查表法的使用。

按照风险管理要求，风险识别并不是只在制定风险计划的时候进行，它应当定期地和事件驱动地进行。比如每次项目例会的时候，都应当进行风险识别。

也正因为这样，方便实用的检查表法就显得格外有价值。

话不多说，下面就给出一个软件开发各阶段的风险检查表的示例：

生命周期	可能的风险因素
全过程	对一个或更多阶段的投入时间不够； 没有记录本阶段重要的信息； 尚未结束一个或更多前期阶段就进入下一阶段。
立项	没有书面记录下所有的项目背景信息； 没有进行正式的可行性研究； 任务书评审的缺陷评审密度过低； 项目组成员能力不足。
策划	准备计划的人没有承担过类似项目； 遗漏了项目计划的某些部分； 项目计划的部分或全部没有得到所有关键利益相关方的认可； 指定完成项目的人不是准备计划的人； 没有使用有效的估计方法进行项目估计。
需求分析	没有对性能需求以及安全性等质量需求进行分析并分解到软件功能； 没有对任务书进行需求的双向跟踪； 需求规格说明没有得到用户的确认。
设计	没有对关键需求制定并选择出最优的备选方案； 设计决策空洞无内容； 没有给出部件的动态关系； 没有给出内部接口关系。
实现	没有依据编码规范进行编码； 没有进行代码审查或静态分析。
测试	没有对测试环境进行跟踪； 测试计划和测试用例评审缺陷密度过低； 没有对测试Bug进行有效跟踪。
结项	验收评审流于形式； 在尚未完成项目所有工作的情况下，项目成员就被分配到新的项目组织中。

参考书目：基于PMBOK的软件项目管理方法研究，作者：周贺来，出版社：中国水利水电出版社