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

3l 会议、独白和交流

一些组织开会开到上瘾,以至于把工作放到了第二位。他们组织会议没啥目的性,也没明确定义什么是会议结束。一些组织则会走另一个极端,害怕会议浪费时间,以至于他们谈“会”色变,这当然也不对。对待会议不偏不倚才是合理的。

神经硬化

随着一个组织的老化,会议时间逐渐增多,到组织弥留阶段,就只剩下开会了。至少现实看起来就是这样。这自然是事出有因,出发点往往也是好的,但效果却适得其反,甚至有机会让竞争对手在远处悄悄偷笑呢。当任何行动的参与方人数增加时,会议就会变得越来越流行。会议可以带来更多的信息透明,这对任何想在层级森严的大公司升职的人来说都是非常重要的因素。别人对你的关注不在于你听得多仔细,所以,为了信息透明来参会的人更多会寻求发言机会:最糟糕的会议就像是一堆空谈者的集会,没有人听别人说什么,每个人都只顾着表达自己的意见或者等着表达。因为有这么多人需要发言,会议时间自然被拖长到不受控制了。

当每个人都痛惜这样的会议占去太多时间时,很多管理者却借口这类事情是不可避免的:不可避免是因为组织正在尝试完成复杂度巨大的事情。复杂度巨大这个提法当然是让每个人都感觉能够接受,因而,一旦这成了会议的正当理由,就没有人会去思考另外一种可能:竞争性的空谈。

“科技手段增强”的会议

现在进入了科技时代。先辈们面对这些糟糕会议时常常无处可逃,我们却有了自己的手提电脑。当会议变得无聊时我们可以打开电脑……唉,这可能还不够明智——更好的是在开始会议时就打开电脑,这样至少不是在哈利站起来讲话时,让他知道我们都走神了。

所以,那些无聊的会议时间就是处理收件箱里无数邮件,或者偷看几页 Facebook 网页,或者给同在会议室里坐对面那个可怜家伙发条短信的好机会。说不定还能完成点真正的工作……

现在,我们已经了解到科技增强能够给你的好处,随之而来的一个问题是:它给会议本身带来了什么呢?让会议更好,对吗?更有效、更快捷?得了吧,我们要严肃点!当然可能有这么一个时刻,一个管理者说:“你们开着电脑的人,上网去查查我们(至少是他提到的)的市场今年有多大,未来的趋势预测如何。”这可能发生,但不会很额繁 j 对应这一次对会议相关信息的查询,可能有上千次是与会议完全无关的。

这就是冲突之所在:在会议上广泛使用的科技对召开会议一点用处没有;这些科技仅仅是为参会的人们逃离毫无意义的会议提供了便利。科技增强带来了会议的沉闷可怕,我们现在的会议比前辈们的还要糟糕,因为前辈们不需要忍受这样的会议——他们可能早就站起来抗议了。

现在能够接受的行为,放到过去可能会让你被解雇。

站立会议

比较新的方式是站立会议,一般是在一个空地方(没有桌子椅子)让所有人都站着。理论依据是站着会让大家都不太舒服,所以不太可能空谈。我们觉得有道理,但带着批判的眼光,我们觉得最大的收益还是在站会上没有地方放电脑,所以大家都没法玩电脑。不管出于什么原因,这样的会议会精短一些,因而大有裨益。

即便是这样的站立会议,如果没有目标和主题也会拖组织效率的后腿。那么,会议的目标和主题应该是什么呢?这就取决于会议的种类了。

基本的健康会议

为完成一件事情而专门组织的会议可以称为工作会议。(我们假设其他会议为非工作会议,下节再细讲。)举办一次典型的工作会议就是为了要达成一个决议。需要谁参会呢?很简单,那些对决议点头的人。其他人就不需要了。为了保证大家都不会茫然,工作会议都需要一个相关的日程安排,有明确的目标并且能够执行。这样可以保证即使不参会的人也能知道会议安排,不在日程上的话题是不会被讨论的。没人需要带着防御心理去参会。

工作会议有一个吸引人的特质,你们知道会议何时完成。一旦达成决定,就不需要继续开会了;当决定没有达成时,会议就还没完。

反之也是一样:如果你们能够确定结束会议的条件,那么这就是一个工作会议;否则就不是。

要是你将上述理论运用到你的下一个会议上,你基本可以断定它不是一次工作会议。不是的原因是没有集体的互动来结束会议:结束会议是因为时间。现在 10 点了,会议该结束了。

仪式

迫于时间而结束的会议是一种仪式。这种会议的目的不是达成某个特定的决议,都是 FYI(for your information,仅供参考)。这种 FYI 通常都是在特定礼仪下开展的:老板进行快速介绍和宣布,然后就是老板和下属的一系列一对一交流。在任何时刻,就只有两个人在交流,其他人名义上都基本在听,当然是名义上的。如果他们有手提电脑开着,那他们的关注点都在其他地方。

