《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》——02-10 项目风险(Risk)管理

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

本节书摘来自异步社区《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》一书中的第2章,第02-10节,作者 邱毅凌,更多章节内容可以访问云栖社区“异步社区”公众号查看。

###02-10项目风险(Risk)管理

screenshot

一般项目时常会无视风险管理,但以嵌入式系统开发项目来看,重要工程人员离职、存储器size过小、预算超支、规格变更、零件涨价或缺料等状况都可能发生。如果项目计划中完全没有考虑到防治风险发生的可能性,当执行时期‘恶梦成真’时,难免令人措手不及。

风险管理的思想是:并非每个可能的风险都需要处理(毕竟风险不一定真的会发生),但一定要在项目初期就将其辨识出来,并评估其发生的几率,以及可能产生的影响力。

举例来说,某个产品开发项目会采用Embedded Linux作为系统核心,但项目成员里只有一位工程师熟悉此领域,且最近有倦勤的倾向。当项目经理识别出这个风险后,他判断该工程师离职的几率很高,若一旦离职,对项目将是严重的打击。于是他决定先试着沟通,再度确认该工程师执行完此项目的几率,同时,他也延请另一位工程师进入项目团队,从项目一开始就熟悉Embedded Linux。

再举另一个例子。NAND Flash的价格变动很大,而且随时都有可能缺货,当项目团队识别到这个风险,就应该直接建议生管单位提前备料。

从这些例子看来,大部分的风险处理其实并不困难,而且可以在项目初期就排除或减缓。但如果未将风险识别出来,想要事后处理将难如登天,使得这些风险宛如项目中的不定时炸弹,让项目经理不得安眠。

screenshot

PMP提供了许多风险定性与定量分析的实用工具,首要任务就是找出项目运行时可能发生的风险。风险识别需要具备一定经验的人来执行,通常就是根据项目目标与WBS,把项目在脑袋里‘跑’一遍,然后列出可能发生的意外事件,或是请所有项目成员,在轻松的气氛下举行‘头脑风暴法’,并记录下所有与会者对本项目风险的想法。

风险是未来才会发生的事,所以没有人可以列出完全正确无误的风险列表,但无论如何,有做风险识别绝对比没做的好,至少我们已经预先排除了项目的某些不确定性。

有了风险列表后,我们要为每个风险打两项分数—发生几率及严重性。同样的,这在项目初期是估不准的,但至少可以比较出高低,例如:客户临时修改规格的严重性比某零件缺料的严重性要高,而工厂发生火灾的机率比某重要工程师离职的机率要低。风险列表里的每项Item都会有两个分数,将其相乘并排序,名列前茅的项目就是我们非得do something的风险。

screenshot
screenshot

项目因为有着独特性与前期不确定性,因此,项目执行本身就是一件高风险的活动。项目管理不可能消除所有的风险,但通过一定的风险规划,并采取必要的风险控制策略,通常可以消除或减少某些风险的影响程度。

当‘风险排行榜’完成后,我们就该针对这些风险,拟定项目风险应对计划,以确定某个风险该不该处理?何时处理?怎样的处理方式?以下有4项规划降低风险的主要策略。

  • 回避风险:主动放弃或拒绝使用导致风险的方案,试着寻找替代方案。
  • 转移风险:将风险转移给外包公司。
  • 损失控制:减缓风险发生时的危害程度。
  • 承担风险:对影响力小或发生机率低的风险,可选择先不予理会。

再次强调,风险识别往往只能借助资深员工与顾问的宝贵经验,或许并非科学,但绝不能因此就不做风险分析。项目中可能发生各种意外事件,事先不可能全部料到,但能事先料想到的风险,却又不加处理,都只是平白错失提高项目成功的机会罢了!

screenshot

