一个项目经理如果一直在项目中处于救火状态，那他就不是一个好项目经理。我所接触到的项目经理中，大家最常犯的一个错误，就是低估项目难度导致进度不可控制。
由此，我今天想和大家讨论的主题，就是项目风险管理了。
项目中不可能没有风险，正如理财一样，没有风险就没有收益。低风险低收益，高风险高收益。而我们都知道著名的墨菲定律，既有可能出错的事就一定会出错。项目中也一样，风险如果存在，就代表他一定会发生。
项目经理的主要职责之一，实际就是控制风险，监控风险，把风险扼杀在早期。如果项目风险管理的不好，那项目经理乃至项目团队就会变成项目风险的奴隶。被风险赶着往前跑，哪里有窟窿就往哪里上，被迫放弃正常的开发计划，导致项目延期。
以下内容，我将会和大家讨论一下项目中的风险有哪些，我们应该如何避免：
项目风险有哪些？
在项目管理领域，有对项目风险非常详细的划分，但我个人并未学过PMP相关内容，所以以下风险都是从工作中总结而来。
从我个人的经验来说，我将项目风险分为三种：不可抗力风险、外部风险、内部风险。每类风险都整理出一个列表，当做参考。
不可抗力风险通常来说和项目经理无关，也不是项目经理可以把控和处理的风险。而外部风险和内部风险，都应处于项目经理的监控之下。这两方面的风险控制好了，项目就得以顺利推进。若控制不好，那可能项目中就一直处于救火状态，甚至抢救不回来导致项目崩盘。
不可抗力风险：
- 甲方资金链断裂
- 甲方中途停止项目
- 投资方撤资
不可抗力风险超出了项目经理和项目团队的责权范围，通常不予以考虑。若真遇上这类风险，应报告的是你的上级/老板，以将自身的损失进行控制。
来自外部的风险：
- 需求变更频繁
- 需求不清晰
- 需求规划和评审周期较长，挤压了开发时间和测试时间
- 来自外部的接口或数据无法按预期得到
- 来自外部的接口或数据达不到预期要求
- 与本系统相连的外部系统无法正确工作，导致不可预知的问题
- 测试环境强依赖与外部接口或产品，由于无法得到该接口/产品，无法测试
- 客户或者主要干系人对交付产品不满意
- 客户或者主要干系人对页面样式/风格不满意
- 客户希望预期一个无法达到的交付时间
- 客户或主要干系人要求的兼容性比预期要复杂
- 开发设备故障
- 开发设备性能不足，影响开发
- 异地协作，无法当面交流导致的沟通效率降低
来自内部的风险：
- 干系人不清晰
- 技术选型无法满足要求
- 项目计划不合理导致的项目混乱
- 产生了许多不在计划中的工作
- 乐观估算导致工期不足
- 任务分配不合理，导致的开发人员工作量不均衡
- 对技术难点评估不足，低估技术难点
- 遗漏或错误的估计兼容性对系统的影响
- 遗漏或错误的估计性能问题对系统的影响
- 分别设计开发的各子模块无法快速集成甚至无法集成
- 系统设计质量不高，导致实现困难或花费更多成本
- 使用不熟悉的技术，导致开发周期延长
- 未进行有效code review，导致前期应处理避免问题反复发生
- 代码版本管理不到位导致版本混乱或代码被覆盖
- 开发自测不充分既提测，导致测试困难甚至测试工作阻塞
- 流程过于繁琐，在流程上浪费了过多时间
- 流程过于简单，导致有效沟通不足
- 项目组成员无法全身心投入项目（被其他项目或事务拖住）
- 项目组成员间沟通方式不明确
- 项目组内信息传递方式不明确
- 项目组内气氛紧张甚至冲突，导致项目必要沟通缺失
- 项目组士气低下导致进展缓慢
- 人员变动
如何识别项目风险
类似于上面的项目风险列表是有用的，可以逐一排查列表，去关注项目中的风险点。但每个项目的风险点不尽相同，需要对项目的状态了然于胸，才能推敲出项目中可能存在的特定风险。你所有的疑问和质疑，都可能是项目中发送风险的地方。
如何应对以避免风险
列表中的风险，我总结为需求风险、沟通风险、计划风险、技术设计风险、成员风险等五类。我针对每类风险，提供我自己的解决思路。
需求风险
需求变更无可避免，几乎每个项目都一定会涉及到需求变更。原因不外乎前期沟通双方理解不一致、干系人突然冒出新想法等等。
我一般做一下几点来应对需求风险：
- 需求阶段勤沟通、出原型、签需求定稿承诺等
- 需求周期若过长，则沟通要够开发时间，否则会坑团队和自己
- 需求评审阶段积极提出自己的疑问和优化意见
沟通风险
沟通风险我认为是在项目中最常见的问题。项目组内，客户与项目经理，沟通不及时导致大家信息不对称。可能造成重复工作，互相等待等情况。所以一个有效的沟通机制是很有必要的。
我一般是采取如下方式：
- 项目组内以讨论组的形式进行沟通，所有交流公开透明
- 职权分明，没人在项目组中的工作定义清晰，让同事想找对应负责人的时候容易找到
- 周会形式，每周周会沟通项目整体情况并解决问题
- 检查进度过程中，若发现交流问题，督促并协调解决
- 与客户方指定主要干系人，仅与主要干系人沟通
- 需要主要干系人处理的事情，积极主动推进，不被动等待
- 外部接口和数据工作主动积极的采用邮件方式催促主要干系人进行处理，并告知其影响的工期
计划风险
计划风险一般都是由项目经理自己造成的风险。通常由于对技术难点预估不足，自身经验不足，对项目考虑不全面等情况造成。
要解决这个问题，我认为除了项目经理提升自己别无他法：
- 提升自己的经验
- 通过列表形式也好，请教也好，将可能发生的情况考虑全面
- 制定计划阶段辅助于甘特图等工具，合理安排开发任务
- 如果有可能，将自己的项目计划与上级和平级进行讨论
技术设计风险
技术设计风险一般由架构成员造成，如果类似于我这样项目经理同时兼任技术经理。那此部分风险造成的原因，也是我们自己的问题。
- 负责技术设计的人一定要确保全面了解需求
- 负责技术设计的人要考虑用户数量、数据量、兼容性等问题
- 技术选型过程中，项目组要能兜住底。不要出现框架、中间件出了问题自己搂不回来的情况
- 开发早期一定要频繁进行 code review，最好是每天。早期每天一小时的代码review，剩下的可能是后期10天的时间
- 采用版本管理工具 SVN 或者 Git 进行版本管理。不能提交的文件需要反复和开发成员强调
- 项目中的技术难点需要仔细推敲，多方考证，确保可以完成，并提前预备解决方案
成员风险
项目经理的一个主要职责还要多关注团队情况，在团队士气低落时，给予激励。在团队浮躁时，给予批评和压力。团队内起矛盾时，积极调和。发现项目中的不稳定因素时，要提前预备解决办法。比如调离问题成员；成员离职时，补充人员或任务转移等。
总结
项目风险是一定会存在的，但我们要尽可能的发现和应对项目风险。把项目风险扼杀于襁褓之中。
正如魏文王见扁鹊一样。
魏文王召见扁鹊，问他说你家的三个弟兄我听说都学医，那么谁的医术最高啊？扁鹊脱口而出：我大哥的医术最高，我二哥其次，我最差。
魏文王就很惊讶，问：那你为什么名动天下，他们两人一点名气没有？
扁鹊说：我大哥的医术之高，他一个人可以做到防范于未然。这个人病未起之时，他一望气色便知，然后用药把你调理好了，所以天下人都以为他不会治病，他一点名气都没有。也就是我们今天所谓的健康保健。
我二哥的能耐是能治病初起之时。一个人以后他要酿成大病，咳嗽感冒的时候，他用药将他治好了。所以我二哥的名气仅止于乡里，认为是治小病的医生。
我呢？就因为医术最差，所以一定要等到这个人病入膏肓、奄奄一息，然后下虎狼之药、起死回生。好了，全世界以为我是神医。
希望各位都能把风险扼杀在早期，项目推进过程中一切顺利。以上所有内容，我也有许多知道但没做好的地方，共同努力。
参考书目
《网易一千零一夜》