1. 什么是风险？
说到风险这个词，相信大家脑子里已经有了很多画面，比如：
- 开发过程中没有写单元测试
- 数据库没有备份
- 下个月有个关键角色要离开团队
- ……
很明显，这些场景都会给项目的开发和交付带来不良影响，这些都是风险吗？
先来看看风险的定义：
风险是指在某一特定环境下，在某一特定时间段内，某种损失发生的可能性。 —— MBA智库·百科
风险是相对某有机体的，指某可能发生的事件（辞源于航海者），如果发生，能阻碍有机体的发展，甚至走向衰亡，风险是指事件发生与否的不确定性。——维基百科
风险有两个关键要素：
- 风险是可能发生的事件，具有不确定性
- 风险一旦发生，会产生损失或不良影响
回过头来再看看开头的几个场景，虽然都会产生不良的影响，但都是确定的事件，这些并不是风险（Risk），而是需要马上处理的问题（Issue）。作为Tech Lead，要能够区分风险和问题，风险是未来有概率发生的，需要提前干预管理，而问题是现在已经或正在发生的，需要马上解决。
2. Tech Lead为什么要关注风险？
既然风险并不是现在已知的问题，未来也不一定会发生，那为什么还要关注风险呢？有必要为一些概率性事件投入大量精力吗？
我们首先从统计学角度分析下风险发生的概率：
假设有10个风险，每个风险有10%的概率会发生，那么有一个风险实际发生的概率是：1 - 0.90^10 ≈ 65%。
也就是说，在这10个风险中，至少有一个会发生的概率超过了50%。如果这些风险的后果是很严重的，项目无法承受的，那无疑是一种灾难。显然，我们必须要采取措施，提前想好应对策略，防患于未然。
然而，风险管理是项目管理者一定会关注的，作为Tech Lead还需要关注风险吗？这不是重复的工作吗？如果两个角色都来管，工作职责边界好像也不清晰，不会带来问题吗？
讲一个真实发生的小故事：
在一个软件系统集成方案中，集成双方根据各自的需求一起讨论并确定了集成接口的契约，集成方式，调用频率以及性能要求，以及一些异常场景的处理方案。然而，集成双方并不了解对方的业务流程和数据流，很多问题都要等到集成联调测试或上线后才发现。当前项目的TL在跟对方闲聊技术时，无意中发现了对方的数据状态变更节点和自己这边的数据状态变更节点不完全一致，上线后一旦遇到某些特殊场景，就会block当前业务流程。于是发起了新一轮的方案讨论。
在跨系统集成的场景，不能想当然地认为对方系统是怎样工作的，更不能忽略未来上线的风险。
不同角色专业能力不同，能识别到的风险是不一样的，在软件开发项目中，Tech Lead在识别技术相关风险方面天然具有优势，更是责无旁贷。
By failing to prepare, you are preparing to fail. —— Benjamin Franklin
3. 有什么类型的风险？
从软件开发项目的各关键要素来看，交付过程中可能出现的风险大致可以分为下面几类：
设计相关风险
说起项目交付风险，很多人第一个想到的就是需求不明确带来的风险：一句话需求，需求变更，需求冲突等。虽然需求更多是业务分析师的工作，但Tech Lead可以从技术的视角帮忙评估需求相关风险带来的影响，需求之间是否存在技术方案上的冲突，Tech Lead同样要对不明确的需求保持警惕，要有敏锐的判断力。
除了关注业务方案设计，作为Tech Lead，更要主导和把关技术方案设计，降低未来的风险。然而，实际情况下的方案设计都是一种权衡，是对成本，对交付时间，对技术选择的权衡，并不存在绝对完美的方案，Tech Lead需要在技术方案设计时考虑到以下风险：
- 新技术引入带来的风险
- 新系统集成风险
- 上线失败回退的风险
- 安全风险，包括开源软件相关安全风险，数据安全等
运行时相关风险
有些项目除了关注开发阶段，同时也要负责后期的运维工作，对软件系统运行时的风险更要格外关注。如果说软件开发过程是在规定的时间内生产出合格的产品，那后期运维过程是让用户实际使用产品的过程，产品价值更多体现在后面，任何可能导致软件产品无法使用的风险都要重点关注。
运行时的软件系统为了配合业务运营需求，实际的需求和使用情况也是在动态变化的，对运行时状态的观察要考虑前瞻性，可能存在的风险有：
- 基础设施（包括VM、网络、存储、DB等）意外宕机
- 随业务增长导致的基础设施资源不足
- 数据泄露
- 集成系统异常
开发过程相关风险
没有规矩不成方圆，即使在自治的敏捷开发团队中，也有一些约定俗成的规定和流程，这是开发团队能够持续保持活力和战力的基础。作为Tech Lead，需要结合软件系统的特点，以及团队的特点，定制化调整团队的流程实践，避免缺少关键流程导致的风险。这些风险可能是：
- 进度风险
- 质量风险
团队相关风险
软件开发是一种创造性的工作，对人的依赖性很高，甚至在长期的项目上，因为项目的上下文不易快速获得，对一些关键角色的依赖性更强，这种现象无法避免。因此，在软件交付过程中，人员的更替和流动一定会给团队带来不同程度的风险：
- 人员能力不足带来的风险
- 人员流动带来的风险
4. 如何应对风险？
那么有什么手段可以帮助我们降低风险呢？ 上文中讲了风险的两个关键要素：不确定性，会产生不良影响。 因此，要降低风险，就要从这两个方面入手，要么想办法降低风险发生的概率，要么降低风险带来的影响：
上图中给出了降低发生概率和影响的几种手段：
- 避开风险（Avoid）：对于可能产生风险的活动，尽量不做，以最大可能降低风险发生的概率，避免风险发生
- 接纳风险（Contain）：通过计划额外的成本（时间或资源）应对可能产生的风险，在风险发生时及时降低风险产生的影响
- 缓和风险（Mitigate）：分析风险，并立刻采取干预手段，减小风险发生的概率和影响
上面几种手段看似直接简单，仔细想想，是需要非常多的经验积累的，作为Tech Lead要不断从过往的经历中总结每一次的事故，提炼经验。在日常交付过程中，对风险进行评估，排优先级，根据不同的风险采用不同的手段。
当然在一些特殊的情况下，我们还有另一个应对风险的选择：4. 忽视风险（Evade），如果风险发生，再想办法应对，如果风险不发生，那就赚到了，这只适用于那些即便发生，影响在可接受范围的场景。
5. 最后
虽然我们在谈Tech Lead的风险管理，但风险管理从来都不是Tech Lead一个人的事情，应该是全团队共同承担的责任，Tech Lead在整个软件开发过程中，也要调动全体团队成员在应对风险上的积极性，通过组织一些风险相关的头脑风暴，可视化技术债和风险，将风险管理作为全团队成员共同关注的话题。
