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

04 质量——如果时间允许

20 世纪的心理学理论指出,人类的特征被一系列基本天性控制:生存、繁衍、领地等。这些都是直接植入我们脑子里的。你可以不带任何情绪理性地分析这些本能(正是你现在做的),但当你感知到它们的时候,总是会带有浓厚的感情色彩。即使对于这些内在的价值观仅有一点小的挑战也会让人感觉失望。

任何强烈的情绪表达都显示了大脑中的原始价值观受到了威胁。一个新手管理者也许会相信工作可以在不掺杂个人情绪的情况下完成,但只要管理者具备一点点经验,就会知道事与愿违。我们的工作给了我们表达自己情绪的很多机会。

你想想,总有一次某人的情绪完全因为工作相关的事情而被煽动起来。好好思考这件事,然后反问自己(可能是第 n 次了),情绪从何而来?若对这件事的背景一无所知,我打赌,它一定是威胁自信的一大成因。在个人生活中,造成情绪化反应的因素可能很多,然而在工作环境中,主要的导火索就是对自信的威胁。

我们通常倾向于将我们的自信与生产出的产品质量(并非产品数量)紧紧关联。(因为某些原因,生产出大量质量马虎的产品带来的满足感很小,尽管在某些情况下需要这么做。)采取任何可能牺牲产品质量的行动都可能挑起员工反对你的情绪。

飞离卓越的航班

管理人员设定的不可达到的期限威胁着产品的质量,但他们不会这样去思考这一问题——他们自认为给了团队一个有趣的挑战,可以激发他们去追求卓越。

有经验的员工(老油条)却不这么想。他们知道,在枪口下,他们的任何努力都是受到约束的。不能自由调配资源,以满足准时交付的要求。要想增加更多的人,或者减少功能?没门!只有质量是可以降低标准的。当员工处于极度的时间压力之下时,质量就开始被牺牲了。他们会把问题藏到脚垫下面,或者直接扔给产品的最终用户。他们交付的产品是不稳定、不完整的。他们会讨厌自己做的事情,但能有什么选择呢?

一些死板现实的管理者会这样回答上述问题:“我们一些同志会为了‘质量’在一个任务上无休无止,但市场才不管你什么质量呢——昨天就赶着要这个产品了,即使质量粗糙也行。”多数情况下,你对市场的判断或许正确,但通过施压让大家制造出达不到自己质量标准的产品终归是错误的。

我们这些管理者总是认为质量只是产品的另外一个特性,可以视市场的需求而调整。就像你涂在自制蛋糕上的巧克力酱:想要多点就多涂点,想要少点就少涂点。

然而,产品制造者对待质量却完全不同。因为他们的自信来自于产品质量,所以会有自己的一套质量标准。对他们而言,要让自己满意,最低标准就是要达到过去做到的最好质量。这当然要比市场要求并愿意为之付出的标准更高。

“但市场才不管你什么质量呢。”读到这句话真让人唏嘘落泪,只因事实确实如此。人们可能会大谈对质量的重视,抱怨质量的缺失,但真到了要为质量买单时,他们真正的价值观就露出真面目了。拿一个软件项目为例,你可能对用户解释说:“根据经验证据我们推断,产品目前的故障平均间隔时间( MTBF)为 1.2 小时。要是我们今天就交付,产品会非常不稳定。如果再多花三周时间,预计 MTBF 会增加到大约 2000 小时,这可是一个非常棒的结果。”然后就看到用户开始支支吾吾,含糊其辞。他们会说质量真的太 重要了,但三周时间可是真金白银啊。

说到软件,这个行业已经让客户接受了自主开发的应用程序平均 100 行代码就有 l ~ 3 个缺陷!极具讽刺意味的是,这样灾难性的纪录常被归咎于制造者缺乏对质量的认知。而且,一旦质量降低,那些祓责怪做事修修补补永无止境的员工就成了质量问题的罪人。还是让我们把这样的责备转到别处吧!花钱的人说了算,他们已经定下了低质量的基调:把开发流程经常性地置于极度压力下,同时又接受低质量的产品,软件用户群体展现了“真正”的质量标准。

