🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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. 第一部分 管理人力资源

05 再谈帕金森定律

英国作家诺斯古德·帕金森(C.Northcote Parkinson)于 1954 年引入了一个概念,认为工作会自动膨胀,占满一个人可以用的所有时间,这被称为帕金森定律。

倘若你不知道其实很少有管理者接受过管理方面的正规培训,你可能会错以为他们都是科班出身,在学校就学过帕金森定律及其分支理论。即使管理者对管理一无所知,他们也极为认同帕金森定律这一针对员工及其态度进行管理的公理。定律为他们提供了强有力的证据,只有设定不可能完成的交付日期,才能保证工作的完成。

帕金森定律和牛顿定律

帕金森定律离公理还差得远呢。牛顿定律才是公理,从这个角度看,帕金森定律显然不是。牛顿是一位科学家,他对重力的研究遵循了一系列严格的科学方法。定律的提出经过了严格的验证和测试,并且通过了接下来几个世纪的后续研究。

帕金森不是一名科学家,他没有收集数据,甚至可能根本就不知道什么是统计推论规则。帕金森是一位喜剧作家,他的“定律”被接受并非因为它是真理,而是因为它有趣。

当然,帕金森定律还是有真实成分的,要不然就不会那么有趣了。帕金森说,他的定律是通过观察一个虚拟的政府官僚机构得出的,一些人认为原型就是英国邮局。

官僚机构很容易产生这样的问题,因为员工很少从工作中收获满足感。但你很可能不在官僚机构工作,就算你在,你可能也花了不少力气保证你的员工不这么做,否则他们不会有任何产出。结果就是大家都可能从工作中得到莫大满足。因此,一个简单的事实值得澄清:

帕金森定律基本不可能运用到你的工作中

生命苦短,不能在工作中虚度光阴。只要大家热爱工作,就不可能让一项工作变得遥遥无绝期——这会推迟获得他们向往的满足感。在不需要降低标准、牺牲质量的时候,他们和你一样,期望工作能快点完成。

如果经历了我们的见闻,你就不会这样说了

每一位管理者在职业生涯中一定会遇到一个员工不想工作,或者完全达不到质量标准,又或者无法完成工作。对此,帕金森定律管用吗?

在一个健康的工作环境里,要是某人表现欠佳,可能是因为能力不足、缺乏自信,或者无法理解项目中别人的想法和项目目标。通过增加进度压力无助于解决上述问题。一旦某位员工表现出工作低效,对工作质量漠不关心,就是发出了明确的信号,说明这个可怜的家伙快被工作困难给压垮了。他需要的不是更多的压力,而是调换工作,或者跳槽到另一家公司。

即使在极端情况下,依靠某人是唯一的出路,管理者也应该将此作为最后的选择。团队发出的声音会更好,我们见证了一些良好团队的管理者和大家站在一起,共同批评那些不与别人协作的员工。

在随后的几章中,我们会就团队以及怎样促进团队良好的化学反应展开讨论。这里,我们不会讨论什么方法有效,而是讨论什么方法无效:把你的团队成员当做帕金森型的员工是不可能奏效的。这只能消磨他们的意志,让他们失去前进的动力。

来自新南威尔士大学的数据

当然,帕金森定律的思维观念并不会因为它不应该存在而消失。要帮助管理者认识到帕金森定律并不适用于大多数员工,方法是通过严格收集得到的数据。(且不提帕金森本人并没有提供任何数据来支撑他的定律,仅仅是花了几百页内容来阐述观点。)

两位备受尊敬昀新南威尔士大学研究员——迈克·劳伦斯和罗斯·杰斐逊在上个世纪 80 年代和 90 年代进行了年度调查。他们按照通行的数据收集标准对正在进行的项目进行了度量。每一年,他们会专注于不同的项目工作方向。1985 年的数据调查结果显示:帕金森定律并不具备普适性。虽然结果不能完全推翻定律,但至少提供了足够的理由来质疑。

