🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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. 第五部分 沃土

35 组织型学习

有些组织具备学习的能力,有些却未必。有些组织能够学习,却不能学以致用。有些组织疏于学习,学习进度远不如荒废的时间。我们都知道“业精于勤荒于嬉”的道理,明白学习的重要性,它是一种至为重要的进步机制,若不学习,则不足以保证基业长青。

经验与学习

要理解组织型学习,首先需要知道的是,它并不能和经验的单纯积累画等号。比如,在 20 世纪 30 年代,法国军队将积累了数百年的作战经验用于保卫其东部的边境,但是他们依然需要依赖于马其诺防线来抵抗德军。发生在 1940 年 5 月的史实向全世界证明,法国人在平衡武器库和军队机动性方面还欠些火候。

相似地,高科技公司可以以惊人的速度积累经验,但是,他们依然无法保证如何让学习跟上这种速度。

我有一个客户,这家公司拥有超过 40 年软件开发经验。在那个时期,公司拥有上千名开发人员。因此,公司的经理常常夸耀说,他们的公司拥有四万人年的软件开发经验。我当时颇受震动:想想每个新项目开始所需要学习的内容!于是我询问了其中一个团队:“当你们安排一名新的管理者去管理一个新的软件项目时,你们会给他悄悄透露什么锦囊妙计?”团队成员们想了想,几乎异口同声地回答:“祝你好运!” -TRL

当一个组织开始考虑经验的表现形式时,此时,经验便能转换为学习。这个过程存在着两种迥然不同的形式,因此我们需要分开讨论:

该组织将新的技能传授给自己的员工。

或者

该组织以另一种不同的方式来运作。

对于第一种形式,变化会直接带来人力资本的增加(更多内容请参考第 20 章)。如果接受培训的员工离开了,投资也就泡汤了,知识的传授也随之付诸东流。若是第二种形式,变化会临时性地存储在那些实施了再设计的人的大脑中。最终,它将变成整个组织的知识储备。然而,由于在过渡时期,知识掌握在少数人手中,如果这些关键人物离开,整个组织的学习活动也将受到危害。无论采取哪种形式,组织都将面临以下风险:

学习受限于一个组织留住员工的能力。

如果人员离职率过高,学习便无法维持下去,或者根本无法进行。在这样的组织里,试图改变技能或者引入重新设计的过程都是徒劳之举,甚至有可能使员工离职率更高。

一个重新设计的例子

在一些具有强制措施的组织型学习中,对供应链进行了重新设计,这是组织型学习的一个很有竞争力的例子。当然,这需要一个可靠的掌舵人,还需要将视野放在组织之外去思考问题。请参考以下例子,该例子是前些年 Nicholas Negroponte 在卡姆登举行的电信大会上讲到的:

为了将商品交付到最终客户手中,Amazon 公司和每一家合作方都建立了内在联系,就当前而言,Amazon 会让联邦快速公司到自己的仓库取书,然后将书空运到孟菲斯(联邦快递的中转城市),再将书运送到离客户最近的机场、现在,设想一下如果 Amazon 将仓库放在联邦公司于孟菲斯机场的周边一在销售每一本书时,依然会通过 Amazon 在西雅图的总部进行处理,但是此时图书将直接从孟菲斯仓库取出,并形成订单二 Amazon 由此获得的好处在于:为每一笔订单减少了一半的物流距离。

能够做出这种改变的组织可以不断地进行改变。你可能在想,是什么让他们变得如此敏捷。

组织型学习的关键问题

组织型学习的关键问题不在于如何开展学习,而在于在何处开展。当一个组织想要像 Amazon 一样改变自身时,它需要一些小的但却活跃的学习中心来构思设计,管理变化。(这类雄心勃勃的改变是不能从什么委员会或者整个组织中获得的。)早期的改变活动即学习,应该在整个组织中找到自己的位置。问题是,应该从哪儿开始?

有人说,学习应该从组织的顶层开始。但是,就我们的经验来看,那些处于组织顶层的人们并不会将心思放在日常的工作事务中。比如,那些大中型企业的老大都将时间花在进行并购(或者将其他公司彻底击败)上:

与之相反,有些人认为组织型学习应该从底层开始:但是,在真实世界中这些想法无异于镜花水月。底层的人们通常受限于他们所在的组织边界,而且可能会对一些重要的时机视而不见。因此,他们很少能够主导实际的改变:

如果关键的学习既没有在顶层,也没有在底层发生,那就可能二者取其中。这意味着在许多组织中,多数自然而然产生的学习中心都发生在位于组织中间的管理层。根据我们的观察,成功的学习型组织通常都拥有一支非常强大的中间管理层。

值得一提的是,如果组织要减小规模,几乎总是中间管理层成为削减目标。换句话说,每隔几年便会发作一次的“绷紧轮船”(tightening ship)活动,其实是以牺牲组织型学习为代价的。在此之后,一个组织型学习中心可能会被摧毁。

管理团队

通过消除中间管理层来碾平组织结构图的确是减少学习的秘方。但是,反过来却未必正确:依赖于中间管理层自身并不能让学习取得成功。这其中还有另外一个因素。这个因素很少得到正确的评估,甚至缺乏培养的土壤。那就是为了形成一个重要的学习中心,中层管理者需要相互交流,并在一起高效融洽地工作。这是一个极为罕见的现象。

几乎所有公司都存在一个所谓的“管理团队”。通常,这样的管理团队都由中层管理人员组成。就像我们在先前观察到的那样,将“团队”一词用于一组人,并不能保证这组人就一定能够像一个团队那样工作。他们可能只是一群乌合之众,没有共同目标,没有共同价值,也不具有互补的技能。对于大多数所谓的“管理团队”,这是常见的情形。

在第 23 章和第 24 章中,我们曾提到对管理者团队来说,通常存在以下现象:团队成员的自我防御意识很疆,受官僚主义之累,他们都被分配给不成体系的零星任务,相互隔离,加班加点工作,并且需要和其他人相互竞争。这样的团队不可能成为一个有机整体。

更糟糕的是,他们缺少的正是任何一个团队都需要的东西:工作产品的集体所有权。他们在团队中取得的任何成就都只是出自于团队中的某一员,而不是该团队作为一个整体的成就。管理者之间的竞争性越强,这种情况就越明显。我们甚至看到了极端的例子,潜规则是:“要是事情有利可图,那就千方百计抢到它;要是抢不到,就破坏它。”

在多数情况下,“管理团队”就是一个让人遗憾的误称,沦为健康团队口中的笑柄。管理团队中的成员在项目状态会上虽然集中坐在一起,轮流向上级汇报工作。但是,他们彼此很少合作。

空白地带的危险

在任何规模的组织中,最适宜的学习中心通常都位于中层管理者之间的空白地带。倘若这样的空白地带成为重要的交流渠道,倘若中层管理者能够作为组织的重新设计者协同工作,共同承担,那么学习的益处便有可能获得。另一方面,如果空白地带变得既没有交流,又没有共同目标,学习就会停滞不前。如果中层管理者彼此相互隔离,严阵以待,钩心斗角,那么从这个角度讲,这样的组织实在还处于茹毛饮血的蒙昧阶殷。

上一页34 让改变成为可能下一页36 构建社区

最后更新于5个月前

这有帮助吗?