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

24 再谈团队自毁

我们在前一章谈到的七种团队自毁让我们感到(当我们在写第 1 版的时候)头绪有点过多。但有两种重要的团队自毁却被我们忽略了。像前面七种一样,这两种在我们行业中也是司空见惯的。其中一种甚至成了必需品,造就了一个小的行业来支持它……

可恶的标语和纪念碑

下次坐飞机时,你可以翻开一本航空杂志或者航空购物指南,扫一眼满页的广告。在某个地方,你会发现一处色彩鲜艳、鼓动人心的招贴,配上特定话语的企业展示(唯恐别人用那块地方展示工作产品)。不要一扫而过,强迫自己认真读读,在你的脑子里把玩一下他们的宣传口号。如果你读完了还不感到愤怒,说明你可能被糟糕的管理者管得太久了。

大部分形式的团队自毁,其危害来自于贬低工作或者贬低做工作的人。工作的重要性和把工作做好的价值可以催化团队。在这句话中,词汇“好”至为关键:团队给自己的任务是要达到匠艺的水平。所有成员都知道工作质量对于组织的重要性,而团队会通过遵守更高的标准脱颖而出。没有这一突显的因素,小组还是小组,不会成为真正的团队。

在这个复杂的机制里,想象一下咱们花 150 美元买了一条标语,提醒大家“质量第一”。呃,我们从来没这样想过,我们从来都觉得——直到这条精彩的标语出现——质量是第 29 位,或者 117 位,或者甚至连公司认可的价值都没有,就是茶余饭后的事情。但现在我们知道了,谢谢!

他们称为励志小附件( motivational accessories)的东西(包括印着口号的咖啡杯、纪念牌、别针、钥匙链和奖杯)就是形式大于实质的表现。他们好像在宣扬质量、领导力、创造力、团队协作、忠诚守信和其他组织美德的重要性。但其实通过这样简单的形式却发出了完全不同的信号:管理者相信这些美德可以通过搞些招贴就能提高,并不需要努力工作或者什么管理才能。所有人很快就发现,这些招贴就是不用努力工作、无须才能的保证。

使用励志招贴来对待如此重要的事情已经是一种侮辱,执行过程还让事情变得更糟。我们看看一家公司做的宣传:在薄雾轻绡的早晨,柔光之中一队大汗淋漓的划桨手正在整齐地划桨。配以下面的文字:

团※队※合※作 让普通人能够获得非凡结果的燃料

这里说的“普通人”就是你和你的同事们。普通人(不要太介意),至少他们态度上是一致的:网一家公司关于领导力的招贴告诉我们“领导者的速度决定了大伙儿的效率”。大伙儿,是的,这也是在说你。

励志小附件假到让大家起鸡皮疙瘩。它们给健康的组织带来危害。只有当它们被忽略的情况下才对组织无害——在一些公司里,很久以前就发生了这样的破坏,人们已经变得麻木了。

加班:一种意外的副作用

你可能已经从本书原来的章节中读到了我们对加班的偏见。我们的经历说明对于额外工作时间的好处被夸大了很多,副作用却从来未被考虑过。副作用很明显:犯错、累倒、离职率上升和付薪的无用时间。在这一节,我们考虑加班的另外一个副作用:对一个良性运转的工作团队的自毁反应。

想象一个项目,团队凝聚力很强,你和你的同事以让人吃惊的速度在开展工作,即便对你或者你的老板来说,这都是前所未有的。你们都知道这是团队凝聚的整体效应,即团队作为一个整体的产出已经超过了每个个体产出之和。但这可能还不够,上层已经承诺六月份交付产品,以现在的速率看,根本完不成。

听起来像是一个可以加班的案例,不是吗?于是,你给团队上发条,每周增加几个小时(仍然在高产出率上),或者几个星期六工作。只有一个问题:你的一名团队成员——就叫 Allen——时间上没法和你们一样灵活。Allen 是一名丧偶的父亲,得承担小孩的监护工作。Allen 必须每天 5:15 到幼儿园去接孩子。可以想象,周末两天是他唯一能够和儿子在一起的时间,没法改变。

“呀,也没啥问题,”你想,“我们可以理解 Allen,大家互相体谅。”一开始,大家都能这样做……

几个月后,除你之外的其他人开始不满了。你们所有的星期六都排满了,甚至大部分星期天也这样。你开始了 60 小时以上的周工作时间,远远超出了你的想象,而且你的老婆孩子都开始抱怨了。你的脏衣服成堆,各种账单未付,休假计划也泡汤了。这么久了,Allen 仍然还是每周工作 40 小时。最后,终于有人说出了你们心里所想的:“我厌倦了总是要帮 Allen 干活。”

发生了什么?一个高效运行的有凝聚力的团队就这样被不统一的加班政策给土崩瓦解了。而在好的团队里,每个人从来就没有统一过,更不可能让他们从个人生活中“借”时间的能力上统一。在任何 4 个、5 个或者 6 个人的团队里,一定会有几个人不能承受在其他人看来很灵活的加班时间。过去的加班仅仅是几次晚班或者偶尔一天的周末,大家都能够咬咬牙。但如果加班延长到几个月,即便是最为精诚团结的团队成员也要受到影响时,就一定会对团队的凝聚力造成破坏。不能够分捏痛苦的人会一点点被其他人疏远。团队的魔力也将随风而逝。

毫无疑问,延长加班时间就是一项减产的实践。额外几个小时的产出总会被之后的副作用抵消,即使不考虑它对团队的破坏也是一样。只是当你考虑到团队成员不同的加班能力会破坏团队凝聚力的时候,这一点就更具说服力。

大多数管理者对加班是否有帮助还是心存怀疑的,通过如此多的加班加点来完成项目,很难证明他们的管理技巧和能力。但最后他们还是允许或者鼓励加班的。为什么呢?作为一名顾问兼作者,Jerry Weinberg 给出了这样的答案:他认为我们并非是要通过加班来完成工作,而是希望能够在工作根本无法按时完成时通过加班来避免指责。

上一页23 团队自毁下一页25 竞争

最后更新于5个月前

这有帮助吗?