上面所说的一切听起来像是在贬低软件用户或者市场上的通用标准,但事实上我们无须如此。我们需要假定:为我们工作买单的人对质量和成本之间的关系有一个清醒的认知。这里明确的一点是,客户想象的产品质量往往比制造者认为的要低。这是一个天然的冲突。降低产品质量可能会让一些人不再购买,即使靠降低成本来提升单个产品的利润,也无法抵消由于质量下降带来的市场占有率的降低。

让买方而不是制造者来设定质量标准,即我们所谓的飞离卓越的航班。如果我们忽略对制造者的态度及效能带来的影响,那么让市场来产生标准也许是可以接受的。

长远来看,以市场为基础制定的质量标准花销更大。即

质量,远远不只是最终用户的要求,而是达到高产能的一种方法。

如果你对这点有疑问,想象一下下面的试验:到大街上随便找 100 个人,问他们认为谁是以高质量著称的组织、文化或者国家。估计一半的人会告诉你是“日本”?我们再问另外 100 个人:什么组织、文化或者国家以高效能著称?同样,大多数人还是会说“日本”:这个国家在作为质量领袖的同时,也以高产能著称:

等等,高质量恁么可能和高产能并存呢?按常规理论,若要提高产品质量,就必然需要在生产过程中花费更多。为了找到答案,让我们一起来看看两位最受尊敬的评论家田岛(Tajima)和松原(Matsubara)对日本现象的解释:

价格和质量的对立在日本并不存在;相反,高质量带来成本的降低却是被广泛接受的想法:

质量是免费的,但是……

菲利普·克劳士贝( Philip Crosby)在他 1979 年出版的《质量免费》一书中阐述了同样的道理。在这本书中,克劳士贝给出了很多案例及理论分析来论证:让制造者来设定他们自己满意的质量标准,会带来生产效率的提高,从而抵消为提高质量而产生的额外成本。

很抱歉,我们认为克劳士贝的著作给行业带来的弊大于利。问题在于多数管理者只听说过书的标题,却没有读过这本书。标题完全以偏概全。随处可见管理者热情地宣扬质量:“只有天空才是质量的上限,我们提升质量是免费的!”这根本不可能形成正面的质量意识,这种态度恰恰是克劳士贝倡导的反面。

关于质量和生产效率之间的关系,需要用一种不同的表达方式来传达信息:

只有愿为质量倾其所有的人,质量才是免费的:

一个组织,如果为了质量一毛不拔,那么收获的质量也将会一文不值。“质量——如果时间允许”这种策略会导致产品不会有任何质量可言:

很早之前,惠普就被认为是一个通过制造者自定义高质量标准而提升生产效率获益的典型组织了。从一开始,惠普就信奉质量。在这种环境下,需要更多时间或资金来生产高质量产品的说法压根儿就没有出现过。因此,开发人员形成的文化是交付的质量要超越市场的质量要求。他们追求质量的标志成为提高他们工作满意度的动因,从而拥有行业内最低的人员流失率。

否决的力量

在一些日本企业,如典型的日立软件和富士的部分团队,项目团队拥有否决发布被认为是未成熟产品的权利。即使客户愿意接受不满足标准的产品,团队仍然可以坚持己见,直到产品质量达标才交付。当然,项目管理者与前面提及的管理者存在同样的压力:他们必须尽快交付。但重视质量的文化由来已久,所以日本的这些管理者知道不能哄骗他们的员工去接受质量上的缺陷。

你能够给予你的团队成员否决交付的权利吗?当然,要迈出第一步需要钢铁一般坚韧的神经。你面临的原则问题在于,帕金森定律会与你做对。这个话题值碍我们用一章来讨论。

上一页03 维也纳在等你下一页05 再谈帕金森定律

最后更新于5个月前

这有帮助吗?