劳伦斯和杰斐逊设定的目标是比较各种估算方法给产能带来的影响。他们想证明(或推翻)大众认为的开发人员(调查对象是程序员)会更加努力工作去达成他们自己给出的估算。对他们调研的 103 个项目中的每个项目,劳伦斯和杰斐逊计算出了一个产能的加权度量值( weighted metric)。然后他们将项目按照原始的估算方法进行归类。部分结果参见表 5-1。

表 5-1 估算方法的对应产能(部分结果)

工作量估算人
平均产能
项目个数

仅程序员

8.0

19

仅管理人员

6.6

3

程序员和管理人员

7.8

16

至少结果证明了大众的观点:相比管理人员的估算,程序员自己给出估算对应的产能会高一点。若二者一起做估算,对应的产能结果处于二者之间。

在同一年调研的 21 个项目中,估算由第三方完成,通常为系统分析师。在这种情况下,程序员的产能持续高于前面提到的由程序员或簪理人员来做估算(见表 5-2)。

表 5-2 估算方法的对应产能(部分结果)

工作量估算人
平均产能
项目个数

仅程序员

8.0

19

仅管理人员

6.6

23

程序员和管理人员

7.8

16

系统分析师

9.5

21

最后一条数据出乎意料,未能证实大众的想法。为什么程序员要更努力工作去达成分析师给出的估算,甚至超过他们自己给出的估算呢?可能我们会觉得这是收集的数据不够准确造成的。但如果你跟我们一样,相信不准确的估算是伤害士气的一个原因,那么其实这些数据并不需要过多解释。系统分析师其实是比程序员或管理人员更好的估算者,他们既了解工作的细节,又不会陷入构建者那种自然的乐观或者老板们通常在政治或经济方面的偏执中。另外,系统分析师通常会有更多的估算经验,因为他们过去做过,而且从中吸取了经验教训,因而能够估算得更加准确。

不准确的估算,或者根本不现实的估算会消磨掉构建者的精力。Capers Jones,以他对开发项目度量的研究成果著名,他这样说道:“当一个项目的时间计划制定得根本毫无道理或不现实,甚至不可能通过加班来达成时,项目团队会变得愤怒和烦躁……他们的士气会跌到谷底。”这种“根本毫无道理或不现实”的计划不管来自于老板还是构建者自己部没啥区别。既然明知不可取胜,人们自然就不会高效地工作了。

在 1985 年劳伦斯一杰斐逊的研究报告中,最后一部分让人尤为吃惊。他们调查的 24 个没有做估算的项目在产能方面远比其他项目强(见表 5-3):

表 5-3 估算方法的对应产能(全部结果)

工作量估算人
平均产能
项目个数

仅程序员

8.0

19

仅管理人员

6.6

23

程序员和管理人员

7 8

16

系统分析师

9.5

21

(没有评估)

12 0

24

老板不给任何时间压力(“你们做完了告诉我一声就行。”)的项目产能最高。当然,这并不能说明帕金森定律不适用于程序员,但应该足以让你产生怀疑了吧?

是否在一个项目上采取时间进度压力,应该像是否惩罚你的孩子一样来决定:如果惩罚比较少见,而时间点也能够掌握得恰到好处,惩罚就可能起作用:若需要经常施以惩罚,就说明你自身是有问题的。

帕金森主题的变异

只要让帕金森定律变异一点,就能在很多组织中造成惊人的事实:

一个组织的工作如果都忙忙碌碌,就会膨胀以至于占满整个工作日:

在一家公司刚成立时,这种现象就开始了,随着时间的推移问题会变得越来越严重。倘若荷兰东印度公司(1651 年成立时最大的公司)仍然存在,他们的员工可能会花一周 40 小时的时间来填各种表格。大家注意,在这种情况下,帕金森式的行为在于公司而非员工。在第二部分,我们会再讨论这个主题。

上一页04 质量——如果时间允许下一页06 苦杏素

最后更新于5个月前

这有帮助吗?