一、风险类别
一般我们可以把风险分成下面几个类别：
| 序号 | 风险类别 | 风险来源 |
|---|---|---|
| 1 | 需求 | 需求不断新增； 需求频繁的变更； 需求变更导致项目计划调整； 需求变更导致测试用例调整及测试工作变更风险； 需求规划和定位不清晰； 干系人对需求的决策时间较长； 变更管理不能及时跟踪记录，周知各端开发和测试； 模块重构导致额外工作量； 新产品方向花费较多的设计时间; |
| 2 | 人员 | 项目人手不足 项目结束前有人离职 新入项目成员，额外的沟通成本 有问题的成员拖慢团队效率 项目缺乏关键核心人员 任务的分配与人员技能不匹配 |
| 3 | 流程 | 缺乏必要的标准规范 文档工作过多影响进度 进度跟踪不准确 向管理层撰写进程报告占用的开发人员时间比预期的多 软件项目管理花费的时间比预期的多 jira任务信息更新不及时 任务描述信息不够，导致沟通成本高 |
| 4 | 计划 | 理想的计划，但不现实 计划有遗漏了P0任务 工作量大于估算数 没有预留缓冲时间（学习、评审、分享等） 任务分配不合理 加班过多影响效率 先决条件的任务不能按时完成，影响后续任务 人员休假 节假日前后效率低 |
| 5 | 沟通 | 跨团队协调管理，沟通链路过多 缺乏激励措施，效率打折扣 项目成员之间有冲突，导致信息沟通不到位 沟通方式信息传递方式不明确不统一 对其他外部依赖沟通不到位 |
| 6 | 技术 | 复杂的技术调研选型时间长 开发环境不稳定导致联调延期 线上紧急问题修复影响当前开发进度 上线计划不完善 测试环境问题影响测试进度 研发提测质量低于预期影响测试进度 设计有逻辑漏洞导致返工 方案设计评审不够 对技术难点调研评估不足 code review未能提前发现代码问题 开发自测不充分 代码管理不充分 测试难度和复杂度未提前充分考虑 部署过程不熟悉导致过长时间 |
| 7 | 外部依赖 | 外部依赖接口没有按时交付 外部依赖产品不稳定，有问题 外部合作细节不到位 |
| 8 | 设备及环境 | 服务器没有及时到位 移动端设备机型是否全面 法律法规 技术大趋势 商业模式 市场竞争 |
二、风险应对方法
能在早期预期并应对到上述风险，已经很不错了，没必要对掌握之外的事情太过忧心。建议在早期做好调研，能应对一些常见的风险。以下整理了常见的风险，并结合自身经历提供应对措施。
2.1 常见风险及应对方法
- 需求
明确用户需求和产品方向，减少后期的变动。 例如规定在一个固定时间盒不接受新增需求；以双版本开发为例，每周四发版。在周五QA测试完成后，版本锁死，不再加新需求。如果确实是当周版本有紧急功能，则拉组要求知会各角色负责人，审批后再开发测试上线。对于线上紧急问题处理，比如热更，采用同样的要求，知会各角色负责人并经审批同意后执行。
- 技术
早点准备技术调研，让资深技术人员根据项目实际情况做好最合理的技术选型。例如程序方面采用集中评审代码，安排多次代码评审；打通Jira和Git仓库做好功能跟进；QA测试时扩大冒烟测试用例范围，开发自动化测试脚本将常规问题跑通，保证能正常运转；
- 计划
适当改变项目的功能范围，保证计划上线；例如强节点任务为抢上线时间，适当对需求排优先级，高优先级保证按计划完成，非高优先级或者非强节点任务则安排至下一版本上线；计划排期充分考虑到节假日，学习、开会、评审、请假等缓冲时间；
- 沟通
维护好公共的需求变更记录wiki页面，建立项目各角色的聊天群组、邮件列表，任何变动及时周知干系人；详细记录各角色间的进度修改和内容文档同步进度，例如策划文档修改、ux文档、程序联调文档；
- 流程
规范发布流程必备内容，包含Release note 、Code review报告 、功能测试报告 、异常测试报告、性能测试报告，另外要求开发负责人，开发，QA，SA/DBA等重要干系人务必参与评审给出意见；以双版本开发为例，周四发版则周三下班前定期发维护测试报告，线上较大定级问题发报告，定期发功能进度报告；版本发布、线上更新制定规范流程；
- 设备环境
可能出现硬件环境故障导致线上游戏宕机，例如机器故障。可以定期维护检查机房环境，采购新机器，对已经到期或者快过期的机器定期按批次更换。
2.2 制定预案
- 人员方面 例如近期项目人员有变动，查看是否可以提前准备招聘和新人培训流程。如果没有名额，寻求哪些人可以做备份人员。
- 运营数据方面 项目上线后我们需要相关数据分析，先期做好埋点，区分好数据源。例如UX和程序对接处理，按照统一ux格式做好日志埋点和统计；预计运营根据节假日有多个运营活动，那先期做好开关，做好多个banner切换等等，程序做动态代码和活动日期控制等。
三、总结
没有风险，就是最大的风险。对每一次的项目管理案例进行总结，无论是成功还是失败，从中汲取经验和教训，从而完善自己的风险管理能力。
