不要成为项目风险的奴隶

一个项目经理若是一直在项目中处于救火状态，那他就不是一个好项目经理。我所接触到的项目经理中，你们最常犯的一个错误，就是低估项目难度致使进度不可控制。

由此，我今天想和你们讨论的主题，就是项目风险管理了。

项目中不可能没有风险，正如理财同样，没有风险就没有收益。低风险低收益，高风险高收益。而咱们都知道著名的墨菲定律，既有可能出错的事就必定会出错。项目中也同样，风险若是存在，就表明他必定会发生。

项目经理的主要职责之一，实际就是控制风险，监控风险，把风险扼杀在早期。若是项目风险管理的很差，那项目经理乃至项目团队就会变成项目风险的奴隶。被风险赶着往前跑，哪里有窟窿就往哪里上，被迫放弃正常的开发计划，致使项目延期。

如下内容，我将会和你们讨论一下项目中的风险有哪些，咱们应该如何避免：

项目风险有哪些？

在项目管理领域，有对项目风险很是详细的划分，但我我的并未学过PMP相关内容，因此如下风险都是从工做中总结而来。

从我我的的经验来讲，我将项目风险分为三种：不可抗力风险、外部风险、内部风险。每类风险都整理出一个列表，当作参考。

不可抗力风险一般来讲和项目经理无关，也不是项目经理能够把控和处理的风险。而外部风险和内部风险，都应处于项目经理的监控之下。这两方面的风险控制好了，项目就得以顺利推动。若控制很差，那可能项目中就一直处于救火状态，甚至抢救不回来致使项目崩盘。

不可抗力风险：

1. 甲方资金链断裂
2. 甲方中途中止项目
3. 投资方撤资

不可抗力风险超出了项目经理和项目团队的责权范围，一般不予以考虑。若真赶上这类风险，应报告的是你的上级/老板，以将自身的损失进行控制。

来自外部的风险：

1. 需求变动频繁
2. 需求不清晰
3. 需求规划和评审周期较长，挤压了开发时间和测试时间
4. 来自外部的接口或数据没法按预期获得
5. 来自外部的接口或数据达不到预期要求
6. 与本系统相连的外部系统没法正确工做，致使不可预知的问题
7. 测试环境强依赖与外部接口或产品，因为没法获得该接口/产品，没法测试
8. 客户或者主要干系人对交付产品不满意
9. 客户或者主要干系人对页面样式/风格不满意
10. 客户但愿预期一个没法达到的交付时间
11. 客户或主要干系人要求的兼容性比预期要复杂
12. 开发设备故障
13. 开发设备性能不足，影响开发
14. 异地协做，没法当面交流致使的沟通效率下降

来自内部的风险：

1. 干系人不清晰
2. 技术选型没法知足要求
3. 项目计划不合理致使的项目混乱
4. 产生了许多不在计划中的工做
5. 乐观估算致使工期不足
6. 任务分配不合理，致使的开发人员工做量不均衡
7. 对技术难点评估不足，低估技术难点
8. 遗漏或错误的估计兼容性对系统的影响
9. 遗漏或错误的估计性能问题对系统的影响
10. 分别设计开发的各子模块没法快速集成甚至没法集成
11. 系统设计质量不高，致使实现困难或花费更多成本
12. 使用不熟悉的技术，致使开发周期延长
13. 未进行有效code review，致使前期应处理避免问题反复发生
14. 代码版本管理不到位致使版本混乱或代码被覆盖
15. 开发自测不充分既提测，致使测试困难甚至测试工做阻塞
16. 流程过于繁琐，在流程上浪费了过多时间
17. 流程过于简单，致使有效沟通不足
18. 项目组成员没法全身心投入项目（被其余项目或事务拖住）
19. 项目组成员间沟通方式不明确
20. 项目组内信息传递方式不明确
21. 项目组内气氛紧张甚至冲突，致使项目必要沟通缺失
22. 项目组士气低下致使进展缓慢
23. 人员变更

如何识别项目风险

相似于上面的项目风险列表是有用的，能够逐一排查列表，去关注项目中的风险点。但每一个项目的风险点不尽相同，须要对项目的状态了然于胸，才能推敲出项目中可能存在的特定风险。你全部的疑问和质疑，均可能是项目中发送风险的地方。

如何应对以免风险

