🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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 提供支持
在本页
  • 忆往昔
  • 公司内垃圾邮件
  • “FYI”到底啥意思?
  • 是开放型组织,还是公社?
  • 撤销被动的同意
  • 建立一个少垃圾邮件、自我协调的组织

这有帮助吗?

在GitHub上编辑
  1. 人件
  2. 第五部分 沃土

33 “邪恶”电邮

是啊,你的电子邮件收件箱满了,很了不起呀,但里面都是些什么啊?

忆往昔

在电子邮件出现之前,我们通过书信和远方的人沟通。一封书信需要听写、记录、打字、校订、重新打字,最后寄出,这整个算下来在过去可以抵得上好几百块,折算成今天的价格,可能会更多。投递还需要三天到一周的时间。收到信的一边又需要花额外的几百块钱,花上三天到一周的时间来回信。今天,我们完成同样的双向沟通,仅仅需要百分之一的花销和千分之一的时间。但是,我们确实受益了吗?收益是落到了我们口袋里,还是让我们的沟通增加了百倍?

你知道答案。我们协调沟通的花销比以往任何时候都高。

我在加拿大有一位叫 Diane 的客户,她在家和工作地之间单程需要 2 个小时。我对此深表同情,但她告诉我说这没什么。“这是加拿大,”她说,“在铁路上我们都有很好的无线网络服务。我用黑莓手机。我在来公司和回家的途中处理我的邮件。” -TDM

好吧,每天 4 个小时的邮件,而且还假设她在工作时间不看邮件,当然你知道她肯定是要看的。

我们都变得习惯于海量的协调沟通邮件。是时候问一个关键问题了:这样做真的好吗?

一个家庭治疗学家会告诉你:双边关系中的一方如果过度表现,另一方就一定会表现不足。当两兄弟中的一个跳起来擦桌子洗碗的时候,你一定会看到另一个悄悄溜去玩了。这会发生在你的组织里面吗?当你过度地和那些为你工作的人沟通协调时,他们自己就可能沟通协调不足。同事之间的自组织与相互协调才是良好团队协作的重要表现。

瞧瞧篮球或冰球里的快速突破,想象一下如果每次传球都必须由场边教练发信号,会是什么样子。

一个好的教练知道自己的工作不是去协调队员的互动,而是帮助大家进行自组织。我们认为这同样是一位脑力劳动管理者的工作。如果你同意这个观点,那么大部分邮件就是问题的一部分,而非解决方案。

公司内垃圾邮件

在被恶意垃圾邮件骚扰了几十年后,大部分组织都知道如何有效过滤掉垃圾,保证员工不收到外来的垃圾邮件。这是你的网络支持小组做出的不小贡献,但他们没有真正解决这个问题,因为在你们的收件箱里,大部分垃圾邮件都来自于同事。当然,你可能不习惯把这些邮件看作垃圾,但它们大部分就是。任何发给一个同事却抄送多于半打人的邮件都可能是垃圾。直接发送对象可能需要看到,但其他抄送的人呢?你收到邮件是因为你需要采取行动,还是仅仅给你 FYI?

一个简单的测试企业内部垃圾邮件的方法是采用安全组织的思考方式。当安全至为关键时,信息传播应根据需要进行筛选。试想,如果捋一捋今天的邮件,思考每一封邮件,“我需要知道吗?”有多少封邮件能够通过测试?那些你不需要知道的可能是某种内部税务事宜,占用了你和你同事的时间。所以,我们很多人永远在疑惑:为什么一天忙碌下来却没有完成任何工作。

“FYI”到底啥意思?

你花时间阅读的那些没有通过需要测试的邮件可以推测是为了 FYI(仅供参考)。但如果你都不需要知道,这信息对你又有什么价值呢?

把你加为抄送人的发件人当时在想什么呢?有很多可能,很多并不值得我们赞赏:

  • “如果我不多抄送些人,谁知道我在工作啊?”

  • “我不敢不发啊,因为如果发生什么事情大家会抱怨为什么他们不知道。”

  • “这是一个开放的组织,所以每个人应该看到所有事情。”

  • “我希望大家都看看我是多么好的一个写手。”

这些都是组织出现问题的表现。如果大家无论发什么都不敢不抄送给你,可能就是你自己出问题了。你传递了什么样的信息,让大家心照不宣地认为必须把每条消息都抄送给你?

是开放型组织,还是公社?

“开放型组织”听起来让人觉得有丝丝暖意。它暗示大家都为自己的工作感到自豪,而且很乐意别人看到自己的工作。我们都希望跟这样的团体一起工作,但我们需要更理性:大家允许你通过拉动的方式了解他们做的工作是好的;但如果大家用推送的方式把所有信息都给你,这就不好了。我们的观点是:

人生短暂,如果你需要知道所有才能工作,你可能走不了多远

撤销被动的同意

组织里陷入一种泥潭,人人都要花时间进行无休止的邮件处理。个中原因乃是一条不成文规定。规定是:

沉默等于同意。

如果一个人发邮件给你建议做些古怪的事情,你又没有反对,根据这条规定就等于你同意这样干。如果你发现自己每天花费大量时间在阅读没有价值的东西时,很可能就是因为你在被抄送人员里,担心被视为默认。

要把你自己和其他人从这样的苦海中解救出来,你需要撤销这样的规则。我们不知道你组织的具体情况,因而不可能给出具体建议。但这是值得做的,有效的撤销——确立只有显式同意才算同意——能够节省你组织中的人员足足一个世纪的时间浪费。

建立一个少垃圾邮件、自我协调的组织

你也许不能改变整个公司,但你能够改变与你共事的同事及下属的工作方式。就从明确企业内部垃圾邮件不受欢迎开始。我们的一个客户甚至建立了一个邮件过滤器(以一种礼貌的方式)来拒绝那些将他的地址放在抄送列表,或有太多收件人的邮件。他属于公司高层,所以不用担心一不小心得罪了上面的某位:每个为他工作的人马上接受了教训,他们不仅不再发给他企业内部垃圾邮件,还停止了给其他人发:

不仅要测试收到的邮件是否需要知道,对于你希望发出的邮件也要做同样的测试。每次当你想要发一封协调邮件给你的同事或为你工作的员工时,考虑一下你需要让这个人变得自我协调的步骤。别以为这很简单。告诉一个人该做什么确实简单,但让这个人逐渐形成自我协调的能力,那就太复杂了。但是从长远看,这种努力是会得到回报的。如果你为这件事情已经苦恼困惑很久,那得记住:这正是你身居高位的原因。

上一页32 终极管理罪恶得主是……下一页34 让改变成为可能

最后更新于5个月前

这有帮助吗?