浅谈互联网项目风险管理

猪小花1号2018-08-28 14:55


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

每个项目,都是一场或大或小的战役,而在项目管理过程中风险无处不在,如果我们知道接下来会有哪些风险,那就可以提前准备做好预案,从而大大提升我们项目的成功交付率。项目经理总在操心各种不确定性,需求、决策、团队成员、进度等等,但除了这份担忧,我们需要对项目有整体的全景认知,认真详细的提前考量各种约束风险,并且在各种实战中积累出一套成体系的风险管理方法实践,用这样的方法做风险管理,我们才能做到胸有成竹,将风险降到最低,最大化的提升项目交付效率。

1、   项目早期列出各项风险

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

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

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

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

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

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

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

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

 No.

风险的类别

风险的来源

1

需求

需求不断新增

需求频繁的变更

需求变更导致项目计划调整

需求变更导致测试用例调整及测试工作变更风险

需求规划和定位不清晰

干系人对需求的决策时间较长

变更管理不能及时跟踪记录,周知各端开发和测试

模块重构导致额外工作量

新产品方向花费较多的设计时间

2

人员

项目人手不足

项目结束前有人离职

新入项目成员,额外的沟通成本

有问题的成员拖慢团队效率

项目缺乏关键核心人员

任务的分配与人员技能不匹配

3

流程

缺乏必要的标准规范

文档工作过多影响进度

进度跟踪不准确

向管理层撰写进程报告占用的开发人员的时间比预期的多

软件项目风险管理花费的时间比预期的多

JIRA任务信息更新不及时

任务描述信息不够,导致沟通成本高

4

计划

理想的计划,但不现实

计划有遗漏了P0任务

工作量大于估算数

没有预留缓冲时间(学习,评审,分享等)

任务分配不合理

加班过多影响效率

先决条件的任务不能按时完成,影响后续任务

人员休假

节假日前后效率降低



5



沟通

跨团队协调管理,沟通链路过多

缺乏激励措施,效率打折扣

项目成员间有冲突,导致信息沟通不到位

沟通方式信息传递方式不明确不统一

对其他外部依赖沟通不到位







6







技术

复杂的技术调研选型时间长

开发环境不稳定导致联调延期

线上紧急问题修复影响当前开发进度

上线计划不完善

测试环境问题影响测试进度

研发提测质量低于预期影响测试进度

设计有逻辑漏洞导致返工

方案设计评审不够

对技术难点调研评估不足

code review未能提前发现代码问题

开发自测不充分

代码管理不到位

测试难度和复杂度未提前充分考虑

部署过程不熟悉导致过长时间


7


外部依赖

外部依赖接口没有按时交付

外部依赖产品不稳定,有问题

外部合作细节不到位



8



设备及环境

服务器没有及时到位

移动端设备机型是否全面

法律法规

技术大趋势

商业模式

市场竞争

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

2、   风险如何应对呢?

首先,我们要有一个好的心态,能在早期预期到这些风险已经很不错了,也不必为了完全在掌控之外的事情太忧心。比如说测试负责人要离职,开发人员有变动,团队高层调动,项目临时被取消等等。

这些风险尤其对于弱矩阵项目管理,过于担心反而影响协调执行的有效性,更应该保持乐观的心态应对这些风险,积极应对。

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

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

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

学会制定预案,很多工作可以提前做好规划。比如说人员有变动,是否可以提前准备招聘流程,如果没有名额,哪些人可以做备份人员。

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

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

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

最后用Aaron Wildavsky的一句话没有风险,就是最大的风险与诸君共勉。


网易云新用户大礼包:https://www.163yun.com/gift

本文来自网易实践者社区,经作者李慧授权发布。