项目管理总结--风险管理

§1.9 项目风险管理
项目风险管理包括项目风险规划、风险识别、分析、应对和监控的过程。目标在于增加积极事件的概率和影响，降低消极事件的概率和影响。
项目Explorer虽然没有十分正式的项目风险管理，但也有专门针对项目中可能出现的问题（即风险）进行讨论和应对的过程，使用的工具和技术主要是专家判断、同行评审等。
§1.9.1 风险规划
风险管理规划是决定如何进行风险管理的活动的过程。
Explorer没有专门的风险规划过程，更多的是停留在定性通过经验规划的层次，也就是通过既往的经验和做法对该项目的风险进行规划和判断。虽然没有明确，但有约定俗成的做法，比如在角色和职责上项目风险管理由PM负责，在风险的确定和跟踪上通过周报的形式反映、风险的概率使用1-9共9个级别，级别越高风险越高、风险的影响分析使用文字定性表述，说明对项目范围、质量、成本和进度等各个方面的影响。
§1.9.2 风险识别
风险识别是指确定哪些风险会影响项目，并将其记载成文。
在Explorer项目中，风险识别主要根据项目组成员在之前项目实施过程中总结和归纳的经验教训、公司内部标准的风险评估清单，通过召开评审会议，召集项目组骨干成员、公司内部其他部门具有类似经验的高级技术人员、质量控制部对风险进行识别。依据风险评估清单，与会的评审人员针对清单中每一风险评估因素发表意见，确定该风险评估因素是否存在风险，如有则明确风险名称、风险可能的原因，如无则忽略该评估因素。其中，风险评估因素是指软件项目各个环节中需要考虑的风险因子，项目环节包括项目目标、环境约束、客户/用户、开发流程、项目管理、项目团队、需求、架构、代码实现、集成和测试、系统平台、上线、运维等方面。
评审会议最终产出项目风险清单，汇总为从管理、技术和商务等多个因素进行分解可能存在的风险列表，包括风险名称和产生原因。风险识别后下一步将对风险进行风险分析。
§1.9.3 风险分析
风险分析包括定性风险分析和定量风险分析。定性风险分析是为了采取下一步行动，对已识别的风险进行优先排序的方法。风险定量分析是对风险定性分析过程中作为对项目需求存在潜在重大影响而排序在先的风险进行分析。
Explorer项目主要通过专家评审的方式对风险识别形成的风险清单进行分析，确定风险清单中的风险优先级、概率和影响。经过评审会议，项目最有可能发生的风险清单及其概率、影响如下：
一、 管理类风险清单：
1. 项目核心团队（PM, TM, 业务分析师, Team Leader）没有足够的专业知识和经验（包括业务领域、技术领域）；
a) 概率：8级；
b) 影响：项目进度延迟；成本增加；质量成本增加、返工较多；
2. 项目团队不稳定，进出频繁；
a) 概率：6级；
b) 影响：项目进度延迟；项目团队建设成本增加、人员培训费用增加；项目质量成本增加、返工较多；
3. 开发规范不能被严格执行，代码复审执行力不足；
a) 概率：7级；
b) 影响：质量成本增加、返工较多；
4. 客户参与和配合的程度不够，不能提供有效的需求；
a) 概率：4级；
b) 影响：范围蔓延；项目进度延迟；项目成本增加；项目质量成本增加、返工较多；
二、 需求类风险清单
1. 项目需求不清，客户没有想法，不清楚自己需要什么；
a) 概率：7级
b) 影响：范围无法控制；项目进度延迟；项目成本增加；项目质量成本增加、返工较多；
三、 技术类风险清单：
1. 没有现成的成熟技术框架，使用的技术在业界不成熟，只有少数成功的案例；
c) 概率：8级；
d) 影响：项目进度延迟；人员培训费用增加，项目成本增加；项目质量成本增加、返工较多；
2. 技术架构未经验证，尚不明确是否满足性能要求；
e) 概率：8级；
f) 影响：项目进度延迟；项目成本增加；项目质量成本增加、返工较多；

由于没有现成的技术框架可用，目前的技术能否满足业务需要很难确定，能否完成项目谁心里都没有底。据此，定义技术类风险为目前优先级最高的风险，在进入开发前需马上组织人手着手解决。
§1.9.4 风险应对规划
风险应对规划是为项目目标实现增加实现机会，减少失败威胁而制定方案，决定应采取对策的过程。
根据风险识别和风险分析的成果，对各项风险制定相应的应对措施，主要采用同行评审会议的方式进行。
各项风险的应对规划如下：
一、 管理类风险清单：
1. 项目核心团队（PM, TM, 业务分析师, Team Leader）没有足够的专业知识和经验（包括业务领域、技术领域）；
a) 责任人：PM、系统分析员；
b) 应对措施：接受，减轻（该风险无法规避和转嫁）；
c) 应对计划活动：业务培训、技能培训、经验总结和分享；
2. 项目团队不稳定，进出频繁；
a) 责任人：PM；
b) 应对措施：接受，减轻（该风险无法规避和转嫁）；
c) 应对计划活动：建立完备的过程文档和工作记录；关键岗位人员的备份以及培训、培养；加强团队建设，增强团队凝聚力，减少人员流失；
3. 开发规范不能被严格执行，代码复审工作执行不到位；
a) 责任人：PM、各子系统负责人；
b) 应对措施：接受，减轻（该风险无法规避和转嫁）；
c) 应对计划活动：制定明确的开发规范和代码复审制度，写入到项目管理制度中，与绩效考核挂钩；
4. 客户参与和配合的程度不够，不能提供有效的需求；
a) 责任人：系统分析员；
b) 应对措施：接受，减轻（该风险无法规避和转嫁）；
c) 应对计划活动：与客户沟通协商，制定明确的时间计划，客户确认；商务协调，求得客户高层的支持；
二、 需求类风险清单
1. 项目需求不清，客户没有想法，不清楚自己需要什么；
a) 责任人：系统分析员；
b) 应对措施：接受，减轻（该风险无法规避和转嫁）；
c) 应对计划活动：安排经验丰富的系统分析员到现场调研和分析，与客户一起讨论需求，在提出想法和业务建议以及收集反馈意见逐步明确需求；组织评审会议，集思广益；
三、 技术类风险清单：
1. 没有现成的成熟技术框架，使用的技术在业界不成熟，只有少数成功的案例；
a) 责任人：系统架构师；
b) 应对措施：接受，减轻；
c) 应对计划活动：组建技术公关团队，研发技术框架；
2. 技术架构未经验证，尚不明确是否满足性能要求；
a) 责任人：测试经理；
b) 应对措施：接受；
c) 应对计划活动：组建测试团队，对技术框架进行性能测试，及早发现问题和解决问题；

§1.9.5 风险监控
风险监控是识别、分析和规划新生风险、追踪已识别风险和“观察清单”中的风险，重新分析现有风险、监测应急计划的触发条件、监测残余风险，审查风险应对策略的实施并评估其效力的过程。
在Explorer项目中，主要使用同行评审会议的方式对风险进行监控。会议内容包括核查风险清单中的风险是否仍然存在？其概率和影响是否有变化？是否已经演变为问题？是否出现了新的风险？对于之前确定的风险应对措施，通过实际观察的项目信息评估措施是否到位，是否有效果等。