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

01 此时此刻,一个项目正在走向失败

自计算机被广泛使用以来,编写出了数以万计的应收账款程序(Accounts Receivable Program)。当你正在阅读这些文字时,可能又有数十个或者更多的应收账款程序即将完成。然而,此时此刻,一个项目正在走向失败!

想象一下!一个没有真正技术创新的项目正在滑向失败的深渊。应收账款程序不过是一个“重复发明的轮子”,经验老到的开发人员面对这样的项目总能驾轻就熟。即便如此,有时在项目中付出的努力却南辕北辙,最终将项目推向失败。假设其中一个走向崩溃的项目结束,并邀请你前往会诊。(当然,这事儿永远不会发生,我们这个行业自有一条金科玉律来阻止我们分析失败。)

现在假设在所有参与者寻觅到各自的借口之前,你有机会分析到底什么地方出现了差错:自然,你不会将项目遭遇覆顶之灾归因于技术。就当前的技术发展来看,在技术上完全可以实现应收账款系统。一定存在其他因素造成了失败。

在人件(peopleware)项目的第一个十年中,我们对开发项目及其结果进行了调研。我们评估了项目的大小、成本、缺陷、加速因素以及项目工期的成败。最终,我们统计了 500 多个项目的历史,它们都来自开发一线的项目数据。

统计结果表明有 15%的项目出现问题:项目取消、终止、延迟或者交付的产品从未被使用。项目越大,出现问题的几率就越高。对于持续时间达到 25 个工作年及以上的项目,足有 25%的项目最后宣告失败。在早期分析中,我们舍弃了这些失败项目的数据,而对其他项目进行了分析。但自 1979 年以来,我们一直努力联系项目上可以找到的人员,期望发现究竟是哪里出现了问题。我们研究的绝大多数失败项目中,没有一个是因单纯的技术问题导致失败的。

游戏的名称

“政治”( politics)是被访问者最常提及的失败原因。但这个词经常被人们习惯性地含混使用。在“政治”这个词语下,包含着诸多不相关联或松散关联的东西,如交流问题、人员安排问题、与上级或客户关系不和、缺乏动力、高离职率等。人们经常用政治来描述所有与人相关的工作,但语言学对这些内容提供了更为准确的描述:它们构成了项目的社会学。真正的政治问题不过是这些病态特征的冰山一角而已。

倘若你认为一个问题属于政治的范畴,你会宿命般地逆来顺受。我们总是能直面技术的挑战,然而垣率地讲,我们又有几人能自信地面对政治这个圈子呢?认识到问题真正的本质分属社会学的范畴,而与政治无关,能帮助我们面对问题时更游刃有余。项目及团队社会学或许超出了你的专业范畴,却没有超出你的能力之外。

不管你怎么命名这些与人相关的问题,它们都比所有的设计、实现及方法论问题更有可能在下一个项目中给你制造麻烦。事实上,本书的基本论调都是基于这个想法:

我们工作中的问题更多属于社会学范畴,而非技术范畴。

大多数管理者坦承:他们对人的担心更甚于对技术的担心。

但他们很少以此种方式去管理?他们的管理方式总是视技术为主要关注点。他们总是越俎代庖,将大量时间耗费在本该由团队解决的复杂而又有趣的难题上,就好像他们是自己完成工作,而非进行管理。他们总是在寻求某种技术银弹(technical whizbang),以期让工作实现自动化(参见第 6 章)。在他们的职责中,最重要的与人相关的要素却被放到了最低优先级。

滋生这种现象的部分原因来自于管理者的提拔机制。对新晋管理者的训练是如何完成一项工作,而不是如何管理它。很少有公司会考察新晋管理者在工作中是否展示出相应的能力与良好的心态来胜任管理工作。他们缺乏管理径验,也没有具体的实践。那么,新晋管理者又是如何自我说服应该花更多的时间考虑问题的技术因素而非人的因素的呢?

高科技的幻觉

问题的症结或许在于高科技的幻觉:广为人知的理论认为凡是接触新技术的人(我们谁不是呢?)就被想当然地看做属于高科技领域。在鸡尾酒会上,当人们畅谈自己就职“计算机行业”、“电讯行业”或者“在线电子交易行业”时,很容易沉溺于这种假象中,认为他们自己就是高科技世界的一部分。在我们看来,他们通常都不是。只有在上面那些领域从事基础研究、获得根本突破的科研人员才是高科技工作者,其他人只是在运用他们的研究成果。我们使用计算机和其他技术来开发我们的产品或者帮助组织我们的事务。由于我们以团队、项目或者其他紧密协作工作小组的形式来完成工作,我们大多数人是在从事人类交流的职业。我们的成功源自于所有参与者良好的人与人之间的互动,我们的失败则归因于这种互动的缺失。

我们习惯性地专注于工作中的技术问题,主因并非它们重要,而是因为它们更简单。安装一块新的硬盘,比寻思为何 Horace 显得忧郁而恐慌,Susan 人职几个月就对公司不满要容易得多。人与人之间的互动非常复杂,没有简单规律可循,但在工作中它的确更为重要。

倘若你发现自己更加关注技术问题而非社会问题,那你就像是一名杂耍演员,在一条雷黑的街道丢失了钥匙,却逡巡至邻近的街道去寻找,并美其名日:“那里的灯光更明亮。”

上一页第一部分 管理人力资源下一页02 干酪汉堡,做一个,卖一个

最后更新于5个月前

这有帮助吗?