🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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. 第四部分 高效团队养成

28 团队形成的化学反应

一些组织被公认为在培育良好的融合团队方面保持了持续的好运。当然,这不是什么好运,而是化学效应。在这些组织中,一种混合了竞争与信任、相互认可、友善共处的社会氛围为高度融合团队的养成提供了肥沃土壤。而且,并非仅仅是团队形成受益于这种因素。所有事情都运作良好。这样的组织可以称之为健康的组织。

这里,我们不再谈论自己经历过的例子,而是引导大家回顾自己的经历。你是否曾经工作于一家焕发健康气息的组织?大家都很放松,享受工作,很喜欢跟其他人交流。这样的环境没有防御保守的气息,没有个人罔顾集体努力,只想着获得成功。大家的工作是一个整合的产品,每个人都对产品质量感到自豪:(在你现在的环境里,至少应该有一丝这样的健康气息;如果不是,可能到了更新简历重新出发的时候了。)

在这样健康的公司里,我们的管理者在于什么呢?一个快速的表面评估可能让你认为他们无所事事。他们看起来不忙。他们不给什么方向。无论与身边的工作是何关系,他们肯定什么事情都没做。

在拥有最佳化学反应的组织里,管理人员把自己的精力放在建立和维护这样的健康化学反应上了。团队和部门能够焕发健康的气息,全是因为管理者在背后推动。因为没有有效的体系理论来总结他们的方法,所以很难分解和分析这些组成部分(组合成的整体能够融合到一起,这比了解组成部分要重要得多)。但做这种分析仍然值得尝试。

下面是一个简化了的健康组织构成策略的化学元素清单:

  • 建立对质量的执著追求

  • 提供诸多满意的闭环

  • 建立精英意识

  • 允许和鼓励差异性

  • 维护和保护成功团队

  • 提供战略而不是战术方向

这些元素不胜枚举,我们这里只列举了跟团队形成相关的元素。在下面的小节中,我们将一一阐述这里列举的元素。

对质量的执着追求

评价一件不完美的产品“足够好”,就等于敲响了团队融合的丧钟。交付一件普通的产品,根本不能推动你们小分队内部产生协同的满足感。反过来,“只有完美对我们才足够好”却给了团队真正融合的机会。对质量的执著追求是催生团队形成的最强催化剂。它之所以让团队凝聚起来,是因为它拉远了团队每个人与其余世界的距离。不得不说,其余的世界并不会为质量鸣笛。

嗯,说起来轻松,当真要为质量多花一分钱时,很快就能看清楚大家的成色了。我们的朋友 Lou Mazzucchelli 是 Cadre 科技的创始人之一。一次,他想要购买一台碎纸机:他让销售人员给他演示,质量非常糟糕,又大又吵(就算不碎纸,也发出轰轰响)。我们的朋友询问一款他听说的由德国制造的碎纸机,那款机器价钱要多出几乎一半,还没提供任何其他额外功能。这名销售极为傲慢,他不屑地说道:“你付出更多的钱,买到的不过是好点儿的质量罢了”。你的市场人员、产品使用者、客户和你的上级领导永远不会为高质量而摇旗呐喊,从短期经济回报上分析,追求一流的质量并不合理。若你的团队对质量报以执著追求,他们总是会交付超出市场要求的高质量产品。只有不受短期经济回报的影响,他们才能够这样做。收益会长期回报给你们。大家在质量上的高追求,会驱动他们精益求精,更好地保持对质量的追求。

对质量的执著追求就像牡蛎中的细沙,它是团队融合的凝聚点。

结婚时,我告诉她我爱她

或许有些人闻所未闻,但是人类自己就是需耍不停确认他是否正沿着正确的方向前进。人类团队同样如此。在哲学上,这种确认称之为闭环( Closure)。闭环就是整体的每一部分皆需要一致满足的“过程”。

