- 2019-03-301.进度/人员风险：项目组开发人员2/3是实习生。技术不熟练，需求理解的偏差可能会导致提交的代码的质量技术债务高及提交时间点延迟，影响进度
发生概率：80%
解决办法 :1.技术上需要加强培训2.通过Code Review早期发现代码中的BUG
2.进度风险：需求没有经过正式评审，文档都是复制粘贴修改写好的，开发、测试时可能会碰到需求矛盾、需求变更的情况，导致返工，影响进度
发生概率：50%
解决办法：1.对需求文档进行评审
3.人员风险：项目没有后备人员，项目过程中有人长时间请假或是离职，影响进度
发生概念：30%
解决办法 ：1.项目组需要培养后备员2.项目进度管理需要清晰明了
以上是一个项目成员在项目之初所设想的风险，不知道列得对不对，请宝玉老师多多指教。
实际上项目已经进行了2个月，以上的3个风险都已经发生(实际上项目管理人员并没有做风险管理)，已经影响到进度。展开作者回复: 👍这些风险都很真实。
给你一些应对方法上的建议供参考。
1. 实习生比例高问题我以前遇到过，靠培养是很慢的，再聪明也需要两三年时间才能独当一面。建议要适当社招补充有经验的程序员，不然管理者和现有的资深程序员会很辛苦，要大量时间救火，短期看大量实习生省钱，长时间看其实成本更高的。
2. 需求评审是很必要的，需要落实，而且要安排多次，刚开始有初步需求文档的时候就要做，这样修改成本低！另外建议产品设计要多用原型设计，原型设计是很好的避免需求模糊的方法，也可以帮助产品设计事先把很多问题想清楚。
3. 还是在第一条里面提到的，不仅要培养人，更要招人开人。 1 4 
2019-03-30目前负责在公司推行敏捷开发，第一个试点推行，也可以认为是一个项目。
个人识别出三个风险:
1. 这个试点项目的项目经理担任PO角色，虽然已多次沟通，但对敏捷的认识比较浅，觉得自己不需要做什么改变，其他人的工作不影响项目交付就行了，参与度较低。
2. 团队中开发的人员多为外包人员，对敏捷开发所需要的技能了解很少，单元测试和持续集成都没怎么做过，无法保证交付质量。
3. 个人虽然参加过敏捷培训，但缺少实战经验，实施过程中需要踩的坑比较多，可能对会影响项目进度。
风险分析和应对措施如下:
1. 项目经理的参与度风险，可能性高，影响度高，应对措施是项目经理的上级沟通，争取对敏捷开发实施的支持，借助一定行政管理的手段，提升项目对敏捷开发实施的重视度和参与度。
2. 开发人员的技能风险，可能性高，影响度低，主要考虑目前项目当前的开发任务比较简单。应对措施是对开发人员进行培训，在迭代开始前尽可能的掌握敏捷开发的技术。
3. 因实施敏捷延缓项目进度的风险，可能性低，影响度高。主要考虑项目当前的开发计划不紧张，有适当的缓冲时间用来赶进度。应对措施是申请外部具有敏捷开发实践经验的人员参与，帮助项目团队在两到三个迭代周期内，走顺敏捷开发的流程。展开作者回复: 我觉得你提到的借人参与两到三个迭代的方案是非常简单有效的办法，一个敏捷团队，如果大家没这个意识和水平，是很难推动的，但是当有几个人一起，走顺了流程，后面相对就照葫芦画瓢容易多了。
另外辅助培训也是很有必要的，有了一些基本的概念，再执行起来阻力会小很多。
对于多年的项目经理转PO，是要一个过程的，毕竟已经喜欢了以前的一套东西，一时之间很难转变观念。沟通时，建议客观分析利弊，优缺点，尤其是将一些事情和他的利益挂钩，会更有参与度一些。比如说让他意识到：这个试点项目成功对他未来的绩效、职业前景都有好处。 1 3
2019-09-02经常被经理分配并行任务，譬如最近有两个测试任务和一个开发任务，这里会有一个风险点，如果一个任务错误估算工作量或者其它原因，出现延期，就会导致其它任务都延期，最后所有任务延期。
如何解决呢？
1、如果一个任务出现延期，重新估算任务优先级、如果可降级，则放下去做其它任务，如果不可降级，则其它任务重排优先级，保证最重要的任务按期完成
2、分析复盘任务原因、自己时间估算有误、自己能力知识不足、阻塞性技术难度、或者环境人员问题、为以后积累经验
但是宝玉老师最后有个问题、如何能跟经理讲明白为什么并行任务出现风险的概率比较大？因为我 boss觉得任务没那么复杂呀展开作者回复: 我觉得你对于任务的优先级、降级处理策略挺好的👍
有时候位置不同，看问题的角度也不同。
比如说经理分配并行任务，在他看来这并不是并行任务，而是两个或者多个任务同时分配给你，你要在指定时间内都完成。但并不是说你必须要同时做这几件任务，你可以串行也可以并行，他只关心你最终能按时完成所有的任务。
从员工角度看，同时接到多个任务，会有压力，想同时做好几件事，但往往同时做效率低，不容易做好。这时候需要做的就是像你那样排好优先级、制定好计划。
除此之外，还要设置里程碑或者关键检查点，这样当有可能的风险出现，能及时发现，并可以及时调整，毕竟对于Boss来说，风险没发生还是无法直观感受，但是里程碑没有达到目标就是很直观的信号，也更有说服力，这样就可以根据里程碑的情况及时沟通及时调整。 2
2019-04-14老师，我们做的项目外包，项目组的人数是固定的，每次都是项目组要离职一个才会再招一个人进来补充，这种情况无法培养技术后备，这种人员风险怎么把控？作者回复: 这种确实有点困难，有两种策略你可以考虑：
1. 减少对人的依赖，让人来了跟流水线工人一样可以马上上手。
如果你的项目类型比较类似，其实可以考虑将相同部分通过架构简化，通过配置或者定制化适用于不同项目。
补充自微博回复：
@bobyuxinyang: 尽量开发流程标准化，然后文档，文档，文档。。。
2. 培养现有的人，提升现有人能力，归属感，减少离职率。
都不容易做到，但都可以试试，或者你也可以想到更好的办法。 1 2
2019-04-01老师说的风险几乎都遇到过。但是实际每次定计划的时候几乎没有一次定过B计划，后面实施方案的时候，确实需要多思考一个B计划。
不过，想来之前的一些拖延比较长时间的项目，对项目的一些变化的估计是有的，只是在计划制定的时候，总是会对一些可能会遇到的困难说克服一下，加加班就过去了之类的话，其实是对计划不确定性的一种逃避。作者回复: 👍
很多时候没有做Plan B，只是没意识到风险的存在！等你意识到风险的存在，以后就会条件反射的要考虑Plan B。
在实践中自然会摸索出很多适合你自己的应对风险的方案。 2- 2019-04-01项目的不同时间节点，项目风险及其处理手段也是不一样的。所以，在讲风险管理的时候，还要加一个时间维度。老师能不能就这个维度来谈谈风险及管控处理方法？
作者回复: 其实要考虑时间维度，你只要把时间范围成本三要素的约束加上就好了。
因为时间变了，这三要素的约束也在变。
给你举个例子：一个创业公司，人少缺钱，这时候人就是个很大的风险，有人离职项目就很危险，这其实本质就是三要素的成本；等到熬过这阶段，进入发展阶段，活下来有钱了，人也多了，相对来说，成本就不是最大的约束了，人的风险就没那么大了，这时候就是求快，时间会变成约束，所以如果你的技术和架构更不上开发的效率，就会成为新的风险。 2 
2019-03-31在做需求分析、软件设计时，就要识别出可能潜在的风险点，并且对风险也做相应的设计，以及监控报警。要把风险也当作项目的一个组成部分。作者回复: 是的，包括做技术选型的时候，也一样要考虑风险。
2
2019-03-30非常感谢宝玉老师每一次地回复和解答，使我能有更多感悟和进步。
风险管理是否到位，取决于管理者对整个项目完整度的认识程度，认识越深刻，考虑越全面，就越容易去发现并预防潜在风险的发生。
宝玉老师提到CSDN总裁讲的那几句话，我就在思考这种问题出现的原因和解决的办法。最近的一个项目中，发布的第一个软件版本中应总经理的要求，添加了各种各样的功能，使用了新的技术平台和管理方法。
就功能来讲，个人觉得挑核心、小步走、快迭代是目前项目比较适合的方法。但在实施开发的过程中，因为要添加各种各样的功能，给人的感觉是每个功能都要有，但为数不少的功能不是必须有的，导致了项目部成员不能集中思路去处理核心问题，每个问题都要去抽丝剥茧，很耗费时间，版本发布日期一再延期。这样需求过多或不明确造成的风险就显现无疑。
就新技术平台来讲，公司在最初选型的时候选用了目前流行的微服务构建方式，例如：在考虑微服务业务划分的时候设备状态、设备使用状态、产品使用状态等等很小的功能点都各自划分为一个微服务，这样造成了在开发一个可用功能的时候需要等到很多微服务开发部署完成后才能进行下一个功能模块的开发，极其痛苦。我想这应该不是新技术平台的问题，而是使用方式出现了问题。这样业务微服务的划分不合理造成的风险也就暴露无遗。
虽然项目还在持续推进，也慢慢开始落地，但心目中觉得这个项目的很多东西可以通过提前去做清晰的了解和调查，把一些潜在的问题进行记录和规避，那么项目可以在更短时间内完成。这让我意识到一个缺乏风险管理的项目，在没有很大人力物力损失的情况下完成实属侥幸。展开作者回复: 关于需求优先级的问题，这个我建议你试试敏捷开发，或者采用迭代开发，因为每个Sprint时间固定，所以逼着你每次Sprint计划时选择优先级最高的需求，这样其他无关紧要的需求可以无限后延。
技术选型是个很重要的事，后面还会再讲讲，希望下次选型时能跟慎重的分析论证。
做项目，想不犯错误也是不现实的，最重要是每一次比上一次做的更好，上一次犯的错误争取不要再犯，这样自然能一次比一次做的更好。 2
2019-09-121、软件测试中有一种基于风险的测试，根据风险优先级计划测试步骤，这个非常好。
2、软件工程与软件项目管理区别与联系，可否说一下？
3、风险级别=风险发生可能性*风险一旦发现造成的损失。
在本文中为什么风险一旦发现造成的损失高，风险发生可能性低比风险发生可能性高但风险一旦发现造成的损失低处理级别要高，二者应该是等效的。
————————————————————
原文：对于概率不高但后果严重的问题也要考虑，不过优先级略低；对于概率高但后果不严重的风险事件，可以优先级很低或者不考虑；展开作者回复: 软件工程是围绕软件项目开发过程的，对整个开发过程的组织，对方法的运用，对工具的使用。
软件项目管理的管理对象是软件工程项目，通过管理手段使软件项目能够按照预定的成本、进度、质量顺利完成。
软件工程为你提供的科学的软件开发方法，而软件项目管理是一种实践，通过管人管事将这些方法落到实处，将工具真正应用推行起来。
就好比@老赵 软件工程学的好，知道单元测试在软件工程中的重要性，但是他不做项目管理，所以无法有效在项目组内推行单元测试。如果他同时也做项目管理，那么就会将单元测试作为一种实践在项目内部推行。
软件工程学的好不好，就在于你是不是能明白软件工程的众多理论知识，知道什么是最佳实践，什么情况下用什么开发模式是最好的；项目管理做的好不好，唯一的检验标准就是结果，项目经理的权威就在于你做成了多少项目！
软件工程就是”知“，项目管理就是“行”，做到“知行合一”才能做好软件项目。
对于后果不严重的，即使发生无严重后果，所以可以不予考虑。比如说你交给一个新手做一个UI界面，可能会导致界面不美观，但是不美观用户可以接受，那么并不是什么大问题。 1
2019-03-31今日得到。
平常项目进展中，具备风险意识。
通过风险识别，风险量化，风险应对，风险监控来进行风险管理。 1
2019-03-301. pc用户管理中心后台采用ant design中后台框架，当时可能考虑体验相对较好自己设计不一定能做好，而且前后端分离可以分担后端人少的压力可以类似移动端的开发方式，复用大部分API，但是这里感觉有一个风险就是客户那边浏览器环境没有做足够的调研，可能需要用户升级浏览器，本身也是一个很大的体验影响
2. web服务器没有做负载均衡一直单节点跑着，市场数据一直在增加感觉有必要做一个了，哪怕是性能做个冗余也行
3. mysql只有备份没有异地灾备，如果出现类似腾讯云上次那件事情虽然概率很低，一旦发生全盘皆输
但是话说回来感觉对风险管理成本好大，一点一点做，排个优先级先，谢谢老师分享，让我重新思考了目前的风险，应该有很多展开作者回复: 赞，有风险意识是很重要的一步👍
后面就可以针对性去识别和预防 1
2019-03-30在项目中使用了React native ，那是React native还不太成熟,那但是项目不紧急也不算太大 ,出了问题 改成原生开发 也不会浪费太长时间.继续使用React native 能丰富团队的技术栈 ，所以接受风险作者回复: 说到这个问题，回头技术选型那篇还要再讲讲。
1
2019-12-19建议内容加点知识密度，看似娓娓道来，但很有可能正确的废话偏多。
风险评估
推荐讲讲代价函数
库尔贝勒交叉熵（K-L divergence也叫KL散度）。从这个名称可以看出，它和熵有关。库尔贝勒交叉熵讨论的是在信息误判时的损失- 2019-11-20看了好多留言，都是讲风险怎么处理，有这样一个问题，项目成员有风险意识，提出来了，负责的人他不在意，或者老板不在意，原因是风险管理是要成本的，往往项目很急或者金额不是很大的时候，风险管理就有很大的阻碍，这种情况怎么处理？
作者回复: 这个问题已经超出软件工程范畴了，毕竟软件工程只能教你怎么去识别风险应对风险。
我个人建议：
如果你只是普通项目成员，那么你可以应用这些知识，识别可能风险，向负责人提出可能风险和应对建议。至于最后结果，可能不是你能控制的。另外有时候由于信息不对称，作为普通项目成员了解的信息有限，看到的结果不一定是准确的。
如果你是项目负责人，则应该重视风险管理，不只是发现，还应该做出具体的应对措施。 1 
2019-04-07风险管理包括两个方面：降低风险发生德概率；降低风险发生后的损失- 2019-03-31应对风险的四种办法。
回避风险，转移风险，接受风险，缓解风险。
根据不同情况进行应对。