仪式是一系列的对话,对话本身是件好事。不好的是那些并没有真正倾听的人被关在了对话发生的屋子里。那些相信这样的会议应该被对话取代的人,很容易观察到这样的一对一可以在其他地方发生,从而放开其他人让他们去做真正的工作。

工作环境中不时会有真正需要这样仪式的时候。仪式可能是庆祝某次成功、给大家讲解战略方向的改变,或者评估一个即将结束的项目。这些正当的仪式都有些不同寻常之处,这些不同寻常之处也是为什么正当的原因。常见仪式的一个例子是每周(每天!)的项目状态会。会上,十几二十个人被锁在一间屋子里轮流向老板汇报工作。

太多参与者

工作会议的参与者仅局限于利益相关的人,人数越少越好。仪式会议的参与者就没有限制了,只要负责人认为有价值参加的人都可以来,人数多一点更好。会议发起者的重要性直接决定了参与者的数量,当然谁都希望搞大一点。

“开放式组织”的幻想让情况更糟糕:

我的一个新客户,表面看来是一家充满生机的新兴技术创业公司,也许会成为下一代的苹果。可是内在却大相径庭。我被邀请参加他们的会议,每一个管理者都出席了。我一开始还以为他们的出席是因为我的到来,还感到有点受宠若惊。但接下来几天的会议都一样:所有管理者都参加了。在这些会议上(不管名义上的主题是什么),总会发生的一件事就是讨论将人员从一个项目调整到另一个项目。没有管理者敢缺席会议,害怕自己的人被拿走。他们为自己开大会找的借口是他们是开放式组织。真正的原因其实是大家都是防御性的被动参与者。 -TDM

下面是一个简单的数学计算,但值得一说:会议的成本直接取决于参会人员的多少。我们有一个客户是苹果的一名管理者,每次在开会前都会让一个人离场。她允许那个离场员工在离开前进行简短的陈词。她清楚地告诉大家选择的标准并不是这个员工相应的能力,而是他用会议时间可以完成工作的重要性。真正从释放一名员工身上得到的收益并不大,但这种行为传递的信号却不可或缺。

开放空间社交

如果你曾经参加过专业的会议或演讲会,你很可能得出和其他人一样的结论:会议和演讲都是烦琐的事物,真正的价值体验在那些间隙时间,一段演讲开始或结束等待的公共区、茶歇休息、午餐排队、与其他参会者一起饮茶或聚餐的时间。基于这些事实,一些有思想的人开始形成“开放空间”的想法。一次开放空间的会议完全就是茶歇和午餐。当然事实会比这要复杂一些,但你知道我们想要表达的。那些会议上没有正式的演讲,完全只是在社交。

同样的想法可以用在会议计划上。作为一名新人职员工,你在组织里的开放空间会议上的体验大致是这样的:你接到老板通知,员工会议在周五早晨 9 点钟召开。你 8 点半就出现了,泡了一杯咖啡,然后坐到一个新人旁边,开始聊你们昨天未完的话题。有人加入到你们的对话中,互相做了介绍。她了解到你被分配的领域,然后告诉你她在那个领域的经验。

这时,老板进屋了,你晃到他面前报道。他给你介绍了一位和你被分配项目使用相同硬件的员工。你俩交换了邮件地址,约定当天中午一起吃工作餐细聊。你偶然听到旁边在聊一个让你一直很着迷的话题,你凑过去想听仔细,又担心在你这个陌生人加入后大家不聊了。大家并没有这样,而是欢迎你加入,给你介绍他们之前在聊的事情。

现在,9 点过了好一会儿,怛会议还是没有正式开始?你去自助餐桌那里又泡了一杯咖啡,遇到一位来自支撑团队的人,和他聊了聊。最后,9 点 20 分,老板拍掌引起大家注意,然后说:“今天很不错,谢谢大家来参加。下周同一时间这里见啦。”然后他离开了……

这就是你第一次参加开放空间会议的经历。没有真正的会议,只是一个长时间的间隙。

治愈会议上瘾组织的处方

你改变不了你的上级,但你可以改变你的地盘,还有那些和你一起工作的同事和下属。这种改变总是知易行难。你的目标是消灭大多数仪式性的会议,而将时间花在一对一的交流上,通过运用“会议怎样才算结束?”的测试来限制每次参与工作会议的人数。要是需要什么仪式,则鼓励大家用开放空间社交来创造非结构化的自发互动。最重要的是,削减你自己需要用仪式会议来做确认的需求。

上一页30 与风险共舞下一页32 终极管理罪恶得主是……

最后更新于6个月前

这有帮助吗?