🍊
翻译橙
🍊返回主站🤖参与贡献
  • 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. 第三部分 正确的人

20 人力资本

此时此刻,就在你读这些文字的时候,离你不远的地方可能就有一台暖气或空调正在运行,使用电力或者燃料改变着周围的温度让你感到舒适。这些都会带来成本。公司每月都要付钱,把这笔钱作为水电费用记账。让我们假设 9 月的账单是 100 美金。公司付了这笔钱,而且公司没有任何其他的财务交易:没有收入,没有工资支出,什么都没有,只有这笔水电费。到月末时,这个组织的盈亏报告应该像图 20-1 这样。

图 20-1 第一个月的盈亏报告

报告显示本月为亏损,显然花销大于了收入。

下个月的变化还是有点缓慢。公司仍然没有收入,没有工资支出。但天气变暖了 9,是一个完美的 10 月,只需打开窗户,用不上暖气了。所以没有水电费的支出。当然你还是写了一张支票:你花 100 美金买了一台掌上型电脑。你在支票上写上“计算机设备”,因为这是在你的会计手册里明显最合适的支出项。到 10 月底,你的盈亏报告如图 20-2 所示。

上个月,你的一张 100 美金的支票造成了盈亏表为负数。而这个月,你的一张同样的 100 美金的支票却让收支持平。为什么会不同呢?这种不同只可能是由于你选择的支出项不同而造成的。9 月,水电费的选项被作为了花销;而 10 月,计算机设备的选择却被区别对待。你的会计把计算机设备作为另外一种资产,就好像在不同银行的存款一样。所以你 10 月的支票就像从一个银行到另外一个银行的转账,当然就不会对盈亏产生任何影响了。

花销是指一笔钱被花掉了。到月底,你的钱花了,暖气也用了(或者其他的花销)。另一方面,投资则是用一种资产去购买另外一种资产。价值并没有被使用,只是从一种形式转换成了另外一种。当你在支出项中选择投资而不是花销时,你就在对这笔支出进行资本化。

对人来说呢?

那么公司花在人身上的钱怎么计算呢?通行的会计准则是将所有工资作为花销,不会作为资本投资。有些时候这是合理的,但有些时候却不然。对于直接产出产品的员工来说,只要产品卖出了怎么计算都没有关系:不管你是记入花销还是投资,付给员工的工钱最后会从产品交易的价格中扣除来计算收益。这样记录人力花销跟记录保暖的供热费一样直接;不管是人力还是暖气,到月底都花光消失了。

但是,假设你送同样的一名员工去参加一周的培训。他的工资和培训费用被花在了一些到月底也不会“消失”的事情上。他学到的东西在接下来的时间里还是在他的脑子里。如果你能够聪明地使用培训经费,那就是一笔投资,而且很可能是非常有价值的一笔:但根据会计惯例,这就是一笔花费。

谁在意这些?

真正有意义的并不在于如何为 IRS 或者投资人提供报告,而是管理者如何看待在员工身上投资的这笔钱:人力资本可能很可观;如果错误地把这样的投资看成是花费,很可能会让管理者放弃组织在这方面有价值的投资。

“放弃组织在这方面有价值的投资”,当然是管理缺陷的显著标签二很多公司都会经历中上层管理者牺牲长期利益而在短期表现(比如季度收益)上比拼的阶段:这经常会被称为“底线意识”,但我们更愿意叫它:“吃老本”。

衡量人力资本投资

你的公司在你和你的同事身上投资了多少?一个简单的度量方法是考虑如果你离开公司,会发生什么:假设贵公司的数据库专家路易丝决定月底要离开公司。在这之前,你对自己的 5 人团队在明年夏天交付公司新一代的订单管理系统感到乐观。工作推进得很平稳,团队能力很强并且效率很高。至少这是在路易丝扔出这个重磅炸弹之前的情况:现在看来就难说了,这简直是一场灾难。你打给人事部一个电话,告诉他们这个坏消息。“路易丝决定 31 号离开,”你报告说,然后充满希望地要求,“能给我们找到另外一个路易丝吗?”

不幸的是,人事部没有像路易丝那样有技术、懂业务、经验丰富的专家。“拉尔夫怎么样?”有人向你建议。你从未听说过拉尔夫,但现在看来也没什么其他选择了,你只有接受。事情搞定,路易丝 31 号离开,拉尔夫在次日加入。

