这一节来和你聊「风险」，我刚入行的时候，得益于行业早期，没有什么规矩，两任领导对我都很宽容，甚至纵容，于是真的是随心所欲地成长，当然也算是无法无天地工作。后来，我自己带团队，随着带过的团队越来越多，团队的规模越来越大，我发现，一些新入行的新手，很像我当年的状态，有冲劲，敢想敢做，有些人做成了，有些人做败了，但还有一些人做死了，于是我去复盘，我发现，有一些做「死」的项目或者业务，都碰到了同一个问题，那就是对风险的控制不足，导致死亡。
这里的「风险」其实有很多，按照轻重缓急，大概有这么些类型：
先列这些，然后我拿其中一个风险，譬如说「开发延期」，给你表演一下：
老大：小王，还有 3 周就劳动节了，你活动准备的怎么样了？ 小王：放心，劳动节活动我早就和开发沟通过了，没问题。 ↓ ↓ ↓ 时间到了 4 月 28 日…… 开发：小王啊，这活动是要 5 月 1 日上午上，还是下午上？ 小王：哥你啥意思啊？还有 3 天就要上线了啊，我都外宣了，可别上不了啊！？ 开发：不会不会，你就说是上午还是下午。 小王：能上就行，其实最好是提前上线，到时候对外打开。 ↓ ↓ ↓ 2 天后…… 小王：哥，咋样，今天能上去明天再对外打开不？ 开发：啥？要测试呢，明天晚上能测完就不错了，还今天上线明天对外，你想啥呢？ 小王：不是，之前不是说好的吗？ 开发：啥时候说好啥了？ ……
到了这一步，接下来小王就要去找老大帮忙了。老大帮忙的方法通常是下面几个动作：
- 去找相关的开发人员的 Leader，确认风险点
- 针对提出的风险点，讨价还价一下，提前一些当日上线
- 感谢开发人员和 Leader 的大力配合，要求当晚小王陪着盯测试，搞不好自己也一起盯着
- 完事儿了请个奶茶吃个饭啥的
其实，延期风险之所以常见，有很大一部分原因，是在于运营人员的工作做得不够细，而开发的工作又很繁重，造成项目进度的管理上出现了问题。那么，应对这个风险，运营的老鸟应该怎么做呢？我的个人看法是分成下面几个部分来展开，我用针对「延期风险」的风险控制方法来举一个例子： 第一步，做好心理准备。
这一步的意思是，作为一个运营，你不能认为「延期风险」不会发生，你应当认为「延期风险」很大概率会发生，甚至必然发生，为了应对这个风险，你需要提前着手做出一系列设计。
那么基于这个心理准备，你应当静下来心来去穷举，如果真的遭遇了「延期风险」，有可能的直接原因是什么？
这里就涉及到整个过程的分析，和对相关的利益相关者的认知了。我们来分析一下，一般情况下，「延期风险」发生在需要开发的部分，那么一但设计开发，就要分为需求方和实现方两个大的角色，而根据整个工作的链条呢，
我们可以这样划分：
需求方 实现方 角色 运营 设计 开发 测试 做什么 提出需求 页面设计 实现业务开发 检查开发错误并要求改正
那么，你大概率能搞明白了，我们有可能碰到这些导致「延期」的原因：
- 需求整理和提出的过程中出了问题，包括：• 需求本身没有讲清楚• 需求的理解过程中，不同的角色理解不一致• 需求提出后，不同的角色的修改意见不一致• 需求落实中出现了偏差• ……
- 需求实现的过程中出现了问题，包括：• 需求变更的范围大• 需求变更的频次高• 其他业务影响到了现有的需求实现过程• 测试用例覆盖不够• 测试轮次覆盖不够• 上游未按时间交付挤压下游的工作计划• ……
那么，我们就要针对这些问题去制定策略了。譬如说，针对需求整理和提出过程问题，我们可能就要去设计一个有效的需求评审机制，比如这样： 在活动需求的创意产生后，用一个最简单的脑图去开一个评审会，评审会上，开发和设计先就活动的规则、文案、设计做一个大概的评估，并给出一些意见。
这个环节的价值是：让相关环节提前知道接下来要提活动需求了，提前做好人力和思想上的准备；然后拿着这些意见和建议，去完善需求文档，再开一次，邀请设计、开发、测试的同学们参会，有必要的时候，还应该叫上产品，大家再开一个评审会，这个会上需要完成的，其实是先确认实际要完成哪些工作来实现需求，然后是各个小组的 Leader 定好进入活动开发的人员，约定开发方案的确认和排期确认时间；再下一次会议，就是各个环节的时间节点、负责人确定好，开发介绍方案，设计按节点给设计图，测试邀请 review 用例，运营准备 Check List……
这样一套工作，如果真的能够好好做出来，那么「延期风险」出现的可能性就有机会被大大降低。
所以，风险意识的价值，并不是说，有了风险意识，就能够避免风险，而是，因为风险意识的存在，所以，我们始终可以有预案应对不利状况，把因此带来的风险的级别降低。
与其说，风险意识应对风险的意识，不如说，风险意识是为风险做足预案的思维方式。我们或许并不是无时无刻都在面对风险，但「预案」对所有人所有事儿来说，都极为重要。希望你可以具备这样的意识，帮助你应对生活和工作中的各种可能发生的问题。
