风险管理

        项目风险管理作为9大项目管理知识领域之一，其重要性不用多说，不用说项目经理，普通开发人员平时其实也会自觉的进行一些风险管理，比如接到任务时，能根据任务难易程度安排自己的时间，能把困难及时反馈领导。

          但在普遍处于CMM2、CMM3级的项目中，风险管理并未作为一个正常的项目管理过程来执行。多数情况下，公司虽有完备规程，执行与监督时却流于形式，主要项目管理人员主要精力未投入风险管理过程中。

                这从风险记录的载体：风险清单中就可以明显看出。风险列表较含糊，未具体针对特定问题、特定来源出现，风险应对责任人总是同一个人、预估发生时间点总是一样。。。

 

            很多项目中简化了甚至消灭风险管理过程，可以分成这几类：

1，投入精力不多，但至少也有专人维护风险列表的常见项，平时也会进行监控和记录新风险。

2，没有专门的项目风险列表，靠需求例会、项目例会、故障例会 各自讨论可能的风险和安排应对措施。

3，最可怕的是这种看法：风险靠后期处理 ，靠响应速度快来规避风险

风险管理计划

      一般认为风险是未知因素引起，实际上对于经验丰富、在本行业、本公司、本产品工作多年的项目经理来说，如果说在本产品开发的第一年、第二年对可能的风险认识还不全面的话，在之后的年份，之前发生过的风险可以认为在之后的年份仍可能发生。所以风险管理只要肯投入精力、肯在项目起始就协调预留资源、愿意正确的估算任务\定制项目进度，大多数引起项目进度推迟、重大故障发生的情况是可能避免的。

      制定管理计划的过程不仅是 制定计划 这么简单，也是统一项目内外、关系人认识到风险对项目的影响的过程。计划中要包括风险经理、风险例会，风险列表的基本内容，风险管理过程有关干系人。。。，例会制度。

      公司可能会提供一个常见风险列表、风险检查单、风险概率分类标准、风险发生后果的分类标准。。。项目线可以定制或补充自己的风险检查单。

      应急储备的分配原则。一般认为这里的应急储备用于未识别、无法管理的风险，但我个人认为可以也可为所有已知风险预留资源、或统一为所有风险预留资源。

 

风险识别、分析、应对计划

      风险的发生，影响了项目的进度、成本、质量。

      以此为依据，从 各种资源、需求、研发过程、任务进度 是否可控的角度，在项目立项阶段，（通过头脑风暴、检查单、历史数据、项目任务\资源\进度\估算中的假设条件进行分析）可以列出初始的风险清单：人力风险（关键人员流失、出差、调动。。。）、技术风险（关键技术点是否有可能很难克服，耗费大量时间。架构设计不全面，引起重大故障。。。）、开发测试设备缺乏、立项重大需求因市场压力放弃而转向新需求（尤其在需求开发到一半时挂起、调整开发任务到新需求）。。。

      有了风险列表，其后的风险定性、定量分析也并非容易的事。定性分析，由于经常很难联系到所有干系人参加风险讨论，对于风险发生的概率、影响面可能会评估错误。      定量分析，这种过于精细的管理，对于软件开发是否有实用价值?

      相对来说，如风险定性、定量分析正确，风险应对措施反而比较容易，因为此处的风险应对人并非风险经理（风险经理的工作主要是跟踪），可能涉及多个项目干系人，有些人同时参与多个项目，或主要精力不在本项目，在制订风险应对措施与指定应对人时，应积极取得干系人的理解和支持。

      鼓励各项目成员、干系人上报风险，比如每个模块的开发人员都可以预估按计划完成任务的概率与外部风险（比如与外部产品联调的风险、重用组件的稳定性风险。。。）。。

      需要记录的信息：风险发现人、上报时间、风险描述、风险归类（外部、内部、xx市场...)、状态（提出、未发生已关闭、已发生、处理中、已解决已关闭...)、发生概率、影响程度（发生后的影响面大、小、中）、风险触发条件、风险应对措施(各种具体的工作手段)、应对目的（规避，转移，减轻，承担）、应对责任人、风险发生后的处理措施、预计发生日期、实际发生日期。。。

      有时会记录 风险等级或优先级（它是风险发生概率、影响程度 的加权组合）、概率与影响矩阵 ，但我个人认为，每个 影响程度大 的风险都是必须重点关注的。     

        记录风险的历史信息，在每次风险例会上汇报每条风险的当前状态。

      理论上，风险记录应该分得较细， 这样责任人更明确（甚至可以给责任人下达风险控制任务、估算工作量 等）。实践上根据项目特点灵活掌握，比如公司重点项目（高层较重视），则较易提到各方面的支持，则项目上不但可投入较多人力用于管理过程，在执行力上也较完美。

        责任人可能分为：风险触发条件的发现者、影响风险产生条件的控制者、执行风险应对措施（或风险处理措施)的执行者。责任人应定位到一个人，但给他列出各种干系人及其职责。

      各种风险应对措施进行整理后，可以纳入项目管理的日常工作计划中，有助于风险控制。

 

风险监控

              立项后，可能产生新风险，旧风险可能发生也可能随着项目进度而自然消失。风险经理平时的工作就是跟踪风险的产生、解决和预测新风险、调整未关闭风险的等级，项目进度可能触发某风险时，提示项目经理、干系人注意，要求紧急处理。。。等。

                  除了利用风险例会这个工具外，风险经理需要参与项目线的每个重大会议：项目例会、故障例会、需求例会、版本例会、市场项目通气会。。。实际上，因为各种项目事宜并非都会在会议上讨论，造成项目线内信息流通不畅，风险经理未能及时关闭旧风险、记录新风险。（比如项目经理没有在版本例会上规划版本，而是在邮件中指定版本，某重大故障未在例会上讨论，而是邮件安排开发人员紧急解决。）

              项目应建立各成员、外部干系人向风险经理上报风险有关信息的机制，在制度刚建立起始的一、两年内，有关制度应反复向项目成员、干系人宣传，最好与奖惩制度挂钩。

                风险经理的工作由于未直接与开发任务、故障处理、市场项目应标 挂钩，各方干系人可能对风险经理的支持程度不够，导致信息收集不全、跟踪不力，难免会导致疏漏或工作懈怠。

                在每周项目例会前应上报风险周报，汇报风险变更情况，重点是紧迫性风险、影响大的风险。

                可能需要与其它干系人、其它项目共享风险周报，平时的沟通制度也应建立。

 

度量

                  应对风险所造成的工作量与资源、

                风险造成的损失(分类如：工作量、资源、进度推迟多少天、产生多少重要故障。。。）

                未识别风险与已识别风险之比

                各种风险的数量。。。

 

风险收尾

      一般是指项目结束时，风险管理的过程数据、文档的整理分析及归档，总结经验教训。

        有些公司、部门会重视项目的经验数据，维护 历史风险库。