表面看来项目没受任何影响,31 号你有 5 个人,下个月 l 号还是 5 个人。如果拉尔夫和路易丝工资一样,那么公司就尽职地用同样的价格购买了工时,团队也得到了完整的 5 个人月的安排,就好像路易丝留下来了一样。如果项目上个月是按计划进行的,那么现在也应该按计划进行。那你还有什么感到闹心的呢?

让我们先来看看拉尔夫在公司的第一天是怎样度过的吧。路易丝走后,仍然留下不少数据库柏关的工作;拉尔夫第一天能够干掉多少呢?答案当然是什么都做不了。拉尔夫当然不会只坐在那里。他花了一天处理他的健康保险、学会怎么订午餐、领取他的办公用品、配置好他的电脑及网络。他的原始产出是零。呀,可能还是负数!如果他占用了别人的工作时间——这个当然你也知道,他总是需要问一些基本问题的——这个时候他对团队的贡献就是负数了。

第一天就这样了;第二天呢?第二天可能稍微好点。拉尔夫现在全身心投入了,学习路易丝留给他的资料。当然,如果路易丝留下来,这些工作是不必要的,她早知道这些知识了。(如果不是因为要离开,她也不需要写这些资料。)拉尔夫的产出效率仍然远低于路易丝。他可能还是负贡献,因为他很可能还是需要其他团队人员的帮助。对于团队来说如果拉尔夫不来他们是不需要花这些时间去支持的。

渐渐地,你的团队新成员拉尔夫完全跟上了节奏,达到跟路易丝差不多的产出效率。现实的数据库开发职位上手时间跟图 20-3 相似。

图 20-3 人员变更导致的生产效率降低

生产效率在路易丝离开后受到很大打击,甚至于有段时间到了零以下,因为团队其他人慌忙去填补一个完全融入团队的成员离开带来的工作缺口。然后,经过一段时间,团队最后又回到了原来所在的生产效率水平:

图中阴影区域是因为路易丝离开导致的产出(没有完成的工作)损失:或者,从另外一个角度来看,这是公司在拉尔夫身上的投资,为了让他能够达到路易丝的技能及能力水平所做的投资。

根据组织为这些无产出时间付出的费用,我们可以计算出阴影区域的货币数值。如果拉尔夫需要 6 个月才能赶上,且他的进步是线性的,那么投资大概是总时间的一半——也就是 3 个人月的工时。这笔投资的货币数值就是公司付给拉尔夫的工资加上这三个月中的其他花销。

新人上手需要多长时间?

6 个月从一个负产出者到达前任的产出效率?这对一个新进的软件应用开发人员来说是比较合理的,但如果对稍微复杂一些的工作,可能就远远不够了:当我们要求客户团队为新人的上手时间给出一个数字时,大多数团队给出了远大于 6 个月的评估。我们的一位客户,开发网络协议分析及数据包分析,给出高达 2 年的新人上手时间。这个客户只雇用对底层技术有扎实理解的技术人员,所以 2 年的额外时问就是去学习专项的领域知识,以及融人到团队里。因此,为一个新员工的初始资本投入大概需要 20 万美金。

假设有新一轮的“精兵简政”的裁员,公司决定要裁掉这样一名员工。当然,花在这名员工身上的工资及其他花费会被节省下来,但这 20 万美金的投资就完全泡汤了。如果公司考虑到这个因素,或许就知道公司承担不起将这样有价值的人力资源解雇的后果了。

玩华尔街的游戏

每年的裁员、减产、缩减组织或收缩规模,华尔街对此都表示欢迎,就好像这样的撤退才是最终的目的。值得指出的是情况并非如此:

这种措施的目的是增员,而不是减员。

减员的公司都坦诚他们的上层管理玩砸了。

但华尔街仍然为之雀跃,为什么呢?部分原因是账面上好看。千把人就这么缩减了,他们挣来的每一分钱直接就成了公司的保底收入,至少看上去是这样的。分析时容易被忽略的是对这些人的投资——这可是真金白银投入的,如今就这样被看做毫无价值而扔出窗外。

要改变华尔街把用在人上的投资当成开销的计算方法,可能希望渺茫。但长此以往,这样玩游戏的公司一定会吃亏。反之亦然:有意识地主动管理这项投资的公司一定会得到长线回报。依靠脑力劳动者的公司必须认识到他们在人力资本上的投资是至关重要的。好的公司早就这样干了!

上一页19 在这儿很开心下一页第四部分 高效团队养成

最后更新于6个月前

这有帮助吗?