软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

15 | 风险管理:不能盲目乐观,凡事都应该有B计划

宝玉 2019-03-30
你好,我是宝玉,我今天想与你分享的主题是:风险管理,凡事都应该有 B 计划。
说到风险,很多人都模模糊糊有一些了解,然而在软件项目中,有风险意识的却不多。比如说:
估算一个模块工作量,程序员总是会给出一个乐观的进度,而最终实现这个模块的时候,却发现总是有些其他的事情发生影响了进度;
一个关键的程序员,突然离职了,导致项目进度停滞。其实早前就有一些迹象,而项目经理没引起重视;
技术负责人很激进的采用了一个最近很流行的新技术,结果做的过程中,发现这个技术还不太成熟,很多坑没法填,导致项目最终失败;
服务器突然挂了,才发现硬盘坏了而数据没有备份,造成巨大的损失。
这些问题其实都和风险相关,如果没有及时发现这些潜在的风险,没有应对方案,轻则导致项目进度延迟,重则导致项目失败,造成重大损失。
在软件工程里面,针对这些可能造成风险的问题,对风险进行提前识别和管理,就可以有效地应对。

什么是风险管理?

风险是指不确定的事件,一旦发生,将会造成消极的影响。风险包含两个方面的内容:
发生后,会造成什么样的损失?
发生的概率有多大?
所以也有人认为:风险 = 损失 x 发生概率。
比如说,有一次我负责一个小项目,激进的采用了刚开始流行的 React 框架,如果使用熟悉的 Angularjs 框架,正常来说一个月就能完成,当时很乐观的觉得 React 和 Angularjs 也差不多,时间应该不会多出来太多,就按照一个月时间来做项目计划。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • 邢爱明
    目前负责在公司推行敏捷开发,第一个试点推行,也可以认为是一个项目。
    个人识别出三个风险:
    1. 这个试点项目的项目经理担任PO角色,虽然已多次沟通,但对敏捷的认识比较浅,觉得自己不需要做什么改变,其他人的工作不影响项目交付就行了,参与度较低。
    2. 团队中开发的人员多为外包人员,对敏捷开发所需要的技能了解很少,单元测试和持续集成都没怎么做过,无法保证交付质量。
    3. 个人虽然参加过敏捷培训,但缺少实战经验,实施过程中需要踩的坑比较多,可能对会影响项目进度。

    风险分析和应对措施如下:
    1. 项目经理的参与度风险,可能性高,影响度高,应对措施是项目经理的上级沟通,争取对敏捷开发实施的支持,借助一定行政管理的手段,提升项目对敏捷开发实施的重视度和参与度。
    2. 开发人员的技能风险,可能性高,影响度低,主要考虑目前项目当前的开发任务比较简单。应对措施是对开发人员进行培训,在迭代开始前尽可能的掌握敏捷开发的技术。
    3. 因实施敏捷延缓项目进度的风险,可能性低,影响度高。主要考虑项目当前的开发计划不紧张,有适当的缓冲时间用来赶进度。应对措施是申请外部具有敏捷开发实践经验的人员参与,帮助项目团队在两到三个迭代周期内,走顺敏捷开发的流程。

    作者回复: 我觉得你提到的借人参与两到三个迭代的方案是非常简单有效的办法,一个敏捷团队,如果大家没这个意识和水平,是很难推动的,但是当有几个人一起,走顺了流程,后面相对就照葫芦画瓢容易多了。

    另外辅助培训也是很有必要的,有了一些基本的概念,再执行起来阻力会小很多。

    对于多年的项目经理转PO,是要一个过程的,毕竟已经喜欢了以前的一套东西,一时之间很难转变观念。沟通时,建议客观分析利弊,优缺点,尤其是将一些事情和他的利益挂钩,会更有参与度一些。比如说让他意识到:这个试点项目成功对他未来的绩效、职业前景都有好处。

    2019-03-30
    3
  • shine
    1.进度/人员风险:项目组开发人员2/3是实习生。技术不熟练,需求理解的偏差可能会导致提交的代码的质量技术债务高及提交时间点延迟,影响进度
    发生概率:80%
    解决办法 :1.技术上需要加强培训2.通过Code Review早期发现代码中的BUG

    2.进度风险:需求没有经过正式评审,文档都是复制粘贴修改写好的,开发、测试时可能会碰到需求矛盾、需求变更的情况,导致返工,影响进度
    发生概率:50%
    解决办法:1.对需求文档进行评审

    3.人员风险:项目没有后备人员,项目过程中有人长时间请假或是离职,影响进度
    发生概念:30%
    解决办法 :1.项目组需要培养后备员2.项目进度管理需要清晰明了

    以上是一个项目成员在项目之初所设想的风险,不知道列得对不对,请宝玉老师多多指教。
    实际上项目已经进行了2个月,以上的3个风险都已经发生(实际上项目管理人员并没有做风险管理),已经影响到进度。

    作者回复: 👍这些风险都很真实。

    给你一些应对方法上的建议供参考。

    1. 实习生比例高问题我以前遇到过,靠培养是很慢的,再聪明也需要两三年时间才能独当一面。建议要适当社招补充有经验的程序员,不然管理者和现有的资深程序员会很辛苦,要大量时间救火,短期看大量实习生省钱,长时间看其实成本更高的。

    2. 需求评审是很必要的,需要落实,而且要安排多次,刚开始有初步需求文档的时候就要做,这样修改成本低!另外建议产品设计要多用原型设计,原型设计是很好的避免需求模糊的方法,也可以帮助产品设计事先把很多问题想清楚。

    3. 还是在第一条里面提到的,不仅要培养人,更要招人开人。

    2019-03-30
    1
    3
  • fei
    经常被经理分配并行任务,譬如最近有两个测试任务和一个开发任务,这里会有一个风险点,如果一个任务错误估算工作量或者其它原因,出现延期,就会导致其它任务都延期,最后所有任务延期。
    如何解决呢?
    1、如果一个任务出现延期,重新估算任务优先级、如果可降级,则放下去做其它任务,如果不可降级,则其它任务重排优先级,保证最重要的任务按期完成
    2、分析复盘任务原因、自己时间估算有误、自己能力知识不足、阻塞性技术难度、或者环境人员问题、为以后积累经验

    但是宝玉老师最后有个问题、如何能跟经理讲明白为什么并行任务出现风险的概率比较大?因为我 boss觉得任务没那么复杂呀

    作者回复: 我觉得你对于任务的优先级、降级处理策略挺好的👍

    有时候位置不同,看问题的角度也不同。

    比如说经理分配并行任务,在他看来这并不是并行任务,而是两个或者多个任务同时分配给你,你要在指定时间内都完成。但并不是说你必须要同时做这几件任务,你可以串行也可以并行,他只关心你最终能按时完成所有的任务。

    从员工角度看,同时接到多个任务,会有压力,想同时做好几件事,但往往同时做效率低,不容易做好。这时候需要做的就是像你那样排好优先级、制定好计划。

    除此之外,还要设置里程碑或者关键检查点,这样当有可能的风险出现,能及时发现,并可以及时调整,毕竟对于Boss来说,风险没发生还是无法直观感受,但是里程碑没有达到目标就是很直观的信号,也更有说服力,这样就可以根据里程碑的情况及时沟通及时调整。

    2019-09-02
    2
  • Tiger
    老师,我们做的项目外包,项目组的人数是固定的,每次都是项目组要离职一个才会再招一个人进来补充,这种情况无法培养技术后备,这种人员风险怎么把控?

    作者回复: 这种确实有点困难,有两种策略你可以考虑:

    1. 减少对人的依赖,让人来了跟流水线工人一样可以马上上手。

    如果你的项目类型比较类似,其实可以考虑将相同部分通过架构简化,通过配置或者定制化适用于不同项目。

    补充自微博回复:
    @bobyuxinyang: 尽量开发流程标准化,然后文档,文档,文档。。。

    2. 培养现有的人,提升现有人能力,归属感,减少离职率。

    都不容易做到,但都可以试试,或者你也可以想到更好的办法。

    2019-04-14
    1
    2
  • 一路向北
    老师说的风险几乎都遇到过。但是实际每次定计划的时候几乎没有一次定过B计划,后面实施方案的时候,确实需要多思考一个B计划。
    不过,想来之前的一些拖延比较长时间的项目,对项目的一些变化的估计是有的,只是在计划制定的时候,总是会对一些可能会遇到的困难说克服一下,加加班就过去了之类的话,其实是对计划不确定性的一种逃避。

    作者回复: 👍
    很多时候没有做Plan B,只是没意识到风险的存在!等你意识到风险的存在,以后就会条件反射的要考虑Plan B。

    在实践中自然会摸索出很多适合你自己的应对风险的方案。

    2019-04-01
    2
  • alva_xu
    项目的不同时间节点,项目风险及其处理手段也是不一样的。所以,在讲风险管理的时候,还要加一个时间维度。老师能不能就这个维度来谈谈风险及管控处理方法?

    作者回复: 其实要考虑时间维度,你只要把时间范围成本三要素的约束加上就好了。

    因为时间变了,这三要素的约束也在变。

    给你举个例子:一个创业公司,人少缺钱,这时候人就是个很大的风险,有人离职项目就很危险,这其实本质就是三要素的成本;等到熬过这阶段,进入发展阶段,活下来有钱了,人也多了,相对来说,成本就不是最大的约束了,人的风险就没那么大了,这时候就是求快,时间会变成约束,所以如果你的技术和架构更不上开发的效率,就会成为新的风险。

    2019-04-01
    2
  • dancer
    在做需求分析、软件设计时,就要识别出可能潜在的风险点,并且对风险也做相应的设计,以及监控报警。要把风险也当作项目的一个组成部分。

    作者回复: 是的,包括做技术选型的时候,也一样要考虑风险。

    2019-03-31
    2
  • kirogiyi
    非常感谢宝玉老师每一次地回复和解答,使我能有更多感悟和进步。

    风险管理是否到位,取决于管理者对整个项目完整度的认识程度,认识越深刻,考虑越全面,就越容易去发现并预防潜在风险的发生。

    宝玉老师提到CSDN总裁讲的那几句话,我就在思考这种问题出现的原因和解决的办法。最近的一个项目中,发布的第一个软件版本中应总经理的要求,添加了各种各样的功能,使用了新的技术平台和管理方法。

    就功能来讲,个人觉得挑核心、小步走、快迭代是目前项目比较适合的方法。但在实施开发的过程中,因为要添加各种各样的功能,给人的感觉是每个功能都要有,但为数不少的功能不是必须有的,导致了项目部成员不能集中思路去处理核心问题,每个问题都要去抽丝剥茧,很耗费时间,版本发布日期一再延期。这样需求过多或不明确造成的风险就显现无疑。

    就新技术平台来讲,公司在最初选型的时候选用了目前流行的微服务构建方式,例如:在考虑微服务业务划分的时候设备状态、设备使用状态、产品使用状态等等很小的功能点都各自划分为一个微服务,这样造成了在开发一个可用功能的时候需要等到很多微服务开发部署完成后才能进行下一个功能模块的开发,极其痛苦。我想这应该不是新技术平台的问题,而是使用方式出现了问题。这样业务微服务的划分不合理造成的风险也就暴露无遗。

    虽然项目还在持续推进,也慢慢开始落地,但心目中觉得这个项目的很多东西可以通过提前去做清晰的了解和调查,把一些潜在的问题进行记录和规避,那么项目可以在更短时间内完成。这让我意识到一个缺乏风险管理的项目,在没有很大人力物力损失的情况下完成实属侥幸。

    作者回复: 关于需求优先级的问题,这个我建议你试试敏捷开发,或者采用迭代开发,因为每个Sprint时间固定,所以逼着你每次Sprint计划时选择优先级最高的需求,这样其他无关紧要的需求可以无限后延。

    技术选型是个很重要的事,后面还会再讲讲,希望下次选型时能跟慎重的分析论证。

    做项目,想不犯错误也是不现实的,最重要是每一次比上一次做的更好,上一次犯的错误争取不要再犯,这样自然能一次比一次做的更好。

    2019-03-30
    2
  • 小老鼠
    1、软件测试中有一种基于风险的测试,根据风险优先级计划测试步骤,这个非常好。
    2、软件工程与软件项目管理区别与联系,可否说一下?
    3、风险级别=风险发生可能性*风险一旦发现造成的损失。
    在本文中为什么风险一旦发现造成的损失高,风险发生可能性低比风险发生可能性高但风险一旦发现造成的损失低处理级别要高,二者应该是等效的。
    ————————————————————
    原文:对于概率不高但后果严重的问题也要考虑,不过优先级略低;对于概率高但后果不严重的风险事件,可以优先级很低或者不考虑;

    作者回复: 软件工程是围绕软件项目开发过程的,对整个开发过程的组织,对方法的运用,对工具的使用。

    软件项目管理的管理对象是软件工程项目,通过管理手段使软件项目能够按照预定的成本、进度、质量顺利完成。

    软件工程为你提供的科学的软件开发方法,而软件项目管理是一种实践,通过管人管事将这些方法落到实处,将工具真正应用推行起来。

    就好比@老赵 软件工程学的好,知道单元测试在软件工程中的重要性,但是他不做项目管理,所以无法有效在项目组内推行单元测试。如果他同时也做项目管理,那么就会将单元测试作为一种实践在项目内部推行。

    软件工程学的好不好,就在于你是不是能明白软件工程的众多理论知识,知道什么是最佳实践,什么情况下用什么开发模式是最好的;项目管理做的好不好,唯一的检验标准就是结果,项目经理的权威就在于你做成了多少项目!

    软件工程就是”知“,项目管理就是“行”,做到“知行合一”才能做好软件项目。

    对于后果不严重的,即使发生无严重后果,所以可以不予考虑。比如说你交给一个新手做一个UI界面,可能会导致界面不美观,但是不美观用户可以接受,那么并不是什么大问题。

    2019-09-12
    1
  • 小先生
    今日得到。
    平常项目进展中,具备风险意识。
    通过风险识别,风险量化,风险应对,风险监控来进行风险管理。
    2019-03-31
    1
  • Charles
    1. pc用户管理中心后台采用ant design中后台框架,当时可能考虑体验相对较好自己设计不一定能做好,而且前后端分离可以分担后端人少的压力可以类似移动端的开发方式,复用大部分API,但是这里感觉有一个风险就是客户那边浏览器环境没有做足够的调研,可能需要用户升级浏览器,本身也是一个很大的体验影响

    2. web服务器没有做负载均衡一直单节点跑着,市场数据一直在增加感觉有必要做一个了,哪怕是性能做个冗余也行

    3. mysql只有备份没有异地灾备,如果出现类似腾讯云上次那件事情虽然概率很低,一旦发生全盘皆输

    但是话说回来感觉对风险管理成本好大,一点一点做,排个优先级先,谢谢老师分享,让我重新思考了目前的风险,应该有很多

    作者回复: 赞,有风险意识是很重要的一步👍
    后面就可以针对性去识别和预防

    2019-03-30
    1
  • 谭鹏
    在项目中使用了React native ,那是React native还不太成熟,那但是项目不紧急也不算太大 ,出了问题 改成原生开发 也不会浪费太长时间.继续使用React native 能丰富团队的技术栈 ,所以接受风险

    作者回复: 说到这个问题,回头技术选型那篇还要再讲讲。

    2019-03-30
    1
  • calvins
    看了好多留言,都是讲风险怎么处理,有这样一个问题,项目成员有风险意识,提出来了,负责的人他不在意,或者老板不在意,原因是风险管理是要成本的,往往项目很急或者金额不是很大的时候,风险管理就有很大的阻碍,这种情况怎么处理?

    作者回复: 这个问题已经超出软件工程范畴了,毕竟软件工程只能教你怎么去识别风险应对风险。

    我个人建议:
    如果你只是普通项目成员,那么你可以应用这些知识,识别可能风险,向负责人提出可能风险和应对建议。至于最后结果,可能不是你能控制的。另外有时候由于信息不对称,作为普通项目成员了解的信息有限,看到的结果不一定是准确的。

    如果你是项目负责人,则应该重视风险管理,不只是发现,还应该做出具体的应对措施。

    2019-11-20
    1
  • javaadu
    风险管理包括两个方面:降低风险发生德概率;降低风险发生后的损失
    2019-04-07
  • 小先生
    应对风险的四种办法。
    回避风险,转移风险,接受风险,缓解风险。
    根据不同情况进行应对。
    2019-03-31
收起评论
15
返回
顶部