《精益产品开发》读后感

1. 前言

本书的书名已经很清晰地表明了其所要介绍和探讨的问题。

职业生涯里一直都待在传统软件企业里"技术人员"，不断重复的残酷现实让我从原本一名死扣细节的唯技术崇拜者，逐渐过渡为更加关注全局研发效能的"管理"人员。

作为一名以"解决问题"自居的职场人士，我的个人经验是传统软件行业技术工作者的职业生涯之路的一大选项正是"抛开狭隘的技术视野，将目光着眼整体的研发流程，持续找出并解决导致流程缓慢的问题"，这样的职业生涯才能走得远，走得稳。正如我在走出软件作坊 - 文集 - 简书中反复论证的 —— 传统软件行业的技术痛点中，先进性的占比并不高；相较之下，整体研发流程的规范化和高效，这一赛道更长，成功的机率也更大。

自2018年正式在部门里提出DEVOPS改良以来，过去的这些年在该领域的理论和实践经验积累一直也是未敢停下，但是必须承认的是尤其最近几年里，已经很少会完整系统性得阅读该领域的相关著作了。

与本书的结缘源自偶然拜读的两篇作者文章阿里如何定义团队的研发效能？-阿里云开发者社区和阿里如何提升团队的研发效能？-阿里云开发者社区，文章所展示出来的作者在该领域的思考深度让人神往，于是理所当然的这本书就有了一读的理由。

2. 全书印象

相较于我过去这些年所一直关注的DEV+OPS领域，作者在这本书中所描述的流程更为全面，堪称完整版。而且正如书名已经揭示的，本书更关注的全局业务价值的交付，我所专注的DEVOPS只能算是其中的一个环节。

全书二十五个章节，分为精益产品开发的原则，方法和实施三大部分，完全覆盖了精益产品开发的整体脉络。如果你刚刚迈入这个领域，直接从这本书入手会让你省下不少弯路。

3. 部分摘抄

3.1 反摩尔定律

"如果我们18个月后卖出的产品和今天相同，那么得到的收入只能是今天的一半。" —— 反摩尔定律

这个定律所要达标的意思很清晰 —— 价值交付越快（早），其价格越高。

如何更快（早）地交付价值，则正是敏捷产品开发的业务目标之一。

注意这里的"更快"并不是绝对速度的快，而是指时间上的早，即通过迭代交付实现分批和更早交付。

3.2 敏捷的业务目标

打造组织更早地交付价值和更灵活地应对变化的能力。

3.3 端到端

这里的端到端是指从用户的问题到交付用户解决方案。

在敏捷推进过程中，需要统一的一大共识就是对于"完成"的定义，经常出现的一个情况就是你问哪个环节都会被告知已经做完了，但实际上这个功能就是不能正常运行。

3.4 流动效率

相较于关注资源使用率的资源效率，敏捷要求我们关注更为根本性的内容 —— 流动效率。从用户的角度，审视用户价值顺畅流动的程度。

3.5 可视化

可视化价值流动是看板方法的第一个实践，也是其他几个实践的基础，必不可少的基础。

如现在持续火热的"可观测性"概念，流程的可视化与系统内部的可观测性一样，其程度越高，问题的暴露速度就越快，解决的成本也就越低，流程或系统的成熟度也就会越高。

3.6 部署 VS 发布

部署是发布的必要条件，而非充分条件。

部署是技术决策 —— 功能开发和验收完毕就可以部署；而发布则是业务决策 —— 业务需要时才发布。

把两者混在一起，就会相互牵扯。

1. 想要更持续地部署，却受业务约束及决策地拖累；
2. 而业务上更灵活发布，也受制于部署能力。

3.7 有效的反馈

有效的反馈应该符合以下三个原则：

1. 方便获取。保证反馈的即时和真实。
2. 易于理解。反馈的含义应该一目了然。
3. 与目标相关。明确反馈是用来干什么的，怎么帮助达成目标。

3.8 资源效率 VS 流动效率

传统软件开发方法，通常都着眼于各个资源和环节，把提高资源效率作为主要目标和改进点，但是各个环节过度局部优化，往往可能形成效率竖井，进而伤及整体的效率。

我们必须将焦点从内部资源环节，转移到用户价值之上，关注用户价值在组织中的顺畅流动。精益产品开发的实施是以流动效率为核心，带动交付能力的全面均衡和可持续提升。

3.9 产品开发中的质量模型

我们需要将质量区分为内部质量和外部质量。

1. 内部质量着眼于产品内部，如代码质量和测试覆盖率。内部质量是质量的根本。
2. 外部质量着眼于产品外观表现，如功能和性能。用户和业务方真正关心的是产品的外部质量，也就是用起来怎么样，是否符合要求。

内部质量决定外部质量，外部质量反映内部质量。

1. 外部质量的长期改进必须通过提高内部质量才能实现。
2. 内部质量的提升必须要有针对性，而外部质量是找到关键内部质量问题的重要线索。
3. 改进的效果最终体现在产品的外部质量上，它是检验质量改进效果的标准。

3.10 内建质量

向开发，而非最后的验证环节要质量：

1. 测试不能提高产品的内部质量。测试能够保障的只有外部质量。
2. 开发移交质量差，测试的质量也会随之变差。糟糕的移交质量，会造成测试等待和反复，压缩测试的实践。
3. 依赖测试发现缺陷再去修复是低效的。开发人员更早地发现问题，还能带来如下好处：
   a. 即时发现设计和其他错误，避免在错误的基础上累积更多的错误。
   b. 及时的修复更加干净，对内部质量的破坏更小。
   c. 快速地从自己的错误中学习，有助于人员水平和意识的提高，避免将来再出现类似的问题。

3.11 领导力的四个特质

1. 专业能力。这是基础。
2. 系统思考能力。能够从全局出发分析问题和采取决策。
3. 影响力。在没有行政权威的情况下影响他人。
4. 勇于担当和决策，并为结果负责。

3.12 DEVOPS所关注的四个指标

1. 变更前置时间（Lead Time for Changes）。
2. 发布频率（Release Frequency）。
3. 服务恢复时长（Time to Restore Service）。
4. 变更失败率（Change Fail Rate）。

这四个指标起到的作用：

1. 快速让IT团队各个角色形成一致的理解，全局指标带来全局的优化，并驱动卓越能力的改进。
2. DEVOPS实施后，通过指标可以更好地和非技术角色沟通，术语简单一致。

3.13 垃圾进，垃圾出（Garbage In，Garbage Out）

这句名言被作者在整本书的不同章节中反复引用，可见其作为口头禅在作者的日常工作中的频率。

作者拿这句话名言主要是为了说明作为源头的需求应该认真对待，围绕需求理解上的共识，需求的独立部署发布能力等等都是需要认真对待并实施的。

4. 相关

1. 走出软件作坊 - 文集 - 简书 (jianshu.com)
2. “能够高效地自我复制”是传统软件行业公司中高级人才认定的关键