12.6 采纳路线图
本附录是关于渐进式推行本书各项实践的实用指南。整本指南中最重要的一条准则，在每一章都反复强调，就是渐进式采纳，不要一次性推行。试图一次性改变一切的转型，往往什么都改变不了：它耗尽善意、压垮团队，并在第一次危机中崩溃。而一场从真实痛点出发、交付出可见成效、再逐步复利增长的转型，则可以在几年内撬动数千人的组织。
本路线图为你提供采纳原则、从头 90 天到两年以上按成熟度排列的推进顺序、一套带有示例的优先级排序框架、按领域划分的速赢举措、面向企业和政府的专门指导、衡量成功的方法，以及应当避免的失败模式。
采纳原则
无论你的组织规模、所属行业或起始成熟度如何，以下原则都成立。
- 从痛点出发，而不是从框架出发。 找出最令人痛苦的问题（）无论是发布缓慢、频繁宕机、审计失败，还是人员流失（）并优先解决它。痛点能产生自上而下的强制命令永远无法产生的需求和政治掩护。没有人会抗拒得到缓解。
- 铺好道路胜过下达命令。 让推荐的做法成为最容易的做法。一条更快、更安全、文档更完善的黄金路径能凭自身优势赢得采纳；而一项比变通方案更慢的政策，终将被绕过。先投资铺好道路，再废弃土路。
- 衡量结果，而不是活动。 追踪这项改变是否提升了交付速度、可靠性、安全态势或用户成果，而不是有多少团队参加了培训或勾选了合规项。先埋点测量，再实施改变，这样才能证明效果。
- 争取高管发起人支持，并且持续维系它。 持久的变革需要一位负责任的高管，他能保护经费、清除障碍，并在转型变得不适时坚持立场。发起人支持不是一次启动活动，而是一段需要用结果不断重新赢得的持续关系。
- 先争取志愿者，再面对被迫者。 从愿意改变的团队开始。他们的成功会成为吸引犹豫多数的参照故事。若先强迫抵触者行动，只会产生消极应付和反面教材。
- 尽量让改变可逆。 优先选择可以试点、可以衡量、也可以回滚的改变。可逆的“双向门”决策可以快速推进；把繁重的流程留给真正不可逆的决策。
- 尽早并持续展示成果。 在数周而非数季度内交付出可见的成果。势能是一种资源，要用第一场胜利去资助下一步。
- 因材施教，尊重各团队的起点。 用统一标准衡量所有团队既不公平也会打击士气。要根据每个团队的准备程度和痛点来安排推进顺序。
按成熟度排列的推进顺序
下面的各个阶段是累积式的：每一阶段都建立在前一阶段之上。日期仅作参考，而非硬性截止期限；规模较大或监管较严的组织，每个阶段可能需要更长时间。无论节奏快慢，这个模式（先稳定，再标准化，然后规模化，最后持续维系）都是成立的。
头 90 天：稳定并验证
目标：建立基线，选定一两个旗舰问题，并与一个愿意配合的团队一起交付一个可信的首胜。
- 指定一位负责任的高管发起人和一个小型的指导联盟。
- 为四项 DORA 指标（部署频率、交付前置时间、变更失败率、恢复时间）建立基线，即便数字还比较粗略。
- 依据 12.4 章中的成熟度模型进行一次轻量级评估，找出最大的差距。
- 选定一两个自愿参与且确实存在痛点的试点团队。
- 端到端地解决一个显眼的问题（例如为某个团队的部署实现自动化，或为某个关键服务添加 SLO）。
- 建立一份共享的决策记录（ADR）以及一个发布成果的地方。
- 在做出任何改变之前，先就如何衡量成功达成一致。
到第 6 个月：把成功模式标准化
目标：把试点的成功转化为可复用、有文档记录的模式，并将其作为一条铺好的道路提供给下一批团队。
- 将试点得出的黄金路径以可复用的模板、流水线和文档形式发布出来。
- 建立一个平台团队或赋能团队（哪怕只是虚拟团队）来拥有并支持这条铺好的道路。
- 将这一模式推广到另外三到五个团队，按影响力和准备程度排定优先级。
- 把自动化的质量和安全关卡（代码检查、测试、SAST/SCA）作为默认项而非附加项引入共享流水线。
- 启动无责事件复盘实践，并在内部发布事后总结。
- 建立一个轻量级的治理论坛（架构评审、铺好道路的管理），其作用是扫清障碍而不是把关阻拦。
到第 12 个月：在整个组织中推广
目标：让铺好的道路成为大多数新工作的默认选择，并开始淘汰最糟糕的遗留做法。
- 扩大平台团队的职责范围；发布服务目录和评分卡。
- 设定全组织范围的基线：一级服务的 SLO、每条流水线中的安全控制、前端构建中的无障碍检查。
- 按团队追踪采纳率，并让这些数据可见。
- 在风险最高的系统上，采用绞杀者模式和抽象分支模式，有计划地开展遗留系统现代化改造。
- 把度量纳入规划：各团队在正常的运作节奏中回顾自己的 DORA 和可靠性趋势。
- 投资于赋能（内部培训、指导、实践社区），让能力的传播速度快于强制命令的推行速度。
两年以上：持续维系与改进
目标：这些实践成为“我们做事的方式”，而不是一个项目，组织无需中央推动即可持续改进它们。
- 将转型项目作为一个具名倡议予以终止；把其工作内容嵌入常规治理和平台运营之中。
- 把铺好的道路当作一款产品来对待，赋予它自己的路线图、用户和满意度指标（开发者体验调查）。
- 把技术债务和现代化改造当作一个持续存在的组合来管理，而不是一次性的突击。
- 定期进行成熟度再评估，并随着基准水平的提高而相应上调标准。
- 防止倒退：持续维系发起人支持、持续测量，并随着技术和威胁的演变不断更新实践。
一套优先级排序框架
你要做的改进永远多于你的产能所能承受的数量。用一个简单、站得住脚的模型来排定优先级，而不是听凭会议室中声音最大的人。
从三个维度为每一项候选举措打分：
- 影响力（1–5）： 这项举措能在多大程度上改善一项真实的结果（交付速度、可靠性、安全性、成本或用户价值），惠及多少团队或用户？
- 工作量（1–5）： 交付它需要多少工作、协调和干扰？（数值越高，代表工作量越大。）
- 风险权重（0.5–2.0）： 一个反映紧迫性和风险敞口的乘数。安全、合规和安全性相关的问题权重更高；锦上添花类的事项权重更低。
一个有用的排名分数公式是：
Priority = (Impact × Risk weight) ÷ Effort按优先级从高到低排序。优先安排排名靠前的事项，但要始终保持至少一项快速、低工作量的“速赢”举措在进行中以维持势能，并随着形势变化，每个季度重新审视这些分数。
示例演算
| 举措 | 影响力 | 工作量 | 风险权重 | 优先级 | 排序 |
|---|---|---|---|---|---|
| 为营收最高的服务实现自动化部署 | 5 | 2 | 1.5 | 3.75 | 立即 |
| 为一级服务添加 SLO 和告警 | 4 | 2 | 1.5 | 3.00 | 立即 |
| 在共享流水线中引入 SAST/SCA | 4 | 2 | 2.0 | 4.00 | 立即 |
| 向所有前端推广一套设计系统 | 4 | 5 | 1.0 | 0.80 | 稍后 |
| 将主机批处理迁移到云端 | 5 | 5 | 1.5 | 1.50 | 分阶段 |
| 在各团队之间统一 ADR 标准 | 3 | 1 | 1.0 | 3.00 | 立即（速赢） |
| 在全组织范围内采用一门新编程语言 | 2 | 5 | 0.5 | 0.20 | 推迟 |
在这个示例中，安全流水线的相关工作因风险权重高、工作量适中而位居榜首，而全组织范围的语言更换尽管大家热情高涨，却因影响力低、工作量和干扰程度高而落到末尾。这个框架让这种权衡变得明确、可讨论，而这正是它真正的价值所在。
按领域划分的速赢举措
本书的每个部分都有一个低成本、高信号的第一步。从这里开始。
| 部分 | “从这里开始”的速赢举措 |
|---|---|
| 基础篇（文化、团队、流程） | 采用轻量级 ADR，并开展一次无责回顾会议；让决策和学习成果可见。 |
| 编程技艺 | 在 CI 中开启自动格式化工具和代码检查工具作为强制默认项，让代码风格不再成为评审话题。 |
| 架构 | 为你最重要的系统撰写一页纸的架构决策记录和一张 C4 上下文图。 |
| 安全 | 在流水线中添加依赖项扫描（SCA）和密钥扫描；先在一个关键代码仓库中启用它们。 |
| 用户体验/设计 | 在流量最高的流程上开展三次低成本可用性测试；修复你所观察到的首要问题。 |
| AI/机器学习 | 在开展任何模型相关工作之前，撰写一页纸的问题框定和数据准备度检查；明确将如何评估成功。 |
| 数据/分析 | 确定一个共同认可的“北极星”指标和一个值得信赖的仪表盘；淘汰一个相互矛盾的指标。 |
| DevOps/平台 | 让一个团队实现完全自动化的构建-测试-部署流水线，并将其记录为模板。 |
| 运维/可靠性 | 为你最关键的用户旅程定义 SLI 和一个 SLO；针对症状而非原因发出告警。 |
| 企业/政府 | 把你当前的控制措施对照一套框架（NIST CSF、ISO 27001 或 SOC 2）进行映射，并为其中一项控制实现证据自动化。 |
面向企业的专门指导
大型成熟组织拥有规模、众多团队、深厚的遗留系统，以及沉重的变更管理开销。请据此调整路线图。
- 联邦式管理，而不是把一切都集中化。 单一的中央团队无法服务数百个产品团队。用平台团队提供铺好的道路，用赋能团队进行辅导，同时让产品团队保留自主权（参见团队拓扑）。
- 尊重康威定律。 你的架构会映射出你的组织架构图。如果你想要解耦的服务，就需要解耦的、被赋权的团队；应当有意识地进行重组，而不是与组织的固有走向对抗。
- 把遗留系统当作一个组合来对待。 你不可能把一切都现代化。按风险和业务价值给遗留系统排序，对少数真正重要的系统采用绞杀者模式迁移；对其余系统则有意冻结或退役。
- 变更管理是真正的工作。 在规模化场景下，沟通、培训和激励对齐都不是开销，而是转型本身。要为赋能、实践社区和内部布道明确编列预算。
- 警惕强制命令的本能反应。 大型组织默认的做法是发布政策备忘录。要抵制这种冲动。没有铺好道路的强制命令只会催生形式主义的打钩合规；而没有强制命令的铺好道路则能带来真正的采纳。
- 对齐激励与资金。 从项目制资金转向持久的产品团队制资金，让改进成果能在项目结束日期之后继续存活。奖励结果，而不是产出。
面向政府的专门指导
公共部门组织还要面对采购周期、合规关卡、承包商管理、多年期资金安排以及透明度义务。这些是设计输入，而不是借口。
- 从第一天起就为 ATO（运营授权）而设计。 运营授权和持续监控关卡（依据 NIST RMF/800-37）可能主导整个时间线。要尽早把安全控制和证据收集内建到流水线中，让合规成为一个持续过程，而不是拖到最后才手忙脚乱地阻塞进度。
- 渐进式采购。 多年期、一次性推行的大型采购，会把本书所警示的“一次性推行”失败模式制度化。应优先选择模块化合同、更小规模的授标，以及允许迭代的、基于结果的工作说明书。
- 把供应商和系统集成商当作团队的一部分来管理。 大量政府工程工作是由承包商交付的。要把铺好的道路、质量关卡和透明度要求写进合同，并确保知识和代码转移给政府，以避免供应商锁定和巴士系数风险。
- 围绕资金周期做规划。 多年期和年度拨款限制了你能做出的承诺。要对工作进行排序，使每个获得资助的增量都能独立交付价值，即便资金安排发生变化，也不会让你在转型中途陷入困境。
- 无障碍和简明语言是法律义务。 Section 508、ADA、WCAG 以及简明语言要求都是强制性要求，而不是加分项。要把无障碍检查内建到流水线中，把内容评审内建到工作流程中。
- 透明度是一项特性。 FOIA（信息自由法）、开源强制要求（“公共资金，公共代码”）以及已发布的服务标准，都意味着你的工作要接受公众监督。要为此而设计：留存清晰的记录，在适当情况下开放，并发布诚实的绩效数据。
- 遵循经过验证的公共部门模式。 美国数字服务手册（U.S. Digital Services Playbook）、GOV.UK 服务标准和 USWDS 都凝聚了来之不易的经验教训；应当采用它们，而不是重新发明。
衡量采纳成效
要同时衡量先行指标（表明变革正在扎根的早期信号）和滞后指标（你最终关心的结果）。关注趋势，而不是单次读数，并且永远不要让一项指标沦为可以被操纵的目标。
| 类型 | 指标 | 它说明了什么 |
|---|---|---|
| 先行 | 采用铺好道路的团队数量 | 采纳扩散的速度 |
| 先行 | 流水线关卡覆盖率（测试、SAST、无障碍） | 质量/安全被嵌入的程度 |
| 先行 | 开发者体验调查得分 | 铺好的道路是否真正带来帮助 |
| 先行 | 以 ADR 形式记录的决策比例 | 书写/学习文化是否真实存在 |
| 滞后 | 部署频率（DORA） | 交付吞吐量 |
| 滞后 | 变更的交付前置时间（DORA） | 从提交到生产环境的速度 |
| 滞后 | 变更失败率（DORA） | 交付流程的质量 |
| 滞后 | 服务恢复时间（DORA） | 运维韧性 |
| 滞后 | 事件频率与严重程度趋势 | 可靠性随时间的改善情况 |
| 滞后 | 审计发现/控制失效 | 合规态势 |
| 滞后 | 留任率与流失率 | 文化是否正在改善 |
这四项 DORA 指标是跨行业验证程度最高的交付结果度量；应把这四项指标一起的改善情况作为核心信号来看待，并警惕以牺牲某一项指标为代价来改善另一项。
常见失败模式及其规避方法
| 失败模式 | 表现形式 | 规避方法 |
|---|---|---|
| 一次性大规模推行 | 一次性为所有人改变一切；项目在自身重压下崩溃。 | 按痛点和准备程度排序；先试点、后验证、再规模化。 |
| 只有强制命令而没有铺好道路 | 政策要求采用新方式，但新方式比旧方式更慢；团队表面合规、实际绕行。 | 首先建立更容易、更好的路径；凭实际优势赢得采纳。 |
| 照搬框架的形式主义 | 照抄 SAFe、Spotify 模式或其他组织的结构，却不考虑各自的上下文。 | 从自身的痛点和原则出发；因地制宜地改造，而不是原样移植。 |
| 衡量活动而非结果 | 庆祝培训完成率和勾选项，而交付水平和可靠性却毫无起色。 | 从一开始就对结果（DORA、事件、用户价值）进行埋点测量。 |
| 工具先行的转型 | 购买一个平台，指望文化随之而来。 | 以实践和铺好的道路为先导；工具应服务于它们，而不是相反。 |
| 失去发起人支持 | 高管支持者离职或不再参与；项目陷入停滞。 | 把这项变革制度化进入常规治理；建立一个联盟，而不是依赖单点。 |
| 虚荣指标与数据操纵 | 覆盖率或速度数字上升，而质量却在下降。 | 把指标当作带有平衡措施的信号来使用；绝不将其作为唯一目标。 |
| 在遗留系统上贪多嚼不烂 | 试图把一切都现代化，结果什么都没交付。 | 按风险和价值排序；对少数关键系统采用绞杀策略，其余的则予以冻结。 |
| 转型疲劳 | 无休止的变化却看不到成果；团队逐渐脱离参与。 | 尽早交付成果；维持可持续的节奏；让项目自然收尾并成为日常工作。 |
| 无视组织架构图 | 新架构与现有团队结构相互对抗。 | 运用逆康威操纵法：按你想要的架构来塑造团队结构。 |
最简版本
如果你只记得本附录中的一件事：
- 找到最大的痛点，与一个愿意配合的团队一起解决它。
- 把这个解决方案变成一条比旧方式真正更轻松的铺好道路。
- 衡量结果，展示成果，并用它来资助下一步。
- 不断重复，逐步扩大范围，直到铺好的道路就是你们做事的方式本身。
- 持续维系发起人支持、持续测量，永远不要一次性大规模推行。
有关支撑评估工作的成熟度模型，请参见第 12.4 章；有关将每一步落地实施的启动、评审和审计清单，请参见第 12.2 章。