🍊
翻译橙
🍊返回主站🤖参与贡献
  • hello,这里是翻译橙
  • spring boot参考文档
    • 1. 法律
    • 2. 寻求帮助
    • 3. 文档概述
    • 4. 入门
    • 5. 升级Spring Boot
    • 6. 使用 Spring Boot 进行开发
      • 6.1. 构建系统
      • 6.2. 构建你的代码
      • 6.3. 配置类
      • 6.4. 自动配置
      • 6.5. Spring Bean 和依赖注入
      • 6.6. 使用@SpringBootApplication注解
      • 6.7. 运行您的应用程序
      • 6.8. 开发者工具
      • 6.9. 打包您的生产应用程序
      • 6.10. 接下来读什么
    • 7.核心特性
      • 7.1. SpringApplication
      • 7.2. 外部化配置
      • 7.3.Profile配置
      • 7.4.日志记录
      • 7.5.国际化
      • 7.6 面向切面的编程
      • 7.7. JSON
      • 7.8. 任务执行与调度
      • 7.9. 单元测试
        • 7.9.1. 测试范围依赖
        • 7.9.2. 测试 Spring 应用程序
        • 7.9.3. 测试 Spring Boot 应用程序
        • 7.9.4. 测试容器
        • 7.9.5. 测试工具
      • 7.10. Docker Compose 支持
      • 7.11. 测试容器支持
      • 7.12. 创建您自己的自动配置
      • 7.13. Kotlin 支持
      • 7.14 SSL
      • 7.15.接下来要读什么
    • 8. 网络
      • 8.1. Servlet Web 应用程序
        • 8.1.1. “Spring Web MVC 框架”
        • 8.1.2. JAX-RS 和Jersey
        • 8.1.3. 嵌入式 Servlet 容器支持
      • 8.2 反应式网络应用程序
        • 8.2.1. “Spring WebFlux 框架”
        • 8.2.2. 嵌入式反应式服务器支持
        • 8.2.3. 反应式服务器资源配置
      • 8.3. 优雅关机
      • 8.4. spring安全
        • 8.4.1. MVC安全
        • 8.4.2. WebFlux 安全
        • 8.4.3. OAuth2
        • 8.4.4. SAML 2.0
      • 8.5. spring 会话
      • 8.6.GraphQL
      • 8.7. Spring HATEOAS
      • 8.8.接下来读什么
    • 9. 数据
      • 9.1. SQL数据库
      • 9.2. 使用 NoSQL 技术
      • 9.3. 接下来读什么
    • 10. 消息
      • 10.1. JMS
      • 10.2. AMQP
      • 10.3. Apache Kafka 支持
      • 10.4. Apache Pulsar 支持
      • 10.5. RSocket
      • 10.6. Spring Integration
      • 10.7. WebSockets
      • 10.8. What to Read Next
    • 11. IO
      • 11.1. 缓存
      • 11.2. Hazelcast
      • 11.3. Quartz 调度程序
      • 11.4. 发送电子邮件
      • 11.5. 验证
      • 11.6. 调用 REST 服务
      • 11.7. web services
      • 11.8. 使用 JTA 进行分布式事务
      • 11.9. 接下来读什么
    • 12. 容器镜像
  • Spring核心功能
    • 1.IOC容器和Bean简介
      • 1.2. 容器概述
      • 1.3. Bean概述
      • 1.4. 依赖项
        • 1.4.1. 依赖注入
        • 1.4.2. 详细的依赖关系和配置
        • 1.4.3. 使用depends-on
        • 1.4.4. 延迟初始化的 Bean
        • 1.4.5. 自动装配协作者
        • 1.4.6. 方法注入
    • 2. Resources
      • 2.1. 介绍
      • 2.2. Resource接口
      • 2.3. 内置Resource实现
      • 2.4. ResourceLoader接口
      • 2.5. ResourcePatternResolver接口
      • 2.6. ResourceLoaderAware接口
      • 2.7. 资源作为依赖
      • 2.8. 应用程序上下文和资源路径
    • 3. 验证、数据绑定和类型转换
      • 3.1. 使用 Spring 的 Validator 接口进行验证
      • 3.2. 将代码解析为错误消息
      • 3.3. Bean 操作和BeanWrapper
      • 3.4. spring类型转换
      • 3.5. spring字段格式
      • 3.6. 配置全局日期和时间格式
      • 3.7. Java Bean 验证
    • 4. SpEL表达式
    • 5. Spring 面向切面编程
      • 5.1. AOP 概念
      • 5.2. Spring AOP 的能力和目标
      • 5.3. AOP 代理
      • 5.4. @AspectJ 支持
        • 5.4.1. 启用@AspectJ 支持
        • 5.4.2. 声明一个切面
        • 5.4.3. 声明切入点
        • 5.4.4. 声明切点
        • 5.4.5. 切面说明
        • 5.4.6. 切面实例化模型
        • 5.4.7. AOP 示例
      • 5.5. 基于模式的 AOP 支持
      • 5.6. 选择要使用的 AOP 声明样式
      • 5.7. 混合切面类型
      • 5.8. 代理机制
      • 5.9. @AspectJ 代理的程序化创建
      • 5.10. 在 Spring 应用程序中使用 AspectJ
      • 5.11.更多资源
    • 6. Spring AOP API
      • 6.1. Spring中的切入点API
      • 6.2. Spring 中的 Advice API
      • 6.3. Spring 中的 Advisor API
      • 6.4. 使用ProxyFactoryBean创建 AOP 代理
      • 6.5. 简洁的代理定义
      • 6.6. 以编程方式创建 AOP 代理ProxyFactory
      • 6.7. 操作切面对象
      • 6.8. 使用“自动代理”工具
      • 6.9. 使用TargetSource实现
      • 6.10. 定义新的切面类型
    • 7. 空指针安全
    • 8. 数据缓冲器和编解码器
    • 9. 日志
    • 10. 附录
      • 10.1. XML 模式
      • 10.2. 自定义XML Schema
        • 10.2.1. 创作 Schema
        • 10.2.2. 编码一个NamespaceHandler
        • 10.2.3. 使用BeanDefinitionParser
        • 10.2.4. 注册处理程序和模式
        • 10.2.5. 在 Spring XML 配置中使用自定义扩展
        • 10.2.6. 更详细的例子
      • 10.3. 应用程序启动步骤
  • 使用redis实现分布式锁
  • Java 安全标准算法名称
  • JDK 9 JEP
  • JDK 10 JEP
  • 人件
    • 《人件》
    • 第一部分 管理人力资源
      • 01 此时此刻,一个项目正在走向失败
      • 02 干酪汉堡,做一个,卖一个
      • 03 维也纳在等你
      • 04 质量——如果时间允许
      • 05 再谈帕金森定律
      • 06 苦杏素
    • 第二部分 办公环境
      • 07 家具警察
      • 08 “朝九晚五在这里啥也完成不了。”
      • 09 在空间上省钱
      • 间奏曲:生产效率度量和不明飞行物
      • 10 大脑时问与身体时间
      • 11 电话
      • 12 门的回归
      • 13 采取保护步骤
    • 第三部分 正确的人
      • 14 霍恩布洛尔因素
      • 15 谈谈领导力
      • 16 雇一名杂耍演员
      • 17 与他人良好合作
      • 18 童年的终结
      • 19 在这儿很开心
      • 20 人力资本
    • 第四部分 高效团队养成
      • 21 整体大于部分之和
      • 22 黑衣团队
      • 23 团队自毁
      • 24 再谈团队自毁
      • 25 竞争
      • 26 一顿意面晚餐
      • 27 敞开和服
      • 28 团队形成的化学反应
    • 第五部分 沃土
      • 29 自我愈复系统
      • 30 与风险共舞
      • 3l 会议、独白和交流
      • 32 终极管理罪恶得主是……
      • 33 “邪恶”电邮
      • 34 让改变成为可能
      • 35 组织型学习
      • 36 构建社区
    • 第六部分 快乐地工作
      • 37 混乱与秩序
      • 38 自由电子
      • 39 霍尔加·丹斯克
