浅谈互联网项目风险管理

查理·芒格经常引用的一句谚语：“如果我知道我会死在哪里，那我一辈子都不会去那里。”这种逆向思维模型，是我们工作中可以用到的思维模型。

每个项目，都是一场或大或小的战役，而在项目管理过程中风险无处不在，如果我们知道接下来会有哪些风险，那就可以提前准备做好预案，从而大大提升我们项目的成功交付率。项目经理总在操心各种不确定性，需求、决策、团队成员、进度等等。

除了这份担忧，我们需要对项目有整体的全景认知，认真详细的提前考量各种约束风险，并且在各种实战中积累出一套成体系的风险管理方法实践，用这样的方法做风险管理，我们才能做到胸有成竹，将风险降到最低，最大化的提升项目交付效率。

项目经理尽量在项目早期，把能想到的所有风险都列出来，提前做好准备。

一个健康的项目，风险数目应该随着时间线呈现递减情况，这样才能在可控范围内。

一个事项不确定是否有风险，还是算作有风险点的，风险是可能发生的事情，风险控制就是要保证一些风险不发生或发生了有应对的措施。

为此，我们可以维护一个互联网项目常见的风险列表。

在项目初期对照风险列表，逐一核对形成一份项目的早起风险清单，并将这份风险清单文档及时透明公示给项目组干系人，让每个人都提前意识到有这些风险，群策群力产出对应的解决方案。

“今天的问题，就是昨天的风险”。

那互联网项目风险都来自于哪里呢？

一般我们可以把风险分成下面几个类别：

有了以上清单，那很多风险你就可以提前开始准备对策了。

首先，我们要有一个好的心态，能在早期预期到这些风险已经很不错了，也不必为了完全在掌控之外的事情太忧心。比如说测试负责人要离职，开发人员有变动，团队高层调动，项目临时被取消等等。 这些风险尤其对于弱矩阵项目管理，过于担心反而影响协调执行的有效性，更应该保持乐观的心态应对这些风险，积极应对。

其次，项目早期做好调研：明确用户需求和产品方向，减少后期的变动；早点准备技术调研，让资深技术人员根据项目实际情况做好最合理的技术选型。对常见的风险（需求不断新增，代码提测质量差，计划排期不准，变更记录不全未周知，发布流程不规范等），可以用对应的更完善的流程来缓和和预防问题的发生。

例如规定在一个固定时间盒不接受新增需求:采用集中评审代码，安排多次代码评审，打通Jira和Git仓库做好功能跟进，扩大冒烟测试用例范围；适当改变项目的功能范围，保证计划上线；计划排期充分考虑到节假日，学习、开会、评审等缓冲时间；维护好公共的需求变更记录wiki页面， 建立项目各角色的聊天群组、邮件列表，任何变动及时周知干系人；规范发布流程必备内容，包含Release note 、Code review报告 、功能测试报告 、异常测试报告（若有） 、性能测试报告（若有），另外要求开发负责人，开发，QA，PE/SA/DBA重要干系人务必参与评审给出意见。

学会将风险交给专业的团队负责。

例如：专业DBA负责数据库模块；专业性能测试团队负责性能 ；让专业的法务、专利团队负责法律条款的草拟和审核；提交工单申请信息安全部做专业安全测试；如果安全要求高，还可申请经费请外部白帽子团队做进一步的安全测试等。

学会制定预案，很多工作可以提前做好规划。

例如说人员有变动，是否可以提前准备招聘流程，如果没有名额，哪些人可以做备份人员。

项目上线后我们需要相关数据分析，那先期做好埋点，区分好数据源；预计运营根据节假日有多个运营活动，那先期做好开关，做好多个banner切换等等。

最后

从每个项目中汲取经验，完善自己的风险管理能力。从一开始的问题事发之后疲于应对；到能动员资源解决问题；再到提前预测风险，从定性分析到定量分析，做好有效准备；最后如果能把问题变为机会，那就更棒了。如果每个风险都是坑，那学会如何优雅的跳过，走出凌波微步；更或是填好坑，作为下次起跳的垫脚石，越走越高，看到更高的风景。

本文得益于邹欣老师的《构建之法》及Johanna Rothman的《项目管理修炼之道》, Mona的《小议风险管理及在互联网项目中的应用》。 综合这一年多来在项目中的实践学习，在这里和大家探讨。

最后用Aaron Wildavsky的一句话 “没有风险，就是最大的风险”与大家共勉。

作者：李慧，来源：网易杭研项目管理