项目起源于哪里？它的威力有多大呢？在项目中有没有经常听到“风险”两个字？听到它有没有心里一颤？又会不会因为天天听而神经麻木？针对我们最熟悉的系统开发项目，站在前人总结的丰富的理论知识的基础上，如何在实际工作中做到有逻辑的识别风险，防患于未然呢？
关于项目管理，我们先来看它的前世。项目管理最早是从美国的曼哈顿计划（美国陆军部研制原子弹计划）开始的，为解决这样一项特殊的任务而生。结果大家也都知道了，美国抢先德国造出了原子弹，直接决定了二战的走向。《项目管理知识体系指南》（PMBOK）中为项目所做的定义是：项目是为创造独特的产品、服务或成果而进行的临时性工作。当下，我们很多的日常工作也运用了项目的管理方式，来组织资源、协调沟通、管理各项风险。如下是PMBOK中归纳的项目管理知识领域矩阵，对项目管理有兴趣的同学可以有个全景的了解：
图片来源于网络侵权则删
上图的矩阵中，范围管理、进度管理（时间管理）、质量管理、干系人管理等等各个方面都充满了不确定性，正是有这些不确定性，才需要有项目管理，来降低不确定性对目标的影响，这就是风险管理。
那么什么是风险？如何有效的识别风险？风险的应对应该分配给什么样的人呢？
什么是风险？
美国项目管理大师马克思·怀德曼将其定义为某一事件的发生给项目目标带来不利影响的可能性。PMBOK中是这样描述风险的：项目风险是一种不确定的事件或条件，一旦发生，就会对一个或多个项目目标的范围、进度、成本和质量造成影响。
可以看出，风险主要是一系列的对项目目标有影响的不确定因素，它最终可能发生，也可能并不会发生，风险管理的目标就是要减小他们发生的概率。但我们并不是对所有的风险都需要管理，风险识别需要评估它发生的概率，也需要评估事件对项目目标的影响程度。
如何有效的识别和分析风险？
项目管理是一种典型的系统性思考，风险识别也要系统性的、有逻辑的识别。
项目立项之初，就需要明确项目目标，项目经理的重要职责之一就是统一项目成员的目标，使项目成员朝着正确的方向努力。因此，脱离了项目目标来谈风险是没有意义的，识别风险也要是始终围绕着项目目标来进行分析。
01
项目目标之一：项目计划
沿着项目计划，往往能识别出关键风险，也是识别风险的主线。
基于产品的项目高阶计划（里程碑计划），以里程碑计划为关键点，通过对整个时间轴上各个阶段开展的各项工作的梳理，来梳理每一阶段的不确定性因素，进而识别每项工作中的风险以及时间风险。比如，需求分析阶段，因为是创新型业务可能导致需求不稳定，需求产出质量低，变化多。
02
项目目标之二：产品
通常情况下，我们都需要对产品沿着产品模块、产品特性等进行分解，创建WBS（Work Breakdown Structure），把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分。通过检视每一个部分来识别风险也是识别风险的一个维度：有成熟经验的，大概率是确定性的；基于成熟经验有突破的部分，需要小心应对；完全全新的部分，有可能是采用全新的技术，有可能是新的产品模式的探索，这部分会存在极大的不确定性，风险也就应运而生了。
另外，干系人的预期在某种程度上也是项目的目标之一，都可以成为辅助项目风险识别的维度。
分析
风险识别的是具体的事件，我们需要能讲明白它的前因后果，这样才能透彻的分析它。这里往往需要从内因出发，可以按照原因-》事件-》影响 三段论来进行分析：风险起因-驱动点或触发点；风险事件-风险发生时的场景；风险影响-结果。如果起因还没有出现，则风险发生的概率较小；同时，起因的临近度也是个重要的考虑因素，因为随着时间的推移，各种内外部条件发生变化，“因”也可能随之改变。
举个栗子：
01
时间不够
可以分析是哪个阶段的时间不够，哪项工作的时间不够，该项工作是否在关键路径上；是被其他项目挤占了时间还是因为情绪低落导致工作效率变低。等等。透彻分析之后，找到因，才能明确他是不是真正的风险，才能找到应对之策。
02
需求变化
了解需求的背景，对需求进行挖掘，做深入性的分析，甚至引导客户需求，都是为了减少需求变化的概率，如果能判断哪些是真正的需求，能解决客户的痛点，这部分就是相对确定的、优先级最高的需求点。
如何应对风险？
PMBOK中把风险的应对归纳为风险规避、降低、转移、后备、应急、共享等几个方面的措施，而不论是哪种措施，最终都需要落实到具体的、合适的人身上。“具体的”是指，明确某一个人，而不是一群人；“合适的”是指有能力应对的人，而不一定是责任承担者，更不能是欺负最弱的人。
最后，风险识别和应对，是整个项目团队需要做的事，而不是项目经理一个人的事。风险管理形成的风险检查表或风险识别清单，是一份宝贵的组织过程资产，给同类型的项目很好的风险管理指引，避免项目中过度依赖的个人经验。
写在最后
风险管理很重要，但也别光盯着威胁，再多关注一下威胁中潜藏的机会，也许也会有收获。