组织同样需要这样的闭环。这种闭环就是成功完成给定的任务,加上过程中不时地对按计划执行的确认(可能是达到一个里程碑,或者关键部分完成交付)。企业到底需要多少次确认,取决于就此风险需要付出多少投资。有些时候,一个组织可能 4 年一次闭环就足以满足需求了。

这里存在的问题是:组织在闭环上的需求远远低于在组织中工作的人们。如果工作了四年,都没有进行一次确认工作是否满意的“过程”,难免会让团队的每个人都忍不住想,“我可能熬不到这件事结束了:”特别是在团队逐步形成的时候,频繁的闭环是很重要的。团队成员需要建立一种共同成功和共同认可的习惯。这是能够帮助团队提升士气的一种机制。

那些建立化学反应的管理者努力把工作分解为小块,同时,确保每块工作都能够显式地展示完成后的成果。这样的管理者可能计划交付 20 个产品版本,即使对于高层管理者和用户而言,只要两个就足够了。可能是对客户隐藏了中间的几个版本,只是为团队内部的确认和达成而构建。每个新版本都是一次闭环的机会。团队不停地预热,直到那个时刻到来,团队临近最盾凝聚,在成功中达到顶峰。它成功为团队的下一步积蓄更新的能量。这会让大家感觉更加紧密。

精英闭队

20 世纪 70 年代初期,我们一个客户的副总给他部门的员工群发了一封关于出差费用的通告。你可能收到过类似的通告,但这封信却与众不同。通告的大意是:“最近,我注意到你们一些人在出差时乘坐的是经济舱。我们不是一个经济舱级别的公司。我们是头等舱级别的公司。现在开始,如果你为公出差,请坐头等舱!”当然,这封通告意味着得花不少钱。花费是实打实的,得到的却是精英意识的提升,这足以平衡这些额外的花销了。至少该公司认为这是一个合理的交换。或许你会说,在真实世界的公司里,这可能发生吗?天方夜谭吧!然而这真有其事,这事发生在 Xerox。

那些认为爆米花“不职业”的人,会认为团队的精英意识是右翼颠覆。普遍认为如果团队在某一方面过于标新立异,管理者就没法完成他的份内工作。团队能够遵从企业的统一标准,是管理者管控得当的标志。然而,从被管理的员工角度出发,这样的标志是毁灭性的。管理者越是觉得舒适,就越会让团队失去新鲜血液。

大家都需要一种独特感来体察内心的宁静,从而在宁静之中发酵出团队的凝聚力。即使管理者尝试去抑制独特性,独特性还是会滋生出来。大家会在不受管理的维度上表现自己的独特性:举例来说,倘若有这么一个人,他总是给管理者制造麻烦,或者没法激励,或者耻于与他人协作,这就表示可能存在过度管理。大多数人更愿意用不那么刁难的方式、那种不会损害团队共同效率的方式来表达自己:

对于一个无论质量意识还是工作效率或能力都显得独特的团队来说,有什么能够阻止他们达成一个具有挑战的交付日期呢?你可能会想,没有,可名义上被全盘接受的这种独特性,还是会让不少管理者感到不安。他们抱怨团队桀骜不驯,骄傲自满。团队精英意识带来的真正威胁并非无法管理,而是让管理无所适从。团队可能坚定不移地追求成功,管理者却担心自己会被看做是懦夫。

如果有方法让你管理的员工产能增加、目标明确,但要减少对他们的控制,你愿意去做吗?这个问题的答案可以帮助我们从泯然众人中甄别出一流的管理者。普通的管理者没有安全感,以至于走不出管理的陷阱。一流的管理者知道人们不能被任何合理方法控制。成功管理的核心是让大家齐心协力,然后助推大家到一个连管理者自己都无法让他们停止的点。

一个富有凝聚力的团队能够让大家更加高效,营造出目标驱动的氛围。当团队凝聚时,你确实需要放弃控制,或者放弃这种受控制的假象:团队在某个点或某几个点上开始感到独特,成员们分享着共同的精英意讽。团队的独特点并不需要任何基础的东西。例如,一支橄榄球冠军球队的防守组合唯一的独特点就是团队每个人都“默默无闻”。这就够了。他们为此感到自豪并且团结一致。不管精英的特点是什么,它都是形成团队标识的基础,这种标识是有凝聚力团队的一个本质要素。