列表中的风险，我总结为需求风险、沟通风险、计划风险、技术设计风险、成员风险等五类。我针对每类风险，提供我本身的解决思路。

需求风险

需求变动无可避免，几乎每一个项目都必定会涉及到需求变动。缘由不外乎前期沟通双方理解不一致、干系人忽然冒出新想法等等。

我通常作一下几点来应对需求风险：

1. 需求阶段勤沟通、出原型、签需求定稿承诺等
2. 需求周期若过长，则沟通要够开发时间，不然会坑团队和本身
3. 需求评审阶段积极提出本身的疑问和优化意见

沟通风险

沟通风险我认为是在项目中最多见的问题。项目组内，客户与项目经理，沟通不及时致使你们信息不对称。可能形成重复工做，互相等待等状况。因此一个有效的沟通机制是颇有必要的。

我通常是采起以下方式：

1. 项目组内以讨论组的形式进行沟通，全部交流公开透明
2. 职权分明，没人在项目组中的工做定义清晰，让同事想找对应负责人的时候容易找到
3. 周会形式，每周周会沟通项目总体状况并解决问题
4. 检查进度过程当中，若发现交流问题，督促并协调解决
5. 与客户方指定主要干系人，仅与主要干系人沟通
6. 须要主要干系人处理的事情，积极主动推动，不被动等待
7. 外部接口和数据工做主动积极的采用邮件方式催促主要干系人进行处理，并告知其影响的工期

计划风险

计划风险通常都是由项目经理本身形成的风险。一般因为对技术难点预估不足，自身经验不足，对项目考虑不全面等状况形成。

要解决这个问题，我认为除了项目经理提高本身别无他法：

1. 提高本身的经验
2. 经过列表形式也好，请教也好，将可能发生的状况考虑全面
3. 制定计划阶段辅助于甘特图等工具，合理安排开发任务
4. 若是有可能，将本身的项目计划与上级和平级进行讨论

技术设计风险

技术设计风险通常由架构成员形成，若是相似于我这样项目经理同时兼任技术经理。那此部分风险形成的缘由，也是咱们本身的问题。

1. 负责技术设计的人必定要确保全面了解需求
2. 负责技术设计的人要考虑用户数量、数据量、兼容性等问题
3. 技术选型过程当中，项目组要能兜住底。不要出现框架、中间件出了问题本身搂不回来的状况
4. 开发早期必定要频繁进行 code review，最好是天天。早期天天一小时的代码review，剩下的多是后期10天的时间
5. 采用版本管理工具 SVN 或者 Git 进行版本管理。不能提交的文件须要反复和开发成员强调
6. 项目中的技术难点须要仔细推敲，多方考证，确保能够完成，并提早预备解决方案

成员风险

项目经理的一个主要职责还要多关注团队状况，在团队士气低落时，给予激励。在团队浮躁时，给予批评和压力。团队内起矛盾时，积极调和。发现项目中的不稳定因素时，要提早预备解决办法。好比调离问题成员；成员离职时，补充人员或任务转移等。

总结

项目风险是必定会存在的，但咱们要尽量的发现和应对项目风险。把项目风险扼杀于襁褓之中。

正如魏文王见扁鹊同样。

魏文王召见扁鹊，问他说你家的三个弟兄我据说都学医，那么谁的医术最高啊？扁鹊脱口而出：我大哥的医术最高，我二哥其次，我最差。
魏文王就很惊讶，问：那你为何名动天下，他们两人一点名气没有？
扁鹊说：我大哥的医术之高，他一我的能够作到防范于未然。这我的病未起之时，他一望气色便知，而后用药把你调理好了，因此天下人都觉得他不会治病，他一点名气都没有。也就是咱们今天所谓的健康保健。
我二哥的能耐是能治病初起之时。一我的之后他要酿成大病，咳嗽感冒的时候，他用药将他治好了。因此我二哥的名气仅止于乡里，认为是治小病的医生。
我呢？就由于医术最差，因此必定要等到这我的病入膏肓、奄奄一息，而后下虎狼之药、起死回生。好了，全世界觉得我是神医。

但愿各位都能把风险扼杀在早期，项目推动过程当中一切顺利。以上全部内容，我也有许多知道但没作好的地方，共同努力。

参考书目

《网易一千零一晚上》