🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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. 第二部分 办公环境

间奏曲:生产效率度量和不明飞行物

下面的间奏曲是我们严肃讨论(哦,是的,真是非常的严肃)之间不多的一次小小跑题。

我们为什么不能直接度量在好与坏的工作环境下的生产效率,从而找到环境和工作效率之间的关系呢?这种方法对流水线可能适用,但如果我们要度量的工作更加偏重于脑力劳动,就不那么明显了。对脑力劳动者生产效率进行的度量已经背上了软科学的名声。在一些人的脑子里,这仅仅比研究不明飞行物好一点儿。

设计一项实验来测试工作环境对生产效率的影响足够简单:

  • 度量在新工作环境中完成的工作总量。

  • 度量工作带来的花销。

  • 比较在新旧环境中完成工作的总量和工作花销:

设计很简单,但实施起来却很困难:比如,你怎么计算一个市场调查、一个新电路设计或者贷款新政策设计的工作总量?可能有一些逐渐形成的标准(软件开发就是这样),但还是需要大量的本地数据收集,并建立内部的专业能力。大部分组织根本就不会尝试对脑力型工作的数量进行度量,他们也不能有效地度量开支。

在一个组织中,可能提供了花费在一个问题上的总小时数统计,却没有包含对其中有效小时数(第 10 章中会更多讨论)的统计。所以,就算一些组织可以在新环境中度量工作总量和总的开支,他们也没有数据来做对比。唉,管理者可能会就这个问题深耕细耙,然后得出结论,说生产效率的分类超出了我们可以理解的范围。不过,事实还没这么糟糕。

吉尔布定律

有一年,我在伦敦软件工程国际会议上和汤姆·吉尔布聊了一下午,他是《软件度量》和其他十几篇关于开发流程度量论文的作者。我发现只要说有些事情“不可度量”,就很容易让他激动起来。这种想法对他就是一种冒犯。让我印象深刻的是他关于度量基础真理的描述。在那时看来,这一想法如此明智而令人鼓舞。我甚至逐字逐句地将它们抄到我的日记中,并命名为吉尔布定律。

你想要量化的任何东西都能够以某种程度度量,至少聊胜于无。

吉尔布定律并没有保证度量免费或便宜,而且可能度量也不是完全准确——但总比没有度量好。 -TDM

当然,对生产效率进行度量是可能的。如果你召集一组人员做同样或者相似的工作,而且给他们一天时间找到一种合理的自度量体系,他们一定可以产生一些东西来印证吉尔布定律。然后,度量出的数字可以帮助他们调整自己的表现,结合质量体系或者同行评审机制,就能建立互相学习的方法。计算出来的该小组的平均值可以给管理层一个可靠的指标来度量改进办公环境这一参数带来的影响。

在我们最了解的软件制造业,有很多有效的生产效率度量体系:甚至还有很多服务能够到现场评估你的生产效率,并告诉你在同行业里处于什么位置。如果一个组织不能评估自己的生产效率,只能说还没有努力尝试。

但是,不知你可否接受

假设现在就有一个简单且验证充分的生产效率度量工具,而且已被大家用到日常工作中。如果度量者进来告诉你,你的团队的生产效率在同行业中名列前 5%,你一定非常开心。你的脸上堆满了神秘的笑容,来回在走廊上徘徊,心里温柔地想着你的员工:“我原来就觉得大家很不错,这条消息实在太棒了。”

哇,糟糕。度量者一会儿又跑了回来,告诉你他们把图拿反了,那是一个错误的结果,其实你的团队是行业的最后 5%。现在,你这一墼天都给毁了。你心里想,“我早就该知道。这帮像火鸡一样的家伙,还能指望他们能完成什么像样的工作?”一开始你还沾沾自喜,转眼就变得失望沮丧。然而,无论是哪一种情形,你都不应该过于惊讶,因为你自己对什么是生产效率其实也是稀里糊涂的。

由于组织之间的表现可以有十比一的差距,你不可能忽略你当前所处的位置。如果你不知道,你就不可能做出任何改变。若是只有市场了解,自然会有一些让你不舒服的外力来纠正存在的问题。

闭上你的眼睛去度量

工作度量可以是很有效的方法改进、员工激励以及增加工作满意度的工具,但却从来没有被用在这些方面。度量体系往往会变成对大家的威胁,反而增加大家的负担。

为了能够让度量这个理念发挥应有的潜力,管理层必须足够主动和安全地把自己从这个圈子里摘出去。这就意味着个人的数据不会被传递到管理层手里,而且组织中每个人都心知肚明,收集的个人表现数据只能用于个人提升。度量体系就是自评估的一个练习,只有处理过的平均值才会交给老板看。

对于很多管理者而言,这很难理解。他们会说这样的数据可以帮助他们的工作更有效率(比如准确地提拔员工或者甚至准确地炒掉某人)。他们的公司付费去收集这些数据,为什么却不能看到数据呢?然而,要做到准确地收集这种个人敏感数据,就需要个人的积极配合并且是有意愿的合作。如果数据的保密性被破坏,如果数据被用来对付哪怕一个个体,整个数据收集体系就会即刻停滞。

员工会倾向性地针对数据做管理者们相同的事情。他们会尝试去改善做得不好的事情,或者尝试在他们擅长的领域精益求精。极端情况下,一名员工可能会自己“炒掉”自己,从而不再依赖于他们缺乏的技能。管理者因此并不需要真正看到个体数据,以期获得收益。

上一页09 在空间上省钱下一页10 大脑时问与身体时间

最后更新于5个月前

这有帮助吗?