5 评估模型在 ZK 公司的实际应用
ZK 公司软件开发项目风险评估模型是本文作者主持下在 2013 年 3 到 10 月之间构建，期间经过多次公司内部以及外部专家的交流，相关方法论和风险因素、权重在多次调整，并使用公司以往的项目情况进行验证和调整（相关验证和调整工作不再详述），上述评估模型在 2013 年 10 月基本成型。
基于该评估模型，公司日常管理中也做了相应的调整，尝试通过评估模型对各项目的风险状况进行评估后，公司管理层可以根据不同的风险状况有选择性地参与具体项目的管理。具体做法如下：
1、项目组的主要成员（项目经理、各小组组长、骨干成员）双周最后一天，针对项目当前情况独立填写《软件开发项目风险评价表》（表 4-14），由行政部门人员收集评价表。
2、行政部门根据评估模型将收集到的评价表整理成评价矩阵，并按公式计算。
3、将评估结果直接反馈给公司领导和技术部经理，根据不同的项目风险评估结果，做成不同的管理应对：
A)对于风险评估结果为“V5(极高)”的项目，公司领导、技术部经理、策划部经理、财务经理等将安排参加该项目的下周例会，听取项目状况以及协调解决重大问题。
B)对于风险评估结果为“V4(高)”的项目，技术部经理、财务总监等将安排参加该项目的下周例会。
C)对于风险评估结果为“V3(一般)”的项目，技术部经理参加该项目的下周例会即可。
D)对于风险评估结果为“V1(极低)或 V2(低)”的项目，意味着一切顺利，项目组按计划自行召开周例会。
4、根据上述管理要求，行政部协调好各项目组周例会的参会领导以及召开时间。
公司领导要求从 2013 年 11 月开始，在当前正在实施的个别软件开发项目的日常管理中，定期使用该评估模型进行风险评估并按上述管理方式进行工作调整。经过讨论，确定在“地税局三维仿真地图应用系统（二期）”和“数字城管执法综合管理系统”这两个软件开发项目上实施。这两个项目规模在 ZK 公司属于中小型项目，项目组成员大约在 4-10 人之间，人员有简单的流动但相对稳定，相当部分人员根据不同项目阶段会在多个项目组内承担工作。项目相关情况如表 5-1 所示：
在 2013 年 11 月开始，这两个项目组都按行政部的要求填报《软件开发项目风险评价表》（表 4-14），在填表前由行政部向各填表人员就项目风险评估的流程进行讲解，并对评价表的各评价指标进行说明。要求针对项目当前情况进行评价，各人独立完成，每次填表用时不超过 10 分钟。
5.1 第一次风险评估实例
2013 年 11 月 15 日，项目 1 和项目 2 的评价矩阵分别见表 5-2 和表 5-3。
分别计算得项目 1 的模糊综合评价向量 S = [0,0.18804,0.32426,0.2427,0.245]，v=3.54466，对应风险定级和评语为“V4(高)”；项目 2 的模糊综合评价向量 S =[0.10052,0.20732,0.20903,0.30355,0.17958]，v = 3.25435，对应风险定级和评语为“V3(一般)”。
根据风险评估结果，行政部协调技术部经理、财务经理在 11 月 19 日参加项目 1的周例会，并要求该项目组做好情况汇报准备。通知技术部经理在 11 月 18 日参加项目 2 的周例会。
根据该周项目例会的情况反馈，项目 1“地税局三维仿真地图应用系统（二期）”由于用户方同时实施内部系统改造，需求和接口时有反复，有时无暇顾及本项目。而项目 2“数字城管执法综合管理系统”应用了手机移动终端新技术，在集成时由于经验不足有一定的难度，但整体可控。评估结果和项目实际情况相符。
基于这两个项目的具体情况，技术部经理决定尽快和项目 1 的用户方落实软件需求的变更和评审相关工作。而对于项目 2，技术部经理将联系具有开发移动终端应用经验的伙伴单位，安排该项目组的技术骨干进行技术交流学习，尽快掌握移动终端开发的相关新技术。
5.2 第二次风险评估实例
2013 年 11 月 29 日，ZK 公司继续组织对项目 1 和项目 2 的评价，评价矩阵分别见表 5.4 和表 5.5。
分别计算得项目 1 的模糊综合评价向量 S =[0.1021,0.23544,0.1881,0.31974,0.15462]，v = 3.18934，对应风险定级和评语为“V3(一般)”；项目 2 的模糊综合评价向量 S = [0.52167,0.23171,0.20858,0.01902,0.01902]，v =1.78201，对应风险定级和评语为“V2(低)”。
根据风险评估结果，行政部协调技术部经理在 12 月 3 日参加项目 1 的周例会，并要求该项目组做好情况汇报准备。而项目 2 则自行安排周例会。
根据该周项目例会的情况反馈，项目 1“地税局三维仿真地图应用系统（二期）”虽然用户方已经积极参与，但需求仍有不断的变化；而项目开始进入编码和测试阶段，由于用户方规定了一些技术框架和接口，公司的技术优势不能有效发挥；该系统的接口较多，且用户方仍在改造，系统的耦合难度较大，所以项目仍存在一定的困难。而项目 2“数字城管执法综合管理系统”在攻克了手机移动终端新技术难关后，系统集成和用户测试都比较顺利。评估结果和项目实际情况相符。
基于以上情况，技术部经理决定亲自研究一下项目 1 的用户方改造系统所使用的技术规范和接口规范，以便更好地指导项目组的技术磨合。
5.3 第三次风险评估实例
2013 年 12 月 13 日，ZK 公司继续组织对项目 1 和项目 2 的评价，评价矩阵分别见表 5-6 和表 5-7。
分别计算得项目 1 的模糊综合评价向量 S = [0.47874,0.36844,0.15282,0,0]，v =1.67408，对应风险定级和评语为“V2(低)”；项目 2 的模糊综合评价向量 S =[0.66938,0.24084,0.07765,0.01213,0]，v = 1.43253，对应风险定级和评语为“V1(极低)”。
根据风险评估结果，行政部通知两个项目组自行安排下周例会即可。
但技术部经理还是参加了这两项目的例会，项目 1“地税局三维仿真地图应用系统（二期）”用户方的系统改造基本完成，已经能够保证对本项目的人员投入和参与，需求评审和设计已经完成，当前工作以编码测试为主，项目内容和进度基本可控。而项目 2 则已经完成系统集成，开始试运行，主体内容已经按计划完成，预计 2014 年 1 月份验收问题不大。
同样地，风险评估结果和项目实际情况相符。
