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

25 竞争

关于团队和工作组内部的竞争是一个复杂的话题,管理者很少能够达成共识。你一定听说过,公司的存在就是为了能够跟其他公司竞争,所以延伸一下,公司内部的一点点竞争也是保持公司竞争力的健康手段。另一些管理者则认为,如果团队成员感觉到自己被强迫与队友竞争,那是有问题的。从极端角度看,竞争当然会阻碍团队凝聚。要是团队被告知:明年,他们之中只有最棒的一个才能留下来,毫无疑问,他们不可能在工作中友好相处并走向成功。

考虑一个类比

跟管理者一样,家长有时也不得不面对内部竞争的问题。他们会发现孩子们趋向于互相竞争。他们可能试图说服自己,保持竞争的态势有利于将来面对生活的磨难与艰辛,因而在家庭中保持这样的竞争是可以接受的。

但兄弟姐妹之间的竞争并不完全可行。例如,我们都知道,兄弟姐妹倘若是在激烈竞争的环境中成长,在长大之后通常都会变得疏远。那些竞争较少的孩子们一旦成人,更有可能建立起温馨的亲属情谊。存在一种几率,那就是至少有一个已经成人却从不来往的兄弟姐妹,又或者最极端的情况,整个家庭没有任何两个关系紧密的兄弟姐妹到了成人还能继续保持良好的关系。

目前,对于父母是否鼓励或制止兄弟姐妹之间的竞争,已达成了共识。竞争之所以产生,或许出于父母对子女的感情关心不够,他们没有足够的时间,没有给予足够的尊重、关心和爱护。

那么,团队内部的竞争可能由于管理者对自己的成员缺乏时间,缺乏尊重、关心和爱护而造成吗?尽管这种想法太过简单,我们仍然认为颇有道理。

这有关系吗?辅导的重要性

在需要一起工作的人群中强调竞争带来的长期影响是什么?首先,牺牲的是对健康团队而言必需的简单有效的个体辅导。

作为管理者,你可能已经说服自己应该作为这个团队或者所有向你汇报的团队的首选导师。在过去,这种做法司空见惯,高科技领域的趋势是老板们就是下属需要并值得信任的专家。今时今日,却不相同了。一个典型的知识型团队需要各种不同的技能,老板掌握的只是其中一些。老板只能辅导团队的部分人员。其他人怎么办?我们慢慢认同应该由团队成员自己提供大部分的辅导。

观察一个紧密协作的团队工作,你会发现直裁了当的个体辅导时常发生。团队成员坐在一起结对传递知识。每当此时,总是一人学,一人教。他们的角色随着时间推移不停交换,或许 A 辅导了 B 关于 TCP/IP 的知识,B 又会辅导 A 怎样实现队列。一旦这种方式得到了良好运转,参与者几乎是不自觉的,甚至不会有谁感觉到是在辅导;对大家来说,这就是工作。

无论提及与否,辅导都是成功团队互动的关键因素。它提供了参与者协作和自我提升的机会。同时,辅导会让人感觉愉快。让我们回想一次意义非凡的辅导,那种感觉近乎于宗教信仰般的体验。对于过去辅导过我们的人,我们备感亏欠,通过辅导他人,我们心花怒放地还清了债务。

若大家感觉不够安全,辅导行为就不可能发生。在一个竞争环境中,除非你疯了,否则才不会让人看到你正在接受辅导呢;因为这足以说明就这方面的知识来说,你知道的内容要少于辅导你的人。同样,你也不会去辅导别人,因为被辅导的人最终可能青出于蓝而胜于蓝,靠你的帮助超过你。

再谈团队自毁

内部竞争会直接造成辅导工作异常艰难,甚至根本就不可能。由于辅导是健康团队工作的核心,管理者做的任何增强团队内部竞争的事情都是在进行团队自毁。下面是一些能够引起团队自毁副作用的管理行为:

  • 年度薪酬评审

  • 目标管理法(MBO)

  • 表彰个别员工的突出成就

  • 跟绩效相关的证书、奖励和奖金

  • 任何形式的绩效考核

等一等,上面的事情是管理者花很多甚至大部分时间在做的啊?是的,很遗憾,正是这些行为在导致团队自毁。

W. Edwards Deming 在他 1982 年出版的《走出危机》一书中,总结了现在被普遍遵守的“十四点”。隐藏于其中的第 12B 条基本可以看做是深思熟虑的结果:

在管理及工程过程中消除阻碍人们追求匠艺的障碍,就意味着(和其他事情一起)废除掉年度或量化评级与目标管理的方式。

即使是自封为戴明( Deming)推崇者的人士,对上面这点也难以接受。他们感觉有点跟不上,那么该做些什么来代替呢?戴明的观点在于 MBO 等系列方法都是管理者站不住脚的借口。使用简单的外部激励来促进绩效,会使得管理者们不去处理应该思考的复杂事务,如能力投资、个人直接动机、团队形成、人员留用及可持续的分析以及对工作流程的再设计。

我们的观点更保守一点:针对团队成员的任何不同的奖励机制都可能增加内部竞争。管理者需要采取措施降低或抵消这样的影响。

混合的隐喻

我们中断行文为的是……

作者们令人震惊的坦白。

在写作本书时,我们曾经讨论并使用体育团队来作为一个强凝聚力技术团队的隐喻;现在,现实迫使我们从这个隐喻中清醒过来。

这些日子,最让我们恼火的是体育团队隐喻下的竞争。橄榄球、足球和棒球团队在联盟里比拼,但同时他们也鼓励激烈的内部竞争。对那些“坐冷板凳”的队员来说,必然会或多或少地感觉到与一线球员的竞争。当然啦,他们还是帮助大家取得了胜利,只是这个过程可能并不那么令人愉快。

高中时候,我是学校体育篮球队最矮的一员。我还记得只有在那个家伙犯规下场时才能轮到我上。他的名字叫 Doug Timmerman。他是那种该死的最有天赋的球员;他几乎从不会对别人犯规。我像兄弟一样喜欢他,但还是…… -TDM

我们都见过体育团队不受某个队员失败的影响而获得成功;我们也见过尽管个别球员拥有精彩表现的一晚,团队还是输得很惨。所以,个体的成败与整个团队的成败看起来风马牛不相及。这种状况并不完美,只能让最初对于竞争的倾向更加恶化。

对比之下,像唱诗班、合唱团这样的组织就建立起了几乎完美的个体与团体成败绑在一起的关系。(不会有人来祝贺你演唱的部分非常成功,而整个唱诗班却跑调了。)

因此,虽然有些晚,我们还是希望告诉你音乐组合是我们认为对形成凝聚力小组更贴切的隐喻。当然不只是我们用“团队”这个词来描述这样的小组。

不管你喜欢称之为“团队”、“组合”,还是“和谐工作组”,都没有关系;有关系的是要帮助所有人理解个体的成功是完全建立在集体成功之上的。

上一页24 再谈团队自毁下一页26 一顿意面晚餐

最后更新于5个月前

这有帮助吗?