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

32 终极管理罪恶得主是……

终极的管理罪恶是浪费大家的时间。听起来这像是一种可以轻易避免的罪恶,但事实却并非如此。作为管理者,你有一些你自己的诉求,这些诉求会让你做出的事情与合理利用你手下员工的时间相悖。

举例说明

你组织了一个员工会议,自己却姗姗来迟(可能你不得不接老板打来的一个紧急电话),于是其他人就只能干等着。或者,你自己中途出去接一个重要的客户电话,然后会议就失去了关注点。或者是,你召集了一个会议,但显然会议明显是在耽误大家的时间(可能除了你自己之外,这是很多仪式型会议的典型特征)。

当你召集一个多人会议时,正常的假设是所有与会人员都聚在同一间屋子里,因为他们需要通过互动来达成某些结论。但当所有的参会人员轮流与一位关键角色互动时,这种召集一帮人开会的合理假设就不存在了;还不如单个找下属交流,而无须强制其他人参与。

我们在上面提及的可能是老板的需求得到了满足,或许要花费下属们的一些时间。但这是不对的吗?难道这不是老板为了保持控制而不得不做的吗?对于管理和协调复杂的工作来说,难道这不是合理的吗?答案模棱两可。传达状态并不需要开这样的会议;有很多更节省的办法可以做到。老板的需求并非获得信息,而是再确认。仪式就满足了这种再确认的要求。让每个人清楚老板就是老板,他来组织会议,员工参会是按预期进行,层级关系是要被尊重的。

项目状态会议只关于状态

召开一次真正的工作会议,原因是需要所有被邀请的人一起来处理某种问题。会议的目的是达成一致。这样的会议在定义上就一定具有临时性。随之带来的就是这种会议不太可能遵循常规计划。如此推理,任何常规规划的聚会更多的可能是出于仪式目的,而要多过专注于达成一致性的目标。周例会就是一个典型的例子:看起来例会的目的是报告状态,但实际上真正的目的是状态的确认,并且不是针对工作状态,而是老板的状态。

当老板特别关注时,这些如仪式般造成负担的状态更新会议可能发展到无法控制的地步。比如,我们就知道一个组织每天都要召开两个小时的状态更新会议。如果参会者在会议期间木在办公室,就要求他们电话接入全程参加。缺席会议被认为是违纪,会受到严重的惩罚。

早期超编

会议并非是唯一浪费大家时间的地方。当过多的人在项目初期就加入时,基本上总是会浪费大家的时间:同样的道理,你可能会认为这很容易避免:简单计算一下这项工作能够多快接纳新人;然后加入的速度按照计划不就成了二理论上这没有问题,可因为各种原因通常不具备可操作性。

项目开始于计划与设计,这些活动最好由小团队来完成。当设计很重要时(除了那种简单的公式型项目,设计都很重要),可能需要占到整个项目周期的一半。图 32-1 的人力规划可能是合理的。

图 32-1 看起来奇怪,但可能很合理

一个两年的项目,大部分成员半年到一年后才能上项目:但这又怎样呢?这样的人力规划有点不同寻常,但如果这是合乎现实的,为什么不能这样计划呢?

当项目迫于紧张的时间压力下时,这一问题就凸显出来了——哪个项目不是如此呢?如果客户和高层管理下达了命令,例如只给了这项工作一年时间,这个限制就会缩短项目预期的结束时间(见图 32-2)。

图 32-2 进度紧张的项目(终止的人员安排)

很自然的,一种倾向就是把因为缩短时间而压缩的人力投入放到前期去。好了,这个项目就变成咱们熟悉的早期超编的典型了(见图 32-3)。

图 32-3 早期超编以满足最终期限

当然,如果你知道早期投入人力完全就是浪费,你不会那样做,对吗?好吧,或许你还是会这么做。你可能推断出了无论项目上怎么投入,要完成这样一个冒进的计划都是不可能的。要是你知道项目无论如何都会延期,那么在高层倾向于在项目早期多投入的情况下,你最好考虑一下如果不再添加额外人手是显得更好,还是更糟。就算早期投入最后被浪费掉,比起你想着要在前六个月按需精益投入,让大家早点上项目可能更安全。如果早期人员配备不足——失望的高层管理肯定会这么看——会让你看起来像个业余选手。

因为这种因素而造成项目早期超编,这种情况普遍吗?嗯,不太普遍,也就只有不超过 90%的项目存在这种情况吧。

评价这种在研发组织常见的文化现象确实让人失望,尽管谈论了许多“至精至简”的思想,对于一个项目管理者而言,在项目关键分析和设计活动中按需以精益的方式加人,在策略上仍然是不安全的。

再说碎片化

当大家的时间都浪费在不必要的会议和早期的超编时,他们都心知肚明。他们会变得沮丧,却又清楚其原因。如果这种浪费至无可收拾,他们可能也会让你知道。所以,这个问题虽然严峻,但至少还是看得见的。然而,还有一种对时间的浪费却很可能是无法察觉的,因而没法改进。这跟我们在第 23 章中提到的碎片化有关。这里的重点在于脑力劳动者的时间被多个同时进行的任务碎片化,这种碎片化必然导致此人会工作在不同小组里,而这样的工作组是不可能凝聚成真正团队的。

时间碎片化几乎都会带来团队自毁,除此之外,还会带来另外一个潜在的副作用:必然会浪费个人的时间。一个同时兼具多项任务的员工——一部分新的开发工作、一些遗留系统的维护工作、售前支持或者用户见面会安排——每天必然会花费一部分时间用在工作准备上。这些时间根本就看不到。这位员工可能把正在进行的设计工作放下,花费 20 分钟通过电话引导一个来电者重新配置公司早期产品的数据库,然后又回到设计工作上。如果你拿着一个计时器站在他身后,你可能不会发现任何时间浪费。浪费悄悄地隐藏在此人第二次设计工作的缓慢起步上,这是打断工作流的直接后果。

当两项任务需要的工作习惯本质上不相同时,碎片化尤为有害。所以将设计工作(需要一个较长的导人时间、相对安静的环境以及与小组高质量的互动)和电话支持工作(需要不停的打断、可持续的服务和快速的注意力转移)混杂在一起,会让思考密集型的任务基本无法开展。特续重启造成的时间浪费只会让员工感到沮丧。你可能从没听谁提起,因为受这样问题困扰的员工可能更多是在自责。

尊重你自己的投资

出于某种原因,在过去几十年里,我的咨询工作需要越来越多地到欧洲出差。我开始乘坐白天从波士顿到伦敦的航班,对我这样时差适应能力很差的人来说影响可以小一点。不幸的是,从波士顿出发到大多数欧洲国家的首都都只有夜晚航班。我不停抱怨这个问题,直到有一位航空公司的工作人员给我指出:航空公司并不是太愿意投入 747 这样的大型客机在这样的航线上,因为飞机在地面等待的时间,完全可以完成从东海岸到西海岸,再从西海岸返回东海岸的日航了。毕竟,747 可是要烧很多钱啊。 -TDM

你投入到工作中的人力资本也代表了不少钱。如果你所在的公司雇用了几千名脑力劳动者,那么在这方面的投资几乎可以看做是一架现代的宽体机。在如此巨大的投资上浪费时间,等于直接把钱冲到下水道里。

上一页3l 会议、独白和交流下一页33 “邪恶”电邮

最后更新于5个月前

这有帮助吗?