由 GitBook 提供支持
在本页
  • 不要逃避风险
  • 我们几乎从不管理的一种风险
  • 为什么不达标的风险总是没有得到管理

这有帮助吗?

在GitHub上编辑
  1. 人件
  2. 第五部分 沃土

30 与风险共舞

在我们出版的《Waltzing With Bears: Managing Risk on SoftwareProjects》(与熊共舞:管理软件项目风险)一书中,我们讨论了两种相反的行为:没有风险管理意识的冒险,以及为了避免风险而造成没法做到任何具有突破性的壮举。现在,我们发现越来越多的组织在这两方面都存在问题:对于那些显而易见而又愚蠢的风险,他们选择了接受;同时却回避了那些代表组织转变的信号。

对于人件这个命题,我们的主要问题自然更集中于社会学,而非技术范畴,因而运用该主题,没有什么领域要强过风险领域。世人皆知风险管理的机制;要是风险没有得到妥善处理,原因很可能就出在组织的制度和文化上。

不要逃避风险

首先,我们需要澄清项目风险是一件好事情,这说明项目是有价值的。真正有价值却几乎没有风险的项目早就绝迹了。如今,重要的项目都需要冒点风险。

设想 Barnes&Noble 公司雇用你为他们的 Nook 电子书阅读器设计软件。下面是你要应对的环境:你们的主要竞争对手 Amazon 已经占据市场的大半江山;你们已经被远远地落在后面;你们的设备没有明显的优势(底层技术同样如此);你们刚刚开始与出版商就电子版权达成协议,你们可能永远都达不到 Amazon 已经上架的图书总数。你该怎么办?

