本节书摘来自异步社区《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》一书中的第2章，第02-10节，作者 邱毅凌,更多章节内容可以访问云栖社区“异步社区”公众号查看。
###02-10项目风险（Risk）管理
一般项目时常会无视风险管理，但以嵌入式系统开发项目来看，重要工程人员离职、存储器size过小、预算超支、规格变更、零件涨价或缺料等状况都可能发生。如果项目计划中完全没有考虑到防治风险发生的可能性，当执行时期‘恶梦成真’时，难免令人措手不及。
风险管理的思想是：并非每个可能的风险都需要处理（毕竟风险不一定真的会发生），但一定要在项目初期就将其辨识出来，并评估其发生的几率，以及可能产生的影响力。
举例来说，某个产品开发项目会采用Embedded Linux作为系统核心，但项目成员里只有一位工程师熟悉此领域，且最近有倦勤的倾向。当项目经理识别出这个风险后，他判断该工程师离职的几率很高，若一旦离职，对项目将是严重的打击。于是他决定先试着沟通，再度确认该工程师执行完此项目的几率，同时，他也延请另一位工程师进入项目团队，从项目一开始就熟悉Embedded Linux。
再举另一个例子。NAND Flash的价格变动很大，而且随时都有可能缺货，当项目团队识别到这个风险，就应该直接建议生管单位提前备料。
从这些例子看来，大部分的风险处理其实并不困难，而且可以在项目初期就排除或减缓。但如果未将风险识别出来，想要事后处理将难如登天，使得这些风险宛如项目中的不定时炸弹，让项目经理不得安眠。
PMP提供了许多风险定性与定量分析的实用工具，首要任务就是找出项目运行时可能发生的风险。风险识别需要具备一定经验的人来执行，通常就是根据项目目标与WBS，把项目在脑袋里‘跑’一遍，然后列出可能发生的意外事件，或是请所有项目成员，在轻松的气氛下举行‘头脑风暴法’，并记录下所有与会者对本项目风险的想法。
风险是未来才会发生的事，所以没有人可以列出完全正确无误的风险列表，但无论如何，有做风险识别绝对比没做的好，至少我们已经预先排除了项目的某些不确定性。
有了风险列表后，我们要为每个风险打两项分数—发生几率及严重性。同样的，这在项目初期是估不准的，但至少可以比较出高低，例如：客户临时修改规格的严重性比某零件缺料的严重性要高，而工厂发生火灾的机率比某重要工程师离职的机率要低。风险列表里的每项Item都会有两个分数，将其相乘并排序，名列前茅的项目就是我们非得do something的风险。
项目因为有着独特性与前期不确定性，因此，项目执行本身就是一件高风险的活动。项目管理不可能消除所有的风险，但通过一定的风险规划，并采取必要的风险控制策略，通常可以消除或减少某些风险的影响程度。
当‘风险排行榜’完成后，我们就该针对这些风险，拟定项目风险应对计划，以确定某个风险该不该处理？何时处理？怎样的处理方式？以下有4项规划降低风险的主要策略。
- 回避风险：主动放弃或拒绝使用导致风险的方案，试着寻找替代方案。
- 转移风险：将风险转移给外包公司。
- 损失控制：减缓风险发生时的危害程度。
- 承担风险：对影响力小或发生机率低的风险，可选择先不予理会。
再次强调，风险识别往往只能借助资深员工与顾问的宝贵经验，或许并非科学，但绝不能因此就不做风险分析。项目中可能发生各种意外事件，事先不可能全部料到，但能事先料想到的风险，却又不加处理，都只是平白错失提高项目成功的机会罢了！
幻灯片列出了嵌入式系统可能发生的风险种类，以下再补充一些软件开发项目常见的风险与预防措施。
- 合约风险：主要就是合约条款有漏洞，项目经理必须会同法务人员详细检验查看合约内容。
- 需求变更风险：提前以书面方式，和客户约定好变更处理流程。
- 沟通不良风险：不可忽略‘项目沟通计划’的制定与公布。
- 缺乏高层支持风险：只能不断的沟通再沟通，或对高层诱之以利，说明此项目可以为公司带来的利益。
- 进度风险：有些项目的进度要求相当‘苛刻’，项目delay可能意味着市场机会变小。假使Schedule无法调整，只能尽量多取得资源与预算，此时，分阶段交付项目成果也是方法之一。
- 质量风险：谨慎制定项目质量策略，成立质量小组等。
- 系统性能风险：增加执行设计阶段的力度、制作原型（Prototype）等。
- 技术风险：可考虑外包，或变更执行人员等。
- 团队成员能力风险：提早开始教育培训或变更团队成员。
- 团队合作风险：目标要明确，绩效制度要公开、公正、公平。
- 人员流动风险：尽可能将核心工作分派给多个人执行。
- 协助厂商风险：合作前即制定审核稽核（Audit）与验收流程。
