风险管理的四大阶段
之前的写的文章里，多多少少结合个人的经验，也谈到过一些跟风险相关的话题，作为PM的一项相对高阶的管理技能，今天呢，理论 实践参半，再继续探讨探讨。风险管理其实也是一个蛮大的话题，应用到不同领域，有不同的处理方式。这里结合互联网的行业背景，只先粗浅的说说风险管理的四个阶段。
说直白点儿，其实风险管理跟看病求医一样，没啥区别。举个可能不太恰当的例子，比如，担心流感，打个预防针神马的，这叫风险预防；但是，很不幸，还是感染上了小风寒，那就得打针吃药，这叫风险应对；如果更不幸，染上了某种危险的流感病毒，这时候情况就更复杂了，可能不止个人，都牵动到国家层面出面应对，这叫风险应急，结果发现病毒的源头来自家禽，还得责令屠宰，并安抚养殖户，事后，没准儿既要总结经验教训，又要出台各种政策对家禽的圈养方式进行改革整顿，这叫风险总结。总结归纳起来，风险管理的也无非就这几个阶段：风险预防、风险应对、风险应急、风险总结。
当然，风险越早处理，损失和影响越小，最好是未雨绸缪，防患于未然，所以预防为上；但是，不好意思，风险还是发生了，那就要想办法减缓风险的影响；再但是，如果因为各种原因，已经造成了非常严重的影响了，那就得应急、接受、再检讨。
要做好预防工作，先得做好风险识别，才能有的放矢。那我们暂时先把话题转移到如何识别风险的问题上来。结合个人的经验，也跟大家分享下有哪些更为具体的方法。
1. 业务数据。你的产品预计有多少受众的用户量，当前的系统能支撑到多少量级的用户？
2. 历史经验。曾经碰过的壁，踩过的坑。
3. 专家意见。相比于低效能的头脑风暴，我更倾向于向各个领域的骨干征求意见。相信大家也见识过一堆人一起讨论的时候，要不漫无边际，要不就沉默不语，再加上，greenhand受限于自己的经验，也提不出多少有价值的信息来。
4. 共性问题。我们身处互联网行业，那自然有这个行业的一些共性问题，比如，用户范围广、产品使用环境各异、需求变化快、版本时间短等。
5. 类似项目。其实，在互联网行业里，PM大多时候聚焦在一个业务上，这对于大家从类似项目中积累经验有着极大的帮助。即使是同一领域的不同业务，我们总也能借鉴些经验来。
6. ...
这里不在赘述，相信大家也各自有自己一套解决问题的思路和法子。
风险识别说完了，那剩下的事情就是规避风险，以及准备风险预案了。比如，前面开始提到的，冬天怕流感那就先打预防针，流感是我们识别到的风险，预防针就是规避风险了。在项目中，规避风险以及准备风险预案的例子也很多，比如：
1. 我们担心需求理解不一致、实现不符合预期，所以我们有需求评审、有方案评审、还有产品体验等各个环节
2. 我们担心产品质量不过关，所以有技术方案评审、代码走查、自测、测试验证、外团用户体验、灰度等环节
3. 我们担心需求用户不买账，所以有后台开关控制随时切换，或者准备好替代版本随时更替
4. 我们担心用户量太多，服务器压力扛不住，所以会做服务器的压力评测、扩容
5. ...
第二阶段：风险应对
即使再缜密的规划和预防，事实上百密还是难免一疏，更何况，有的风险我们即使知道，也奈何不了，问题照样还是来了。此时，需要我们采取相应的措施已缓解或者抵消风险。最先想到的就是实施风险预案，比如：
1. 产品发布到外网后，用户不买账，前面提到的后台开关控制、替代版本等都是我们可选择的应对方案
2. 当发现用户量有较大增长趋势，服务器压力逼近警界线，那么选择扩容或者部分拒绝服务，也是我们在这种情况下可选择的应对方案
3. ...
总结起来，这个阶段所要做的事情无非是：采取一定的应对方案缓解损失或者抵消损失，防止问题进一步蔓延。这也分两种情况，一种是针对已经有风险预案的，选择合适的方案来应对；二是，没有风险预案或者虽有，但是使用的时机未到，此时，需要有相应的权宜之计，防止问题扩大化，并且能为最终解决问题争取时间、创造条件。比如，服务器压力抗不住了，一时半会儿没有预先申请好的服务器用来扩容，为了避免服务器瘫痪，先拒绝部分服务，为扩容赢得时间、创造条件。
第三阶段：风险应急
此时，风险已经发生，且已在事实上造成较大损失或者不良影响，这时怎么办呢？没辙，只能紧急应对。比如，发生了火灾且已蔓延，难以控制，此时就只能施救。比如，我们策划了一个活动，因为忽略了产品上的某个历史因素，导致购买该产品的用户，享受不到本应得到的服务，最快速的响应可能是：尽快下架这个活动，发一个事故说明，再给这些用户一定的物质或者精神上的安抚。
第四阶段：风险总结
风险发生了，也造成损失了，但不能白白发生了，是吧。吃一堑总要长一智，这才是学习之道。所以，末了，要善于总结经验教训，把这些意料之外的风险，纳入到我们的管理计划中，想好对策，以免未来再吃亏。毕竟我们做的不是一锤子买卖，今天的经验教训，便是明天的财富。
案例分享
说了这么多，我还想再介绍一个比较成功的案例“DTS音效接入”，在另外一篇文章《项目中的那些别人家的孩子》里也有提到，这里围绕今天的主题再换个角度聊聊。
首先，风险已经识别到。引入第三方库，而且是初次开发、未曾正式使用过的库，初次接入，无论效果表现，还是产品质量都是未知数。为此，我们预备以及采取了哪些手段来避免、缓解、以及应对呢？
一、避免招式
1. 卷入各方的定期沟通会议，及时反馈、跟进、解决项目过程中的问题。
2. 专业人士的帮助，为音质效果好坏做初步的判断和保证。
3. 专项测试，保证基础质量过关。
4. 内部体验，音质效果好坏小范围内做初次评测。
5. 开关控制，设定完工deadline，到期如果还未能达到较为满意的标准，随时做好不上线的准备。
二、缓解/应对招式
1. 插件化，有问题，随时替包。事实上，版本灰度期间，这招我们就用上了。时值谷歌推广Android 5.0系统之际，先前的插件包在5.0系统上下载时会出现持续载入无法下载的问题，当发现问题后，立即进行了修复并且替换了插件包。
2. 逐步灰度，试探用户反馈，把影响降低到最小。
3. 放低姿态，安抚用户。大概的意思就是：初次和大家见面，如有照顾不周，还请大家多多包含，有问题大家尽管提，我们逐步改善。先降低用户的预期，做好了，很容易让用户满足，有超出预期的赶脚，做不好了，用户也不会抱怨，反馈出来，我们逐步改进。
三、效果总结
12.1日的数据为例，外网来自该入口的反馈是常规入口反馈的4～5倍，其中正向的反馈占比80%以上，不满意的反馈以及BUG类反馈占比不到15%，而常规入口的BUG反馈占比高达60%以上，并且DTS音效还获得了当月微创新的第四名，效果相当赞！