当时,处在该职位上的那位,可谓初生牛犊不怕虎,他甘冒极大的风险,决定提供连竞争对手想都未曾想过的服务:电子出版物的图书馆租借服务。考虑要怎样才能让这个想法运作起来:不仅需要和出版商谈判,还需要和图书馆以及作者洽谈;设计并实现网络借阅的协议;在阅读软件里让借阅到期的图书失效;实现积分系统来奖励图书的作者。风险、风险,还是风险,并且附带着开拓未知市场的变数,推向市场时可能面临无人问津的境况。谁知道会有多少借阅量?

在这个案例上冒的风险收到了回报。Nook 携带着这一标新立异的功能一起捆绑销售,得到了市场的认可。

考虑自己项目上的风险清单。在项目运行过程中,很多事情都可能出错,管理这些风险就是你工作的主要部分。如果让你不假思索地快速列举出所有的这些风险,我们打赌,你一定会遗漏其中一种重要的风险:

我们几乎从不管理的一种风险

我们习惯性地不去管理的风险是我们自己的失败。如果你和你信任的团队需要和一个远在千里之外不知名城市里有时差的合作方互动,你当然会把他们可能出现的不达标当成风险来管理。这显而易见。但是,对于你和你的团队无法达成设定目标的风险呢?你当然会为此焦虑不安;甚至会午夜梦回,冷汗如浆地被噩梦惊醒。之所以没有将其列举到你的风险清单上,说穿了,是因为它会让你自己看起来很糟,像个失败者:毕竟,正因为你的能力使你得到了充分信任;这就是赋予你的职责。

为了说明不管理这一风险的危险性,我们需要思考风险管理的本质:不是让所有的风险都消失,而是确保风险发生时有相应的应对措施。应对措施应该提前就经过规划和演练了。

丹佛国际机场的行李输送系统就是这样一个例子。当权者决定系统必须按时交付,这一点至关重要,以至于根本未将不达标(延迟)视为风险。它之所以不是风险,只是因为它不允许发生。于是,风险就这样被管理上的决定给屏蔽了。

如果他们管理了该风险,就必须制定一个人工或半人工的备份方案,以预备在新系统没有按时交付时负责搬运行李。他们没有这样做,因而当系统延误时,只得推迟新机场的运营时间。一座不能投入运营的机场空置了超过一年,其资金成本最后高达数十亿美金。

当风险友生、系统无法按期交付时,才来计划应对措施已经太晚了。如果早做了第二手准备,准备好应对措施,就可以采用旧式的,临时使用人力小推车的方式运送行李,机场就可以开张了。软件交付的延期带来的不过就是一个小小的失望而已。咱们永远都不会听到这个关于丹佛国际机场行李输送系统的故事;除了项目中的人员之外,没人知道。

倘若一项风险出现的几率极低,那么不去管理还情有可原。但只是因为结果“想起来太可怕了”而不去管理这项风险,那就实在是没有道理了。

为什么不达标的风险总是没有得到管理

当需要完成的任务被视为挑战时,进取精神往往取代了风险管理。大家都会为挑战感到兴奋,所有人都欢迎挑战。在困难的情况下大家能够证明自己的能力。最不需要花时间的就是规划和预演他们自己的失败。时间是宝贵的,特别是当挑战同时又附带着紧张的时间表时更是如此。越是时间紧张,大家越是倾向性地不愿将更多的时间花在制定应对措施计划上。

这并非完全是坏事。如果一位管理者和他的团队都不进行风险管理,那一定会有其他人需要进行风险管理。最好的项目经理面对这种情况时会说:“大家注意,我们很愿意迎接这个挑战,还有这个有点恐怖的时间表,我们一定会做出最大的努力。我们不会有时间来管理那种尽管竭尽全力仍然会失败的风险。但是,我们需要有人挺身而出,负责管埋这个风险。除非我们看到有详细的措施,可以应对我们最后交付推迟的风险,我们不会认为这是一个挑战。这是一场愚蠢的、铤而走险的赌博。

中层管理者和决策者们往往善于将期望获得的结果说成是挑战:他们把挑战塑造为一种卓越的证明。但很多时候,他们并不是要指引团队去追求卓越,而是让团队尽可能廉价地完成项目。不合情理之处在于,项目收益越大,廉价交付却越重要。通过廉价交付来掩饰那些不当的利益肯定不是好的激励,所以,当决策者面临这样的情况时,通常会说:“这项工作非常重要,我们必须在 1 月 1 日之前完成。”他们其实真正想说的是,“这项工作其实根本不重要,1 月 1 日后,我们就不想给钱了。”

这是种虚假的挑战,但团队和团队负责人无法理解。他们可能会认可这一挑战的交付日期,并为之做出最大努力,这个过程中的所有风险管理都被虚假所笼罩。

虚假的挑战项目都有共同的特点:边际收益(因为组织回避风险,它们并非存在真正的技术风险),但时间安排的巨大风险基本是不受管理的。欢迎来到这两个最糟糕的世界。

上一页29 自我愈复系统下一页3l 会议、独白和交流

最后更新于5个月前

这有帮助吗?