这里,一个重要的限定条件是团队需要在某些方面感到独特,但并非所有方面。遵守组织规则的团队比比皆是,军事化的团队和大多数体育竞技团队都统一着装:但只要他们能够在一些方面感受到自己的独特,在其他方面就能够去遵守。

感受到精英团队威胁的管理者,常常谈论精英意识对外界人员的危害。倘若一个小型工作组的成员自诩为成功者,那岂不是其他人就被自动归为失败者?有些极度成功的团队,确实会让其他团队感受到压力。但这并非是团队成功造成的影响。如果只有你存在这个问题,那你真该写一本你自己的书。

不要拆散洋基队

如果团队已经凝聚,就不要拆散团队。至少,要给大家一个机会在一起尝试另外的项目。他们可能会选择分头行事,但这是他们应该有的选择权。当团队一起从一个项目转到下一个,他们会动力十足地踏上新的征程。

团队行为的网络模型

这可能会让你作为一名管理者感到很受伤,但多数情况下,管理者并不是团队的一员。团队是由平等的个体组成的。大多数情况下,管理者都游离在团队之外,不时为团队提供来自上面的方向,同时清除行政和过程中的障碍。根据定义,管理者就跟大伙儿不平等,因而不是团队的组成部分。

这一理念会让以领导力自豪的管理者感到沮丧。难道管理者不是应该提供领导力,像四分卫那样,通过明智的选择和精准的计时带领团队向着胜利冲刺吗?这听起来很美,但若是团队需要这样的领导力,那就压根儿没像一个团队那样运转起来。在最棒的团队中,不同的个体时不时会展现出领导力,在自己擅长的专业领域带领大家。没有人是永远的领导者,因为这样的领导者不会是团队中平等的一分子,团队里的互动也会由此瓦解。

团队的结构是一个网络,而非分层结构。故而,认同领导力(在我们这个行业,是如此狡猾的用语)这个概念在这里没有市场。

中餐菜谱的选择

在写团队时,我们或多或少借用了体育团队来类比我们的行业。团队这个词会让大家想到一群健康的年轻人,正挥汗如雨地追逐着橄榄球或冰球之类的场面。想到团队就很难不联想到体育,然而,使用体育团队的类比也随之会带来一些负面意义。

周末电视上一支活力四射的典型团队,通常都是由一群相似的个体组成:就拿篮球队来说,队员可能都身高体壮、年轻、性别相同。之所以相似,在于他们努力的目标驱使他们这样。开发项目中的团队并没有这样的相似性需求。但由于受到体育团队范例的影响,我们通常会期望这种相似性出现在我们的团队中,同时,可能会无意识地打造这样的团队。

存在一点差异才能极大地帮助我们形成一个有凝聚力的团队。一名行动不便的开发人员加入到一个新组建的工作小组中,会让团队团结的几率大大增加。加入一名实习生或者一个刚刚接受完再培训的行政人员,都能产生同样的效果。不管这种差异的元素是什么,对团队成员来说,象征意义更重要。这是一个明确的信号,不要成为某个人的克隆,也不需要完全统一的“橡胶人”,就好像从同一个企业模子里铸出来一般。

最惨的例子就是全部由男性组成的高度同质化团队。当然,女人在团队里跟男人一样工作。所有在混合团队中工作过的男士,很难想象在一个全男性的环境里工作。这一点,我们的先辈体会颇深。

做个总结

你不能每次都促成它发生,但当一个团队真的凝聚起来时,任何代价都是值得的。人们工作愉悦,精力充沛。大家达成一个一个交付期和里程碑,并不断前进。人们彼此欣赏,并且忠于这个团队以及让这个团队能够存在的环境。

上一页27 敞开和服下一页第五部分 沃土

最后更新于5个月前

这有帮助吗?