所有我们列出来的这些条目，就是所谓的“风险项目”。
那么风险识别这件事，在项目里应该由谁来做呢？一般情况下，风险分析的过程除了有专家的参与，更是一种集体智慧的体现，也就是说项目所有利益相关方，都应该参与到风险分析的过程中。在风险识别这个动作上，头脑风暴是一种可行的方法（即与会各方各抒己见，提出自己认为产品可能有的风险项）。
第二步：对每个风险项目做出风险等级评估
在风险评估过程中，我们要对上个阶段列出的风险项目做出评估，得出风险高低大小的一个排序。
这里我们要考虑风险的两个维度：风险发生的可能性大小，以及风险如果发生，带来的影响范围和严重程度有多大。
我们首先用定性的方法对风险进行评估，采用风险评估矩阵来指导我们的评估过程：
我们将前一阶段得出的风险项目列表进行两个维度的风险判断，得出如下结果：每一个风险项我们都从两个维度给他’高、中、低‘的判断：
那么这个填表过程是由谁来执行呢？答案仍然是集体智慧。风险评估会议要求各项目利益相关方参与，项目团队的成员，包括客户（如果可能的话）每个个体都可能在评估过程中表达自己在某一方面最权威的意见。打个比方说，上面表单里的’订单支付模块‘的影响范围，最适合对他进行评估的可能就是：客户、需求人员和测试工程师；而对于’后台管理系统‘的风险概率，最适合对他进行评估的可能是：开发组长或者对应的开发人员，以此类推。
得到这个评估表，我们使用先前的风险评估矩阵对他进行排序和整理，就得出以下结果：
进一步：
到此为止我们就完成了定性风险评估的过程。
不过这种定性分析还没有能够很细致的展示各风险项之间更细节的风险等级，比如上图标注红色，风险等级为高的三个项目，他们之间的排序我们并不能确定。
所以我们可以改为采用更为细致的一种定量分析，比如我们把’高、中、低‘这样的指标转换为’3，2，1‘这样的得分系统，可以得出如下结果：
可以看到，通过得分相加（采用发生概率和影响范围两个指标相乘是一种更合理的做法）这样的形式，我们得出了更为细致的风险等级划分。
实际上我们还可以更进一步细化，比如对于所有风险项的发生概率，我们可以结合其产生原因进行去量化分析：
对于风险的影响范围，我们从相关风险的使用频率和问题的严重程度去进行量化：
这样再从两个维度去对这个表格做一个运算，不管是用相加还是相乘的策略，我们就能得出更准确的一个风险排序。
当然风险评估除了矩阵法，还有一些其他的方法我们就不一一阐述了。
第三步：定义风险缓解措施
既然我们已经得到风险由高到底的一个风险结果，那么我们就要实施一些措施，对这些风险进行规避和缓解。
这里我们可以有很多种思路：比如将更有经验的开发人员投入到风险高的领域里面去，或者向风险高的领域投入更多的人手，等等。
还有就是：进行基于风险的测试。