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

21 整体大于部分之和

“团队”这个词在商业世界里常常被广泛使用,对拥有共同任务的一群人都称其为“团队’’。然而,很多这样的小组并不像团队。他们没有对成功进行共同定义,或者没有一种可识别的团队精神。某些东西缺失了,那是一种被我们称为“凝聚力”的现象。

有凝聚力团队的概念

一个有凝聚力的团队是一组紧密交织在一起的人,他们的整体大于个体之和。这种团队的产出要大于那些在一起工作却如散兵游勇的团队。重要的是源于工作本身,大家从工作中得到的乐趣远远超出你的想象。有时,别的团队视为沉闷乏味的工作,有凝聚力的团队做起来却甘之如饴。

一旦团队产生了凝聚力,成功的几率将大大增加。这样的团队几乎不可阻挡,如同一台推向成功的推土机。管理这样的推土机团队是相当令人愉快的,你主要的时间都花在清除路障、铺平通向成功的道路,防止局外人拖累团队上——“他们来啦,大家给他们让出一条通道,看他们表演吧。”这样的团队不需要传统意义上的管理,更不需要激励。他们斗志昂扬。

产生这种现象的原因并不复杂:团队都是围绕共同目标成立的。(想想体育运动团队:没有一个目标,还能称其为团队吗?)在凝聚为团队之前,团队中的每个人可能都有自己不同的目标。但作为凝聚过程的一部分,他们聚拢所有,汇为一个共同目标。公司级目标至关重要,因为它对团队而言意义非凡。目标自身对团队成员来说可能有一定的随机性,但大家可以竭力去追求目标的实现。

歇斯底里式的乐观管理

接下来的内容可能让一些管理者感到不舒服。他们觉得任何让员工接受公司目标的工作都是多余的。我们为什么需要刻意组建内部社交单元来做这样的事情?说到底,职业工作者难道不应该把接受雇主的目标作为雇用的前提条件吗?这难道不是职业素质的基本表现吗?

相信员工都会自动认同组织的目标,只能说明管理上的盲目乐观:要让个体把自身融人组织目标中的机制实在太复杂了。你不必为此感到惊讶。例如,你熟知的那位同事,作为一名数据库专家,他却更倾向于把自己描述为一位父亲,或童子军的领队,或本地学校执委会的一员二在这些角色中,他随时都在通过深入思考做出价值评判。让人诧异的是,他是否会在谈及工作时停止进行价值判断呢?他不会二他会在工作中持续她评判和他个人能力及信任度有关的各种言论:组织里的人时刻都在批判组织目标,而且,他们认为大多数目标都过于随意。

这里的困境在于,倘若你是一名老板,你可能真心诚意地接受了企业的经营目标(比如明年 4 月交付项目,并且预算在 750 000 美元内)。要是你的员工不够热情,你就会感到失望。他们兴趣缺乏的表现可能会被你视作背叛。但回头想想:你自己对企业目标的强认可也许也不仅仅是职业素质的表现吧?难道不是你的老板或者企业高层通过一点点聪明的设计,让企业的目标和你个人的目标一致带来的吗?完成企业的目标当然会让你拥有更多的权利和职责:“今天是 Sysboombah 项目,明天就是世界!”利用组织阶梯,保证管理者有强烈个人动机去接受企业目标,这种设计真是太巧妙了。然而到了最底层,在真正开展工作的地方,这种天才的设计失效了。在那里,我们仅仅希望用所谓的“职业素质”来保证大家都向同一个方向前进。这完全就是撞大运。

如果你为拯救蜗牛鱼协会这样的组织工作,所有员工拥有共同信念,自然就可以依靠大家对组织目标的认同感。如果不是,那么就别再心存这样的幻想。执行委员会热情高涨地制定出利润大幅增长的目标,同样的目标底层的员工根本提不起兴趣。MEGALITHIC 公司利润增长 10 亿美金,挺好……公司创纪录的季度表现,唿嗯嗯。

我曾经为一家大型个人财务公司实施了一个电信项目。这家公司的一项业务是向穷人放贷并收取很高的利息。这项业务当时在 23 个州都是非法的。公司获利已经很高,管理层希望继续增长利润率,但这一目标并不为下面的员工轻易认同。一个星期五的下午,管理层代表团过来跟我聊天。他们说公司历史上最好的第二季度就在我们手里了,加油干。他们请我务必把这件事情传达给团队其他人,让大家“集中精力”。这已经是我工作过的最具凝聚力的一个团队了,但我还是尽职地转达了管理层的想法。(尽管是星期六,他们还是让全队都来了。)管理层的激情对于团队来说就像耳边风。首席程序员听了后说:“谁爱管第二个季度谁管!”半小时后,大家就各自回家了。 -TDM

建立这个系统是一个强制目标,但团队接受了。这就成了团队组建的基础。从大家凝聚在一起开始,团队就成了他们真正的动力。他们在一起为了协同的成功,一起成就一个目标——任何目标。重新让大家聚焦到公司在这个项目上的收益毫无帮助,只能让团队的成功变得索然无味。

