本章内容概要
- 使用A3问题解决法推进你的APIOps改进
- 绘制API交付流程图并识别浪费
- 领导你的APIOps转型
在第1章中，我介绍了APIOps的概念，并讨论了其原则与优势。在本书后续章节中，我将深入讲解具体的软件工具和实践，帮助你改善API开发流程。但在深入探讨API工作流自动化工具之前，有几个关键问题需要回答：虽然本书介绍的API工具可能宣传了许多优势，但你如何确认它们真的能改善API交付流程？引入自动化是一回事，但如何验证自动化确实提升了端到端的API交付性能？你希望达到的关键结果是，通过APIOps引入的任何API工作流自动化，都能帮助你快速交付更有价值、高质量、且客户能够轻松集成和使用的API。企业也必须看到自动化带来的成本降低，并在可能的情况下提升收入。除此之外，还必须考虑推动流程改进时的文化因素：你的同事和相关团队会如何看待这场变革？
为回答这些问题，我将介绍一些精益思想（Lean Thinking）的理念。精益是一种持续改进的管理方法，旨在用更少的资源为客户创造更多价值，并减少生产过程中产生的浪费。本章将演示如何利用A3问题解决表单，将精益思想应用于API交付流程的改进。A3问题解决表单最初由丰田汽车开发，是一种结构化、迭代式的问题解决与流程改进方法，能够促进与同事的达成共识，并高效记录改进中的学习成果。其名称来源于丰田员工用来记录和展示问题解决报告的A3尺寸纸张（297 × 420 毫米）。在制作A3表单的过程中，我还会教你如何使用价值流图（Value Stream Mapping, VSM）技术和符号来绘制API交付流程图。价值流图是一种可视化工作流和生产流程耗时的工具，起源于丰田的物料与信息流图。
章节后半部分，我将讨论API交付流程中可能存在的各种浪费类型，并提供如何引入和维持变革以推进APIOps转型的建议。本章重点是概念工具，帮助你分析适合你的自动化方案，促进组织内部达成一致并推动变革系统化推进。本章不涉及编码，你需要的不是IDE或文本编辑器，而是一支尖锐的铅笔、一块橡皮和几张白纸。本章内容尤其适合API产品经理、产品负责人以及希望在组织内推动APIOps改进的相关岗位人员。
2.1 你公司的API质量与交付周期问题
设想你的公司"Acme宠物用品有限公司"陷入危机。Acme快速搭建了多个RESTful API供平台使用，但现在不断收到客户关于API文档缺陷的投诉。客户抱怨API参考文档（由Acme的OpenAPI定义文件生成）质量低劣，部分RESTful API设计混乱且不一致。为解决这一问题，Acme成立了API网关团队，负责审核API变更并通过API网关对外提供API服务。网关团队发现Acme多个团队生产的API未遵循公司API风格指南。因此，该团队强制要求所有团队采用设计优先（design-first）方法，并提交设计变更供人工审核，确保符合风格指南。尽管这提升了质量，内部团队抱怨设计与审核过程耗时过长，拖慢了API交付节奏。
为破解这一难题，Acme领导层设立了一个企业目标，既要提升API质量，也要缩短设计审核时间。你的经理选中了你来牵头这项工作。你将如何开展？这类因危机催生的企业目标，是启动APIOps的绝佳契机。解决API文档和设计问题的企业或部门级目标，是启动APIOps的良好背景，因为APIOps旨在缓解API高质量与快速交付之间的矛盾。为了启动APIOps讨论和改进项目，你可以利用A3表单将问题可视化、理清思路，并制定对策。
2.2 用A3方法推动APIOps改进
A3报告是一种直观且迭代的问题解决方法，强调与同事持续对话。它是一页纸的报告，基于计划-执行-检查-行动（PDSA）循环（后文详述），比起冗长的文字报告或大量幻灯片，更简洁地讲述问题解决过程。A3报告没有固定格式，会根据目标和受众有所变化，但本书采用的格式包含以下几个部分：
- 主题 --- 说明你想要改进的内容标题。
- 背景 --- 描述问题的业务背景和组织目标，突出问题的重要性。
- 现状与问题陈述 --- 描述问题及其表现形式。
- 目标陈述 --- 明确期望达成的结果。
- 根本原因分析 --- 展示如何识别出潜在的根本原因。
- 对策与目标状态 --- 提出纠正措施和预期的目标状态。
- 效果确认 --- 提供数据以确认所采取对策达到预期效果。
- 后续行动 --- 描述将成功对策标准化并推广的计划，以及与其他组织单元共享经验教训的安排。
这些部分在图2.1的A3模板中有示意，箭头展示了填写A3表单的顺序。
我们回到第1.1节的场景。假设你的经理让你准备一份关于提升Acme API一致性并缩短设计评审时间的A3报告。你会从哪里开始呢？接下来的内容将带你一步步完成这份A3报告。因此，请准备好制作A3报告所需的工具------一支铅笔、卷笔刀、橡皮和一张A3尺寸的纸。虽然现在Lucidchart、Miro、diagrams.net等数字绘图工具很流行，你可能会第一时间想到用它们，但这些工具有个风险，就是你可能会花太多时间去制作"完美"的图表。制作A3是一个迭代过程，需要反复思考、讨论和草绘，你会对草图做很多修改。用铅笔和纸先画草稿，而不是用图形软件，可以帮助你快速启动，集中精力解决A3所体现的重要问题，而不是花时间去做一个数字上完美的图表。等你完成第一版草稿，准备与同事和经理分享、进行更广泛的讨论和协作时，再制作数字版即可。
不同类型的A3报告
如前所述，大多数A3问题解决报告在形式和风格上相似，但并无统一标准格式。关键是A3报告能帮助你以计划-执行-检查-行动（PDCA）循环结构化思考，并有效向目标受众传达你的想法。想深入了解A3报告及其在精益制造中的应用，可参考John Shook的《Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead》（Lean Enterprise Institute，2008年）。
同样重要的是，要注意A3报告有不同类型。我在图2.1中展示的是用于问题解决的A3报告，但A3报告也可用于提出方案和提供状态更新，这时结构可能不同。关于A3报告的更多类型，可参考Durward Sobek和Art Smalley合著的《Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System》（CRC Press，2008年）。
2.3 主题与背景
A3报告的主题即你想要改进的内容标题。它应让读者对报告讨论的变革有整体认识，并描述该改进所要解决的问题。撰写A3报告时，首先在顶部写明主题。本例中可写为"提升API一致性并缩短API设计评审周期"。
除了主题，读者还需要知道谁负责解决该问题。问题负责人既对结果负责，也对实现结果的过程负责。既然经理指定你负责该问题的解决方案，请在报告上写上你的名字。
另外，顶部部分还应注明日期。随着你获取新信息并推进问题解决过程，会频繁修改A3报告。更新最新草稿的日期，有助于读者区分新旧版本。请填写主题、你的名字和日期，如图2.2所示。
请注意，主题部分不要将问题归因于某个原因，也不要预设解决方案。A3报告的目标之一是帮助你调查并发现潜在的根本问题。在这个阶段，主题应告诉读者你希望进行的变革或改进的性质。对于问题解决类的A3报告，我通常建议主题开头使用"提升"、"增加"、"减少"、"简化"等词语。
接下来是A3报告的背景部分。当你的繁忙经理阅读这份报告时，如何提醒他/她解决这个问题的重要性呢？利用背景部分提供业务背景，并将问题与公司或部门的目标联系起来。（为此，你需要了解组织的季度或年度目标。）此外，还应提供与问题相关的历史情况。尽可能用图示、表格或项目符号的方式呈现信息。Acme案例的背景部分示例见图2.3。
背景部分应针对受众进行调整，说明为何需要进行改进，并传达紧迫感。使用项目符号和图表能够简洁地传递信息，吸引读者注意。在这些场景中，图像往往比文字更有表达力。可以考虑使用柱状图、饼图、直方图、趋势线、时间轴和帕累托图来说明观点。
2.4 当前状况与问题陈述
你已经向经理提供了问题的背景，接下来要关注问题本身。以Acme的案例为例，假设客户提出API改进请求，由API产品负责人接收。工程师设计API后，将设计提交给API网关团队进行审核和批准。网关团队每周召开两次会议，审查各开发团队的API设计。如果需要修改，会要求工程师进行调整，之后设计才获批准。这个过程对开发团队来说太慢，导致无法按时完成客户承诺。以上是高层次的描述。那么，如何用数据和确凿事实帮助经理和A3报告的读者深入理解问题细节及其表现形式呢？
利用A3报告的"当前状况与问题陈述"部分，用一两句话定义问题，并展示问题体现的现行流程。提供经过验证的事实和数据，说明问题持续的时间及发生频率。获取信息和深入理解问题及其表现的最佳方法是亲自观察问题。这一点非常重要。亲自观察问题和流程是解决问题的重要环节。精益管理专业人士称之为"去现场"（Going to the gemba）或"现场走访"（gemba walk），其中"gemba"是日语，意指"实际发生工作地点"。例如，在Acme案例中，你可以这样观察流程：
- 采访同事，了解他们在流程中遇到的问题及阻碍。
- 请求同事允许你观察他们工作，了解问题如何表现。例如，如果他们在电脑上完成任务，陪同观察屏幕操作；如果远程工作，要求共享屏幕或录制屏幕。
- 记录他们使用的工具及工作方式，同时留意未使用的工具。例如，如果公司有API风格指南或推荐的API设计工具，观察同事是否真正使用。
- 参加流程中关键会议，观察重要任务的执行或问题的讨论。以Acme为例，参加API评审会议。
- 研究缺陷工单、事件工单或其他反映问题表现的文档。
观察时不要提出建议或改进意见，重点是通过问"为什么"、"什么时候"、"谁"、"什么"、"如何"等问题理解流程，记录信息。
提示：理想情况下，应进行三到四次观察，获取每个步骤指标的平均值。
工作流程由多个步骤组成。改善流程（如Acme的API设计与评审流程）时，有两个重要维度：
- 整体流程耗时，取决于各步骤耗时（忽略并行步骤）。
- 流程产出质量，是各步骤产出质量的累积结果。
以下是观察过程中应收集的重要指标：
- 任务时间（Task Time, TT） ：专注执行任务所需的时间，假设所有信息和依赖都已就绪，且同事无中断。包括思考、阅读和讨论理解任务所需时间。不包括排队等待或任务开始后的中断时间。又称"过程时间"或"触碰时间"。
- 前置时间（Lead Time, LT） ：从工作开始阶段可用，到该阶段完成并交给下一环节的时间，包括等待信息和中断的时间。换言之，包含排队等待和延迟时间。TT与LT的区别见图2.4。LT也称"吞吐时间"。
- 完成且准确百分比（% Complete and Accurate, %CA） ：上游流程传入的任务中，有多少百分比是无缺陷、无需补充信息或依赖即可直接处理的。即可直接使用的任务占比，是衡量流程输出质量的指标。可通过询问该流程阶段的同事获得，例如API评审人员可能报告他们仅80%的评审任务信息是齐全的。
- 在制品库存（Work-in-Process, WIP） ：待处理的任务或工单数量。以Acme为例，指等待评审的API评审工单积压。注意工作是否被批量处理，比如评审频率为每周两次，或任务积累到一定数量后才处理。
此外，还可收集其他关键数据，如因该问题产生的缺陷工单数量、问题发生的频率（Acme案例中，是否存在某些时间段评审延迟更严重？）、流程不同阶段涉及的同事人数等。
你已经与参与流程的同事进行了讨论，核实了问题的事实，并收集了展示问题表现的重要数据。但如何在你的A3报告中高效呈现这些内容，使你的经理能够快速理解问题，而不必一行行阅读你的详细发现呢？
利用你在现场观察（gemba）中获得的见解和数据，用可视化方式描述问题。你可以使用之前提到的图表来说明问题：柱状图、饼图、帕累托图等等。
提示 ：帕累托图是可视化问题发生频率的好方法。该柱状图能帮助聚焦对影响最大的少数关键原因或问题。本书不深入讨论帕累托图，感兴趣可访问 asq.org/quality-res... 了解更多。
绘制流程图，展示你为每个步骤收集的指标数据。你可以使用各种业务流程建模技术，但我推荐使用价值流图（Value Stream Mapping，VSM）的方法和符号，应用于流程级别。如前所述，VSM是一种用于可视化和分析满足客户需求所涉及活动序列的技术，展示工作流和信息流。VSM通常用于宏观层面，展示组织中多个高层流程如何为产品或产品族增加价值。然而，你也可以通过调整和应用VSM技术及符号，创建低层次的流程图，接下来会演示具体方法。
2.4.1 创建工作流程步骤
首先在图的顶部显示提出请求的客户和主要流程步骤。以Acme案例为例，客户是内部的------一位提出API设计变更请求的产品经理。使用客户图标将客户放在图纸顶部。（我使用的VSM图标定义见附录A。）
接下来，用流程步骤图标绘制主要步骤。（如果流程步骤存在变异，绘制大约80%情况下实际执行的步骤。这样可聚焦改进重点，避免被细节干扰。）
在流程步骤图标上方写明流程名称（建议用动词+名词格式，如"设计API操作"）。在图标下方写明执行该步骤的团队或角色。用推送箭头连接各流程步骤，表示工作从一步流向下一步。
图2.5展示了Acme案例中的示意图。
2.4.2 绘制信息流
识别价值流中每个流程步骤所使用的主要信息系统，这些系统用于存储和传输数据。理解流程中的信息流对于发现生产过程中的某些浪费类型非常重要，关于这一点我会在后续章节中进一步讨论。使用信息流箭头将流程模块与信息系统连接起来。箭头指向信息系统表示数据被输入系统，箭头从系统指出表示数据从系统中被提取。
在Acme的案例中，产品负责人或团队的业务分析师会与工程师讨论需求，并在Jira工单系统中创建工单来记录这些需求。工程师设计API时，会创建或更新OpenAPI定义文件，设计过程中可能会参考Jira工单。他们还会查阅存放在Confluence中的Acme API风格指南。工程师使用基于云的API设计工具，该工具同样存储他们的OpenAPI定义文件。设计完成后，工程师提交一个工单给API网关团队以进行API审查。网关团队在接手审查任务时，会打开云端API设计工具查看API定义文件，并添加审查意见。这些信息流的示意线条如图2.6所示。
2.4.3 添加性能指标
利用你从观察价值流中收集的数据，为每个流程步骤添加性能指标，包括你的 LT（交付周期）、TT（任务时间）和 %CA（完成且准确的百分比）指标。这些指标应填写在数据框图标中，该框用于记录每个流程步骤的重要数据。同时，了解每个流程步骤中等待处理的工作项数量也很重要。将这些排队或积压的工作可视化，有助于分析流程中的浪费点。使用库存三角形图标，在适用的步骤之间添加等待处理的任务数量。在 Acme 案例中，这就是 Jira 工单的数量。
接下来，在每个步骤展示时间指标。时间阶梯图总结每个模块的 LT 和 TT，并显示总的 LT 和 TT。为你的流程绘制时间阶梯图，顶部显示 TT，底部显示 LT。Acme 案例中，完整的流程图及其当前状态和问题陈述部分如图 2.7 所示。
注意：本书重点介绍如何使用价值流映射（VSM）技术进行流程绘制，以推动APIOps的改进。若想深入了解价值流映射及其在不同流程中的应用，请参考 Mike Rother 和 John Shook 著作的《Learning to See》（Lean Enterprise Institute, 2009）。另一本相关书籍是 Karen Martin 和 Mike Osterling 的《Value Stream Mapping》（McGraw-Hill, 2013）。另一个值得考虑的映射技术是基于指标的流程映射（Metric-Based Process Mapping，MBPM），这是一种低层级的流程绘制技术，通常通过白板、纸张和便签协作完成，用于捕捉流程指标。有关 MBPM 的更多信息，可访问 mng.bz/y8NG 及 Karen Martin 的 MBPM 幻灯片 mng.bz/OZWR。
2.4.4 审查你的流程图
让我们来看一下流程图反映的当前状态问题。从图 2.7 可见，Acme 的产品负责人或业务分析员花费 0.25 小时（15 分钟）创建 API 设计变更的工作工单。这里的任务时间（TT）等于交付周期（LT），说明没有延迟。随后，工程师花费 3 小时更新 API 设计（即 API 定义文件）。团队共有四名工程师，但在处理这张设计变更工单前，他们还有六张待办工单堆积，因此这张工单在积压区停留了几天，该步骤的 LT 为 4 天。根据与工程师的讨论和观察，你发现工程师平均 85% 的时间内拥有完成任务所需的全部信息（包括 Jira 工单和 Confluence 中的 API 风格指南）。剩余时间可能缺少部分重要信息，需向他人询问并等待回复，因此他们的 %CA 值为 85%。
完成 API 设计后，工程师在 Jira 中提交工单，请求 API 网关团队审查设计更新。网关团队是负责审查公司所有团队设计变更的核心组，也是公司 API 风格指南的管理者。但该团队需要为 Acme 的16个开发团队服务。他们当前有4张设计变更工单积压，除此之外还需处理许多 API 网关路由和测试相关工单。为平衡工作需求，团队每周召开两次会议（周二和周四）审核并批准设计，每张工单审查时长约一小时。鉴于积压的4张工单，预计需 11 个工作日才能轮到该工单。工单审查时，网关团队会邀请工程师参加会议，解释设计变更。原因之一是 Acme 使用的 API 设计协作工具不支持不同版本文件的差异比较（diff），导致网关团队难以准确判断提交的 API 定义文件具体改动。
审查会议中，网关团队发现工程师应修正的三处问题，并要求修改设计，修改完成后网关团队才批准设计。修正和最终批准的任务时间约为 1 小时，但由于工程师忙于其他任务，导致等待修改完成的时间增加，整个步骤的 LT 达 1 天（8 小时工作制）。
时间阶梯图显示，价值流的 LT 为 16 个工作日（按8小时工作日计共128小时），为批准添加一个新的 API 操作等待时间过长，而实际的任务时间（TT）仅为 5.25 小时。因此，活动比率（总 TT 除以总 LT）为 4.1%，意味着价值流中有 95.9% 的时间工作处于闲置等待状态，效率非常低下！流程图帮助我们直观识别出了流程中的浪费。
2.5 目标陈述
你已经很好地展示了流程的各项指标，你的经理也能清楚地看到问题的具体表现。但在探讨如何改进流程之前，经理还有一个关心的问题：你将依据什么标准或基准来衡量改进工作的成功？成功的样子是什么？A3 报告中的目标陈述部分可以帮助你回答这个问题，并提前思考你打算用哪些指标来确认改进工作的有效性。
基于对当前状况的研究，确定一到两个你希望改进的绩效指标。在 Acme 的案例中，目标可以是将 API 设计审查流程的总交付周期（LT）减少 20%。这意味着将该流程的总 LT 从 16 天减少到 12.8 天。你还可以指定希望达到该目标的时间范围，这个时间可以是几周，也可以是几个季度。为了符合在 A3 报告中偏好用图表、图示和表格展示信息的习惯，你可以用一个简单的表格来表示这个目标，如图 2.8 所示。
你可以提前指定时间范围，也可以在填写完"对策"部分后再回来补充时间范围。因为我常与采用敏捷开发的团队合作，这些团队通常基于冲刺来规划工作，所以我喜欢用预计完成目标所需的冲刺次数来指定时间范围。
不要在"目标陈述"部分讨论问题的解决方案。目标陈述提供的是一个可衡量的目标------即用于比较和判断成功与否的绩效指标。在完成改进工作后，你需要回头检查该部分的数值，以确认改进是否达到了预期目标。
2.6 根本原因分析
你已经定义了问题及其表现形式，并设定了改进目标。但问题为什么会发生？你需要进行根本原因分析，找出问题发生的深层次原因，从而防止问题再次发生。常用的方法之一是"五个为什么"法，即连续问大约五次"为什么？"或者"导致这个问题的原因是什么？"。注意，不一定非得问五次，有些原因可能对应多个理由。目标是找出根本的流程问题，避免类似问题再次出现。在 Acme 的案例中，图 2.9 展示了一个根本原因分析树的示例。
翻译如下：
分析识别出了两个根本原因。第一个是团队使用的 API 设计协作工具不支持版本控制。第二个是中央 API 网关团队是一个组件团队，专注于 API 路由工作，但并不负责自动化审核检查及端到端 API 设计与交付过程的其他方面。
根本原因分析旨在发现并解决问题的深层或根本因果因素，从而避免问题重复发生。它采用演绎推理来建立因果关系，因此需要批判性思维。该分析帮助你避免仓促下结论和采取权宜之计。通过深入挖掘，而不仅仅停留在观点和表面症状，你能发现潜在的问题。在你撰写 A3 报告的"根本原因分析"部分时，你是在提出一个预测性的系统运行理论。你的理论通常是：如果根本原因得到解决，整体系统就能得到改善。在进行根本原因分析时，应与同事及受影响流程中的其他相关人员一起审视你的思路。让他人验证你的想法并探讨你未曾考虑的替代原因，是非常有帮助的。
提示：除了"五个为什么"方法外，你还可以使用另一种思维工具------石川图（又称鱼骨图）。本章不涉及该工具的详细讨论，但你可以访问 asq.org/quality-res... 获取更多信息。
2.7 对策与目标状态
到目前为止，你主要聚焦于问题------提供背景、定义问题、展示问题数据以及分析根本原因。现在是时候提出你打算如何解决它。在精益术语中，你为减少或消除问题根本原因所采取的行动称为"对策"。在 APIOps 语境中，你的对策包括你认为能改善 API 交付流程的行动和 APIOps 实践。
在 A3 报告的"对策与目标状态"部分，头脑风暴并记录你能用来解决分析中识别出的原因的对策。将对策列入表格中，并标明其对应的原因。为了激发创新的解决方案，请尽可能多地考虑方案，并与参与流程的同事商讨。跨职能的参与和共识有助于你获得更好的对策。随着方案的不断完善，你可以缩小列表范围，合并类似的对策，挑选出你认为可行的方案。
为所选对策制定实施计划。在表格中明确谁负责实施每项对策，以及预期完成日期。为了帮助你对对策进行优先级排序，可以添加"收益/投入"列，说明预期收益（高/中/低）和预期投入（简单/中等/困难）。高收益且易于实施的对策应优先执行，而低收益且难以实施的对策应放到最后甚至取消。在实施对策过程中，及时更新"状态"列。图 2.10 中有一个示例。
提示：在实施对策时，将关注点缩小到问题实例的一个小范围。在这个阶段，你处于"试验"模式，想要尽量减少对策应用的范围，同时验证哪些有效、哪些无效。例如，在 Acme 的场景中，你可以将改进重点放在某个 API 相关的改动，或某个开发团队提交的设计变更上。如果对策取得成功，在 A3 报告后续部分中，你可以探讨如何将其推广到更广泛的范围。
在精益方法中，使用"对策"一词而非"解决方案"，是因为对策意味着该行动能够解决当前情境下的问题，但可能不是问题的最终解决方案。未来你可能会发现更好的补救措施，或者问题本身可能演变，需要新的或更新的对策。由于精益的根本原则是追求完美，即持续改进，目标是不断审视当前问题状态并完善对策。对策的作用是改善流程。所谓流程，是指工作从一个步骤顺畅地进行到下一个步骤，没有延迟、中断、闲置时间或返工。APIOps 的改进应当减少等待时间，从而提升流程中的工作流畅度。
你已经定义了对策，但你的经理和 A3 报告的读者可能仍不太清楚，实施这些对策后改进后的流程会是什么样子。如何能形象地展示预期的未来流程呢？
通过创建未来状态流程图来描述目标状态。该目标状态帮助经理一目了然地看到改进后的流程如何运行，以及流程中每个步骤的预期绩效指标。图 2.11 显示了 Acme 的"对策与目标状态"部分完成后的样子，并附有未来状态流程图。你可以看到工程师现在可以在"设计与自动检查"阶段更早地运行自动化设计检查。因为可以在本地运行自动化检查，API 设计问题的检测时间被缩短。还要注意，在 Pull Request 中增加了自动检查的流程。评审工单库存已消失，交付周期（LT）也从16天缩短到了4.1天。
总结来说，在你的"对策与目标状态"部分，应完成以下工作：
- 头脑风暴，提出对策，并与同事共同完善这些对策。
- 制定实施计划------即明确谁负责做什么，以及时间节点。
- 绘制目标状态图，展示改进后的流程应是什么样子。
2.8 效果确认
在对策实施之后，如何验证它们确实减少或消除了问题？在 A3 报告的"效果确认"部分，你需要收集数据，验证所采取的对策是否达到了在"目标陈述"部分定义的预期效果。基于改进，记录并总结你获得的关键新认识。同时，你应建立所实施对策与观察到效果之间的因果关系。
以 Acme 场景为例，你可以绘制一张简单的图表，展示在实施对策的几周内，交付周期（LT）和风格指南合规问题的指标变化。在图表上标记出实施对策的时间点。如果你的因果理论正确，目标指标在该时间点之后应有所改善。图 2.12 展示了 Acme 价值流的一个"效果确认"部分示例。
"效果确认"部分的目标是展示你在"根本原因分析"部分提出的因果关系理论是否正确。这体现了你对流程或系统的理解。这非常有价值，因为如果你拥有经过验证的流程运行理论，就意味着你获得了新的知识，这些知识可能适用于其他流程或组织的其他领域。
2.9 后续行动
假设 A3 报告中"效果确认"部分的结果表明，你的对策在一个志愿参与流程改进的开发团队中取得了成功。那么，如何将这些对策更广泛地推广应用呢？以 Acme 案例为例，这可以在组织中的其他开发团队和 API 上实施。此时，你可以开始创建用户故事（stories）和史诗（epics），以扩展已验证对策的应用范围。同时，寻找其他团队和组织部分，分享你所获得的新经验。图 2.13 展示了 Acme 案例的一个"后续行动"表格示例。
A3报告的一个优势是其尺寸和呈现格式便于分享所学内容。将A3报告发送给具备足够背景的读者，能够让他们快速了解你所做的工作及获得的收获。
2.10 审阅你的A3报告
请你的经理或上级定期审阅你的A3报告，检验你的思路。这是一个让拥有更广泛组织视角的人，基于PDSA（计划-执行-检查-调整）原则，审查你解决问题的客观性和严谨性的机会。同时，你也可以借此机会与经理沟通问题，展示你已完成的解决工作，确保你和经理在所解决的问题上达成一致。
除了经理审阅外，你还可以定期与团队或其他重要利益相关者一起审阅A3报告。我喜欢利用组织内的API实践社区会议（有些公司称之为API公会）来审阅A3。这是一个获得其他关注API流程改进人员反馈的好机会。这样的审阅社区可以提出你可能遗漏的有效对策和后续行动。在准备A3报告的整个过程中，都应该开展正式和非正式的审阅，广泛邀请不同人员参与、贡献和验证A3报告。将各方反馈融入报告至关重要。
2.11 识别价值流中的浪费
精益方法的一个重要原则是识别产品所创造的价值。在审视当前状态流程图时，应区分增值活动和非增值活动。
精益思想（Lean Thinking）
"精益"一词由John Krafcik在其1988年发表于斯隆管理评论的文章《精益生产系统的胜利》中提出，用以描述丰田汽车在生产效率和质量上远超竞争对手的优势。Krafcik指出，丰田的生产理念由企业主导，持续提升效率和质量，同时降低生产成本。James Womack、Daniel Jones和Daniel Roos在《改变世界的机器》（2007年）一书中进一步普及了精益实践。Womack和Jones还著有《精益思想》（2010年），总结出成功实施精益理念的企业所遵循的五大原则：
- 明确单个产品创造的价值。
- 识别每个产品的价值流。
- 使创造价值的步骤顺畅流动；消除大批量工作和排队，这些本质上都是低效的。
- 让客户从生产者处"拉取"价值。
- 追求完美。
精益是一个框架，用于明确指定产品或服务的价值，有效地安排创造价值的任务顺序，最小化浪费地执行任务，并持续改进任务执行方式。精益思想教你识别和消除生产过程中的各种浪费，帮助企业以最少的努力和资本创造更多客户价值。本书的目标之一，就是帮助你将精益原则应用于API的设计、管理、构建、部署和发布，从而尽可能高效地产出有价值的API。
当一些开发团队听到"精益"时，可能会马上联想到他们使用的敏捷框架，比如Scaled Agile Framework（SAFe）或Large Scale Scrum（LeSS）。的确，这些框架在将敏捷应用于软件开发组织时，借鉴了一些精益原则和实践，但理解敏捷框架与精益思维原则之间的区别很重要。
生产过程中的三种活动
- 增值（Value-Adding, VA）工作
价值是客户认为有用且重要的内容。对外部客户而言，价值是他们愿意为之付费的内容。如果活动将输入转化为客户所需的有价值输出，则为增值活动。例如，分析、设计、编码、创建API文档等都是增值活动。 - 价值支持（Value-Enabling, VE）工作
这类工作虽然不直接转化输入为客户需要的产品或服务，但在当前条件下对其他增值活动的开展是必需的。例如，在测试环境中对软件进行验收测试和安全测试，这些测试本身不直接增加软件价值，但能发现问题，确保软件交付给客户之前符合要求。在Acme案例中，API审查本身不增加价值，但属于价值支持活动。再如，ACME的业务分析师或产品负责人创建工作单，也不直接增值，但支持工程师获取设计API所需的需求信息。 - 浪费（非增值，Non-Value-Adding, Non-VA）工作
浪费活动消耗资源，但不产生客户愿意支付的价值。例如，为了开始自己的工作而等待同事完成任务就是浪费。你是否能在价值流中消除不必要的交接或合并流程？Acme案例中，API审查等待11天就是浪费！
改进的目标是增加增值活动，尽可能减少价值支持活动，消除非增值活动。
精益七大浪费
丰田生产方式创始人大野耐一（Taiichi Ohno）在1988年指出生产过程中的七种浪费："我们关注的是从客户下单到收款的时间线，并通过消除非增值浪费来缩短这个时间。"虽然这些浪费最初是针对汽车制造，但同样适用于软件开发及API构建。这七种浪费包括：
- 缺陷产品浪费
对API而言，如错误的API参考文档或错误配置，会导致缺陷本身的浪费、检测缺陷的工作和修复返工。质量保证测试属于价值支持而非增值活动。 - 过度生产浪费
设计和构建API或API功能，而消费者不需要或不会使用（即无经济需求）。API功能增加开发时间和复杂度，同时产生机会成本。 - 在制品库存浪费
未完成的API设计和交付工作等待进一步处理，表现为大批量积压，消耗资源和资本。 - 过度加工浪费
如每次重新设计OpenAPI组件而非复用共享组件，或者重写常用代码（如幂等性校验）而非使用共享库。 - 不必要的人员移动浪费
生产中组装工人需走动取件属于此类；在API开发中，工程师需花时间寻找权限或澄清需求，也属于这类浪费。 - 不必要的物料运输浪费
信息不必要地从一处传到另一处，如多余的邮件、报告或文档。 - 等待浪费
员工等待机器、上游活动完成等。在软件开发中包括等待信息、审批（如人工API审查）、测试结果等。
有关软件开发中七大浪费的更多示例，可参考Mary和Tom Poppendieck的《实施精益软件：从概念到收益》（2007年）和Bohdan Oppenheim的《系统工程精益》（2011年）。Marjukka Niinioja的电子书《API开发中的8种精益浪费》（Osaango Ltd; mng.bz/MZw7）也提供了API设计和交付中的浪费视角。
本书关注API交付流程的自动化，但需注意，如果流程中存在浪费，单纯的自动化可能不会显著提升性能。以Acme为例，增加代码检查步骤确实提升了流程表现，但从目标状态流程图可见，"设计与自动检查"步骤仍需关注，因其交付周期（4天）远高于处理时间（3小时），大部分时间工作处于闲置状态。为优化此环节，你需要深入观察（即"走进现场"）了解原因，是否存在浪费活动及根本原因，这可能成为新的A3改进迭代。部分对策可能并非自动化，而是改变团队工作方式或结构。应考虑多种方案。目标不是自动化本身，而是持续改善流程绩效指标（如交付周期和合规率），为客户提供最大价值。这正是精益追求完美原则的体现。
2.12 使用A3的好处
在APIOps中，你的目标是实现API设计与交付价值流的端到端自动化。然而，自动化只有在能够降低成本或帮助组织为客户创造更多价值时才有意义，例如释放资源，让团队可以专注于更多的增值（VA）活动。使用A3方法来推动APIOps的改进，有助于你深入思考所引入的自动化变革如何真正惠及组织。以下内容介绍了使用A3方法进行APIOps改进的一些优势。
2.12.1 逻辑且客观地思考
A3的核心哲学是计划-执行-研究-行动循环（PDSA循环，也称为戴明循环），这是由W. Edwards Deming提出的，且与紧密相关的计划-执行-检查-行动循环（PDCA）类似。这些迭代方法被用来推动变革和持续改进流程。
在PDSA循环的计划（Plan）阶段，你观察一个问题或机会，收集数据以进行定量评估。你对数据进行分析，理解根本原因，提出一个理论，解释观察到的效果与根本原因之间的关系。然后你计划一项测试或变更来解决问题或利用机会。这正是你在A3报告中，确定主题中的问题、在背景部分调研、在当前状态部分展示观察和数据的步骤。计划阶段还包括根本原因分析部分，你提出了因果关系的假设，以及对策部分，即你设计的测试假设的实验。
在执行（Do）阶段，你在小范围内实施变更或测试，以验证你的假设，这对应着你执行对策的过程。
在研究（Study）阶段，你收集结果并评估其是否符合预期和你的理论，同时记录你对系统工作原理的新认识。因此，该循环促进了持续学习。这就是你A3中的效果确认部分。
备注
PDSA循环与PDCA循环的区别在于对系统工作原理理论的修正，而不仅仅是检查和修订执行计划。PDCA循环中，检查（Check）阶段关注计划执行的成功与否，若失败则修订计划；而PDSA循环中，Deming博士强调不仅需要一个实施计划，还需有系统工作原理的理论。他关注的是预测改进结果（形成理论）、研究实际结果，并将结果与原理论比较，必要时修正理论。他强调只有在已有理论的基础上，通过Do阶段的结果和学习验证或推翻理论，才能产生新的系统知识。换句话说，要生成系统的新知识，你的改进应基于可证伪的系统理论。关于Deming博士的PDSA循环，详见《工业、政府与教育的新经济学》（W. Edwards Deming著，MIT出版社，第3版，2018年）。
最后，在行动（Act）阶段，你将变更更广泛地采纳并分享所学。如果变更未成功，可以放弃或重新执行循环。这对应你的A3报告中的后续行动部分。PDSA循环示意见图2.14。
你可以看到，PDSA循环与科学方法是一致的------识别问题，调研并收集数据，提出假设，验证假设，解读结果以判断是否符合理论，并报告结论。
除了这种逻辑性的方法，A3以观察和数据驱动为核心，帮助你聚焦于事实而非观点。在你的价值流图（VSM）中捕捉关于流程的定量数据（例如交付周期LT、处理时间TT和合格率%CA）有助于消除假设和误解，使你的分析更客观。
2.12.2 达成共识，促进协作
与价值流相关的同事一起审阅你的A3，有助于在改进工作上建立共识和一致性。大家可以共同观察价值流，了解A3中展示的流程和数据，参与撰写和审阅报告。A3的客观和逻辑性有助于你获得各利益相关方的支持，从而顺利推进变革。
2.12.3 运用系统思维方法
A3促使你从整体、系统思维的角度来看待问题，并采取对策加以解决。系统思维是把系统看作一个相互连接的整体，关注各部分之间的关系，而非孤立分析单独部分。这种大局观可能得出与单独分析工作流各环节完全不同的结论。在你的A3中，不仅考虑问题本身，还包括历史背景、组织目标与优先级、同事反馈以及对策。根本原因分析帮助你理解系统的行为。
其他问题解决方法
本书推荐使用A3作为你的APIOps改进方法，因为它是精益专业人士常用的流行问题解决工具。但需明白，A3并非唯一的流程改进方法。还有六西格玛的定义-测量-分析-改进-控制（DMAIC）方法，以及福特公司开发的八步法（8D）。这些方法本质上遵循PDSA循环的逻辑，但它们的详细讨论超出本书范围。有关DMAIC，详见 mng.bz/eoBz；有关8D，详见quality-one.com/8d 。
2.13 领导你的APIOps变革
在本章结束前，我给你一些关于推动变革的通用建议。引入APIOps即是引入变革，而在大型组织中变革从来不易。John P. Kotter在《变革领导》（哈佛商业评论出版社，2012）中提出了引领变革的八个阶段流程。以下是你如何将其应用于APIOps转型：
- 制造紧迫感
研究市场和竞争对手，了解组织面临的威胁、危机、潜在危机及机会。比如，你的竞争对手多快将代码和API推向生产？你的API在一致性、设计质量和文档方面与竞争对手相比如何？利用这些信息让管理层和同事意识到变革的必要性。构建若不变革可能发生的场景，劝说管理者维持现状是危险的。记住，说服人们走出舒适区需要付出努力。 - 组建强有力的联盟
组建一支有影响力的变革领导团队（指导联盟），拥有共同的承诺和足够的权力推动APIOps变革。这个联盟应在公司常规架构外运作。尽可能包括一位执行赞助人（如部门主管或负责API项目的主管），为计划提供支持和资源，以及高级API产品经理和API架构师。 - 创建变革愿景
明确定义APIOps转型的愿景，用简短几句话描绘未来蓝图，帮助人们理解。确定变革指导价值观，制定实现愿景的策略。注意避免愿景过于复杂或模糊。你的指导联盟应能在5分钟内清晰描述愿景。 - 传播愿景
利用一切机会宣传新愿景和策略，切勿传播不足------多多谈论愿景。指导联盟应以身作则，成为愿景的榜样。内部实践社区和公司简报是不断传播APIOps愿景的好机会。 - 消除障碍，赋能他人
移除阻碍实现愿景的障碍、系统和结构。审视现有工具是否妨碍APIOps工作方式，考虑替换。为同事提供支持APIOps的工具和流程，促进跨部门协作创新，实现愿景。 - 创造短期胜利
为激励变革，计划并实现可见的性能改进。确保变革初期几周能展现成功。根据组织面临的问题，利用API代码规范检查（第3章）、破坏性变更检查（第4章）或最简API定义流水线（第8章）等，找到快速见效的切入点。认可并庆祝参与领导和交付改进的同事。 - 巩固改进成果
几次快速胜利后，切勿过早宣布胜利。巩固成果及由此获得的信誉，推动组织内更大规模的变革，改变系统和结构。思考如何将APIOps实践推广到组织中其他Web API开发流程，甚至消息API。招聘、提拔和培养能够实施和强化愿景的员工和变革推动者。 - 制度化变革
尽可能展示新的APIOps原则与实践与企业成功之间的联系。确保未来新员工了解你的DevOps和APIOps工作方式。创建或更新内部API开发培训项目，包含APIOps实践，使新老同事都能应用。
总结
随着组织采用DevOps并构建大量API产品，他们面临着如何将API设计、文档和部署流程规模化，以匹配日益加快的软件交付节奏的问题。
这些问题表现为API设计交付周期（LT）过长、API文档问题以及API一致性问题。当组织将解决这些问题作为目标时，就是引入APIOps改进的好时机。
A3问题解决方法是一种思考和报告工具，可以用来对APIOps改进采取科学的方法。你可以借助它理清改进工作的思路，与同事达成共识，验证改进是否能达到预期效果，并沟通进展情况。
使用价值流图（VSM）技术进行流程映射，是可视化你希望通过APIOps自动化改进的流程的有效方法。它帮助你识别可以消除的浪费活动以及可以改进的增值活动。
启动你的APIOps转型应从制造紧迫感开始，组建能够推动变革的指导联盟，并创建和传播你的APIOps愿景。