幻灯片列出了嵌入式系统可能发生的风险种类,以下再补充一些软件开发项目常见的风险与预防措施。

  • 合约风险:主要就是合约条款有漏洞,项目经理必须会同法务人员详细检验查看合约内容。
  • 需求变更风险:提前以书面方式,和客户约定好变更处理流程。
  • 沟通不良风险:不可忽略‘项目沟通计划’的制定与公布。
  • 缺乏高层支持风险:只能不断的沟通再沟通,或对高层诱之以利,说明此项目可以为公司带来的利益。
  • 进度风险:有些项目的进度要求相当‘苛刻’,项目delay可能意味着市场机会变小。假使Schedule无法调整,只能尽量多取得资源与预算,此时,分阶段交付项目成果也是方法之一。
  • 质量风险:谨慎制定项目质量策略,成立质量小组等。
  • 系统性能风险:增加执行设计阶段的力度、制作原型(Prototype)等。
  • 技术风险:可考虑外包,或变更执行人员等。
  • 团队成员能力风险:提早开始教育培训或变更团队成员。
  • 团队合作风险:目标要明确,绩效制度要公开、公正、公平。
  • 人员流动风险:尽可能将核心工作分派给多个人执行。
  • 协助厂商风险:合作前即制定审核稽核(Audit)与验收流程。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
0
0
0
1816
分享
相关文章
Django 后端架构开发:高效日志规范与实践
Django 后端架构开发:高效日志规范与实践
162 1
鸿蒙开发:console日志输出
针对初学者而言,大家只需要掌握住日志打印即可,等到了鸿蒙应用开发的时候,还有一个鸿蒙原生的打印工具HiLog,到时,我们也会详细的去讲述,也会针对HiLog,封装一个通用的工具类。
22 11
鸿蒙开发:console日志输出
Tauri 开发实践 — Tauri 日志记录功能开发
本文介绍了如何为 Tauri 应用配置日志记录。Tauri 是一个利用 Web 技术构建桌面应用的框架。文章详细说明了如何在 Rust 和 JavaScript 代码中设置和集成日志记录,并控制日志输出。通过添加 `log` crate 和 Tauri 日志插件,可以轻松实现多平台日志记录,包括控制台输出、Webview 控制台和日志文件。文章还展示了如何调整日志级别以优化输出内容。配置完成后,日志记录功能将显著提升开发体验和程序稳定性。
230 1
Tauri 开发实践 — Tauri 日志记录功能开发
3D-Speaker:阿里通义开源的多模态说话人识别项目,支持说话人识别、语种识别、多模态识别、说话人重叠检测和日志记录
3D-Speaker是阿里巴巴通义实验室推出的多模态说话人识别开源项目,结合声学、语义和视觉信息,提供高精度的说话人识别和语种识别功能。项目包含工业级模型、训练和推理代码,以及大规模多设备、多距离、多方言的数据集,适用于多种应用场景。
591 18
3D-Speaker:阿里通义开源的多模态说话人识别项目,支持说话人识别、语种识别、多模态识别、说话人重叠检测和日志记录
|
3月前
|
java项目中jar启动执行日志报错:no main manifest attribute, in /www/wwwroot/snow-server/z-server.jar-jar打包的大小明显小于正常大小如何解决
在Java项目中,启动jar包时遇到“no main manifest attribute”错误,且打包大小明显偏小。常见原因包括:1) Maven配置中跳过主程序打包;2) 缺少Manifest文件或Main-Class属性。解决方案如下:
1019 8
java项目中jar启动执行日志报错:no main manifest attribute, in /www/wwwroot/snow-server/z-server.jar-jar打包的大小明显小于正常大小如何解决
【MySQL】根据binlog日志获取回滚sql的一个开发思路
【MySQL】根据binlog日志获取回滚sql的一个开发思路
鸿蒙5.0版开发:使用HiLog打印日志(ArkTS)
在HarmonyOS 5.0中,HiLog是系统提供的日志系统,支持DEBUG、INFO、WARN、ERROR、FATAL五种日志级别。本文介绍如何在ArkTS中使用HiLog打印日志,并提供示例代码。通过合理使用HiLog,开发者可以更好地调试和监控应用。
369 16
SpringBoot项目使用AOP及自定义注解保存操作日志
SpringBoot项目使用AOP及自定义注解保存操作日志
88 1
git显示开发日志+WinSW——将.exe文件注册为服务的一个工具+图床PicGo+kubeconfig 多个集群配置 如何切换
git显示开发日志+WinSW——将.exe文件注册为服务的一个工具+图床PicGo+kubeconfig 多个集群配置 如何切换
71 1