纳瓦隆大炮

企业的目标或多或少总是会让大家感到过于专制——企业对人们来说本来就是专制的——但带有强制性的目标并不意味着没人接受。如果真是这样,那么就不会有体育竞赛了。体育竞赛的目标总是强制的。整个宇宙对于在阿根廷和意大利半场交替的一个小白球漠不关心,但很多人却对结果相当投入。这种投入是他们所处社会单元的一种功能。

团队外围的人可能对团队的成败感兴趣,但他们的兴趣相对团队成员来说就微乎其微了。在凝聚力强的团队中工作的人们常常会过度投入,以至于疯狂到想要使用纳瓦隆大炮,仅仅是为了通过退休金系统第三版的验收测试。你不得不提醒他们正在突击完成的不是“道义战争”这样的命题。

尽管有凝聚力的团队拥有这样的动力及热情,管理者却不愿意经历必需的痛苦去孵化它。部分原因在于不理解为什么团队需要凝聚力。对达成目标有强烈驱动力的管理者会发现团队并不会帮助达成目标,反而是团队里面的人在达成目标。为达成目标,分解的每个任务基本都是由团队中的个体来完成的,大部分工作也是由个体单独完成的。

在我们的工作中,真正意义上的团队合作很少。但团队仍然很重要,因为它能够让每个人劲往一处使,心往一处想。

团队存在的目标不是达成目标,而是让目标一致。

一旦团队实践其目标,团队申的成员会更加高效,因为他们找准了方向。

有凝聚力团队的标志

如果团队拥有下面这些特征,则说明一个具有凝聚力的团队形成了。最重要的一项是在项目和任务执行过程中的低人员流失率。团队成员都愿意留下来完成项目。凝聚前,一些非常重要的因素(钱、地位、升职)在凝聚后变得微不足道,甚至无关紧要了。大家自然不会为了老套的例如多点儿工资而离开团队。可悲的是,管理者通常会忽视团队成功的标志。即使情况已经很糟糕,他们仍然不愿意关注人员的流失;当流失率较低的时候,他们根本就不会去想。

有凝聚力的团队通常都有一个很强的自我认知。行业里经常会听到绚丽多彩的团队名称:通用电器的“Okie Coder”、杜邦公司的“Gang Of Four”或者辛辛那提电气公司的“Chaos Group”。队友之间都用一些朗朗上口的称呼而且会分享诸多玩笑。团队可能拥有明显的地盘,大家聚在一块儿共进午餐,或者在下班后吆喝着一起去哪儿喝一杯。

在好的团队中,有一种精英的感觉。队员们都觉得自己是独特事物的一部分。他们感觉比机器强多了。他们自有一种傲慢,就像 SWAT 特警队那般的态度,从而使得那些不在团队的人们感到不舒服。

有凝聚力的团队对生产出来的产品有强烈的归属感;参与者都希望一个产品或者某个组成部分能够留下大家的名字。每个人都希望别人看到自己的成果,随着产品的成型,团队的地盘装饰着产品的各种展示。

有凝聚力的团队的最后一个标志是队员们对工作乐在其中。有凝聚力的团队显得健康而拥有活力,交流轻松自如,自信而充满热情。

团队和团伙

如果上面提到的有凝聚力的团队紧密抱团,认为自己高于世界的样子让你感到不舒服——可不仅仅是你一个人会这样认为。我们完全可以想象,你会暗自琢磨,“等等,这些家伙说的‘团队’更应该称为‘团伙’。团队可能不错,但对于团伙,不是应该不惜代价去避免吗?”

团队和团伙的区别就像微风和阵风。微风和阵风意义相同,都是“凉的流动空气”:若你感觉这种清凉空气的流动让人心旷神怡,你会说这是微风;如果让人烦闷不安,你会说这是阵风二内涵不同,但词义确乎相同。同理,团队和团伙在词义上没有区别,内涵却完全相反。当一个密切协作的 T 作小组凝聚在一起并让大家感到愉快时,大家会说这是一个团队;但如果让大家感觉是一种威胁,人们会视其为团伙。

对团伙的恐惧是管理缺乏安全感的表现。越感觉不安全,越害怕团伙这个想法。个中自有因由:管理者往往不是真正意义上的团队成员(见第 28 章中的更多讨论),所以,被排除在团队外的感觉超过了跟团队紧密相连的感觉。团队内部的信任程度也要高于把团队联系在公司内的信任度。然后,就会滋生一种糟糕的想法,认为紧密连接的团队可能会脱离集体而把所有的动力和热情用于竞争。就是这些原因,造成了缺乏安全感的管理者们惧怕团伙的情形。他会感觉跟一群统一的可替代的塑料人一起工作会更好。

一个拥有凝聚力的工作组可能自傲、自足、让人头疼还有点排外,但对比拼凑起来的可替换部件,它却能帮助管理者实现真正的目标。

上一页第四部分 高效团队养成下一页22 黑衣团队

最后更新于5个月前

这有帮助吗?