11.1 探索流水线

概述与动机

探索流水线（discovery pipeline）是在交付之前、以及与交付同步进行的一系列工作，用来决定该构建什么、为什么要构建，并定义成功将会是什么样子。交付流水线（第 11.2 章）把经过验证的想法转变为运行中的软件，而探索流水线则把问题、证据与战略转变为一份经过优先排序、可测试的预期成果清单。在现代实践中，这两条轨道是持续并行运行的，常被称为双轨（dual-track）开发，而不是先后相继的两个阶段。探索不断为交付提供一批已降低风险、界定清晰的工作，交付则不断把真实世界的结果数据反馈回探索。

对于大型团队而言，薄弱的探索流水线是软件领域中代价最高昂的失败模式。一个交付出色但探索薄弱的团队，会高效率地构建出错误的东西：它交付得很快，达成了速度目标，却依然没有推动任何一项业务指标。这种代价在工程仪表盘上是看不见的，却在资产负债表上巨大无比。探索流水线正是让这种代价变得可见的方式：它迫使目标在投入大量资源之前，就必须是明确的、可衡量的、可证伪的。

企业与政府场景则提高了赌注。企业需要协调数十个团队围绕一个共同战略行动，因此错位的局部目标会累积成被浪费的整个投资组合。政府项目要为立法授权的使命投入多年的公共资金，“我们按照合同规定建造了它”在这里不能成为一种辩护，如果那个结果（服务了多少公民、等待时间缩短了多少、防止了多少欺诈）从未真正实现。一条以目标、度量指标和明确的质量需求来表达的、有纪律的探索流水线，正是双方保持意图可审计的方式。

关键原则

成果重于产出。 衡量你为用户和业务创造的改变，而不是你交付了哪些功能。
让意图明确且可衡量。 一个你无法衡量的目标，只是一个你无法管理的看法。
先降低风险，再构建。 最便宜的实验胜过最自信的看法。
探索与交付持续并行运行，而不是先后相继的关卡。
质量属性是需求，不是事后补充。 可靠性、安全性和无障碍性是被发现和规定出来的，而不是被寄予希望的。
一致性胜过局部优化。 层层嵌套的目标把团队工作与战略连接起来。
闭合循环。 交付出的成果是重新进入探索的证据。

建议

用 OKR 来框定方向

用 目标与关键结果（Objectives and Key Results，OKR）来把战略与团队执行连接起来。目标（Objective）是一个定性的、鼓舞人心的、对预期终局状态的陈述（“让首次入职变得毫不费力”）。关键结果（Key Results）是少量（通常为二到四个）可衡量的成果，用以证明目标正在被达成（“把 7 天激活率从 40% 提高到 60%”；“把入职相关的支持工单减少 30%”）。关键结果表达的是成果，而不是任务：“交付新的引导向导”是一个伪装成结果的任务。

以对齐而非指令的方式层层传递 OKR：领导层设定少量的公司级目标；各团队提出能够向上支撑这些目标的关键结果和自己的目标。按固定节奏设定它们（通常以季度为单位、以年度为框架），在周期中段进行评审，并在周期结束时诚实地打分。让它们与绩效评审保持分离：一旦 OKR 的打分与薪酬挂钩，很快就会被故意压低。关于 OKR 如何与投资组合和项目管理相连接，见第 10.1 章。

用 KPI 来监控健康状况

把关键绩效指标（Key Performance Indicators，KPI）与 OKR 区分开。OKR 描述的是你在这个周期想要的改变；KPI 描述的是无论你在改变什么，你都必须维持的持续健康状况（正常运行时间、转化率、每笔交易成本、客户满意度）。一个指标可以同时是两者（一个你正在积极努力推动的 KPI，会变成一个关键结果），但大多数 KPI 是你监控的护栏，而不是你冲刺追逐的目标。

把每一个重要指标归类为先导指标（leading）（具有预测性且当下可据以行动，例如试用注册量）或滞后指标（lagging）（具有确认性但反应缓慢，例如年度营收）。探索依靠先导指标来提前掌舵，而不是等滞后指标事后确认。要警惕那些稳定上升却什么也预测不了的虚荣指标（原始页面浏览量、注册用户总数）；优先选择比率类和群组（cohort）类指标，它们更能抵御被刻意操纵。关于这些度量背后的分析与实验机制，见第 7.3 章和第 7.4 章。

明确规定系统质量属性

功能性需求说的是系统做什么。系统质量属性（即各种”性”：可靠性、性能、可扩展性、安全性、无障碍性、可维护性、可运维性）说的是它必须做得多好。这些属性经常被探索不足：每个人都假定它们存在，没有人明确规定它们，于是它们最终以生产事故的形式浮现出来。把它们当作探索输出中的一等公民来对待。为每个项目识别出具有架构意义的需求（那些会实质性塑造架构的质量要求）。把它们量化（“在 10 倍当前负载下 p99 延迟低于 200 毫秒”；“WCAG（Web 内容无障碍指南）2.2 AA 级”；“恢复时间目标为 15 分钟”）。并且在可能的情况下，把它们编码为自动化的适应度函数（fitness function）（持续验证某项质量属性的可执行检查），供交付流水线检查。这是第 3.1 章（架构基础）和第 3.5 章（可扩展性、性能、韧性）在探索侧的对应内容。

让每一个目标都符合 SMART 原则

无论是撰写一项关键结果、一条验收标准，还是一个质量目标，都应用 SMART 测试：

具体（Specific）： 指明一个清晰、无歧义的结果。
可衡量（Measurable）： 有一个指标和一个可信来源。
可实现（Achievable）： 在约束条件和证据下是现实可行的。
相关（Relevant）： 能够向上支撑一个更高层级的目标，并关联到用户价值。
有时限（Time-bound）： 有一个截止日期或评审日期。

“提升性能”没有满足任何一条标准。“在第三季度末之前，把移动端用户的中位结账时间从 8 秒降低到 3 秒，并通过真实用户监控进行衡量”五条全部满足。SMART 标准把模糊的雄心转化为一个可证伪的主张，供探索去测试、交付去验证。

运行持续的、以证据为驱动的探索

把探索构建为一条可重复的流水线，而不是一次性的阶段：

感知（Sense）。 收集信号：用户研究、支持数据、分析数据、市场与合规方面的输入。
框定（Frame）。 绘制机会图（机会-方案树，opportunity-solution tree，把一个预期成果与能够推动它实现的用户需求和候选方案连接起来）。
假设（Hypothesize）。 把假定表述为可证伪的主张：“我们相信 [某项变更] 会为 [某个细分群体] 带来 [某项成果]，并且我们会通过 [某项度量指标] 是否变动来判断这一点。”
实验（Experiment）。 用最便宜的测试来验证风险最高的假定：访谈、原型、假门测试（fake-door test，先宣传一个尚未构建的功能以衡量真实需求）、A/B 实验（对两个变体进行随机化比较，见第 7.4 章）。
决策（Decide）。 坚持、转向，或放弃，并把存活下来的方案连同它们的 SMART 成功标准一起送入交付待办事项列表。

探索流水线的产出不是一份功能清单；它是一股源源不断的、经过验证的、可衡量的赌注流，随时准备交付。

权衡取舍：利与弊

方法	优点	缺点
基于成果的目标（OKR）	让团队与影响力对齐；在”如何做”上赋予自主权	很难写好；容易被事后填入任务来凑数；归因噪声大
产出/功能路线图	可预测，易于沟通和签订合同	奖励交付而非影响力；掩盖了做错方向的风险
重度前置探索	减少构建浪费；需求扎实	拖慢启动速度；有分析瘫痪的风险；假设依然未经测试
持续双轨探索	持续降低风险；反馈迅速	需要研究能力和纪律；更难安排日程
将明确的质量属性设为 SMART 目标	防止”某某性”方面的意外；可审计	量化需要投入精力；可能过度约束早期探索

核心的张力在于承诺与学习之间。企业，尤其是政府，往往出于预算和合同的需要而要求坚定的承诺，这会把工作拉向产出型路线图。良好的成果则需要留出学习的空间，这会把工作拉向 OKR 和实验。这样来解决它：对问题和成果要坚定承诺，对解决方案则要保持灵活。

与团队讨论的问题

你的团队里谁真正拥有探索这件事的所有权，他们是否有能力持续运行它，而不是只在一次性的冲刺中做一次？ 双轨开发只有在每周都有人守着探索这条轨道时才有效，而不是只在季度开始时。在一个大型组织里，探索往往没有专职负责人，于是它就落到了任何有空闲时间的人身上，而这个”任何人”其实并不存在，团队于是默认直接开始构建。拿出证据：数一数你们最近十个功能中，有多少是先经过一个有文档记录的假设和一次廉价测试，再进入构建，还是直接进了待办事项列表。在企业和政府场景中，一个错位的项目可能浪费掉多个团队季度的工作，因此要指定一位产品负责人或一个三人小组（产品、设计、工程），让他们对”感知-框定-假设-实验-决策”这个循环负责。如果没有人拥有这件事的所有权，先把人配上，再讨论别的一切。
你目前的哪些项目存在从未被量化过的、具有架构意义的需求，其中有哪些可以被编码为适应度函数？ “某某性”（可靠性、性能、安全性、无障碍性）往往被想当然地假定，然后以生产事故的形式浮现出来。逐一检视每个正在进行的项目，问一问哪些质量属性会实质性塑造架构，并检查每一项是否都有一个数字和一个可信来源：“10 倍负载下 p99 低于 200 毫秒”、“WCAG 2.2 AA 级”、“恢复时间目标为 15 分钟”。对企业和政府而言，未被量化的无障碍性或安全性需求会带来直接的法律和审计风险。要拿出来的信号是你们最近三次事故：有多少能追溯到一个没有人规定过的质量属性？只要能把一个目标转化为交付流水线检查的自动化适应度函数，就去做，因为一个被规定了但未被强制执行的目标终将走偏。
你们上一次决定采用某个解决方案时，测试的是风险最高的假定，还是最容易测试的那个？ 团队总是可靠地验证他们最有把握的那个假定，而跳过那个真正能扼杀这个想法的假定。为每个项目列出它的假定（可取性、可行性、技术可行性），按照”如果我们在这一点上错了，这个想法会死得有多彻底”来排序，然后把最便宜的测试对准这份清单的最顶端。这在规模化场景中很重要，因为一个自信的资深团队可能把整整一个季度的工程投入都押在一个未经测试的信念上，而这种代价在发布之前都是看不见的。拿出证物：你们最近一次假设是否被表述为”我们相信 [某项变更] 会为 [某个细分群体] 带来 [某项成果]，通过 [某项指标] 来衡量”，并问一问你们是测试了它，还是直接就把它构建出来了。如果你说不出风险最高的假定是什么，那你就还没准备好投入构建能力。
你们的关键结果中，有多少是真正的成果，又有多少是披着成果外衣的任务或发布日期？ 基于成果的规划中最常见的失败，就是用你们早已计划好要做的工作（“上线新的引导向导”）去事后填充关键结果，而不是填入那项工作理应引发的改变（“把 7 天激活率从 40% 提高到 60%”）。在规模化场景下，这会悄悄地使整件事失去意义：几十个团队都报告”绿灯”，却没有任何一项业务指标发生变动，因为每个人都在按照是否交付了东西给自己打分。这种相反的拉力是真实存在的，产出型路线图更容易沟通、签约和预测，这正是它们悄悄卷土重来的原因。拿出你们当前的 OKR 集合，把每一条关键结果标记为成果或产出，然后检查一下 OKR 打分是否与薪酬纠缠在一起，因为与薪酬挂钩的结果很快就会被故意压低。对于资金是依据既定目标承诺的企业和政府投资组合而言，一份只有产出、没有成果度量的路线图，就是一个等着被发现的审计问题；要坚持每个项目都对一个问题和一项可衡量的成果做出坚定承诺，同时对解决方案保持灵活。
你们的哪些 KPI 即使在产品变得更糟的情况下也会持续上升，又有哪些护栏在保护你们正在积极努力推动的那些指标？ 每一个你提升为目标的指标，都在邀请古德哈特定律（Goodhart’s Law）发挥作用：一旦一项度量变成了目标，人们就会去优化这项度量本身，而不是它原本用来代表的那件事。虚荣指标（原始页面浏览量、累计注册用户数）可靠地上升，却什么也预测不了，而一个在没有护栏的情况下被死盯不放的单一关键结果，可能会以损害某个你从未提及的东西为代价而达成。这种张力在于，先导指标能让你及早掌舵，但噪声大且容易被操纵，而滞后指标虽然可信，却确认得太晚，来不及据此行动。拿出你们的指标清单，把它们分类为先导或滞后、目标或护栏，然后针对每一个目标做压力测试，问一问”一个聪明的团队怎样才能在让产品变糟的同时，还是达成了这个数字”。在受监管和公共场景中，要把护栏和目标一起公开，因为一个只看到头条指标的监督机构，无法分辨这是真正的公共价值，还是一个被操纵出来的数字。
当交付上线了某样东西之后，真实世界的结果究竟是如何重新回到探索环节的，还是这个循环始终没有闭合？ 双轨开发只有在交付出的成果作为下一轮的证据流回来时，才能产生复利效应；当循环始终没有闭合时，团队会交付、庆祝，却从来不去了解这个赌注是否真的有回报，于是同样未经测试的假定会一再重演。在一个大型组织中，反馈路径正是责任最容易掉进缝隙里的地方：交付拥有发布，分析拥有仪表盘，却没有人拥有”把承诺的关键结果与观察到的结果进行比较”这件事。拿出你们最近十个已交付的项目，逐一问一问，是否有人把成果指标与最初的 SMART 目标进行过核对，以及这次核对是否改变了后续的某个决定。对于承诺了多年资金的企业和政府项目而言，要指定退役或重新界定那些未能推动其指标的功能的节奏和负责人，因为一个没人再回顾的已上线功能，会变成一项没有任何问责评审的永久性成本。

行业视角

初创企业。 团队规模很小、跑道很短的情况下，你的探索流水线要有意做得很轻量，但绝不能省略：一天的客户访谈和一次假门测试的代价，与一次错误构建所耗费的数周相比几乎可以忽略不计。选定一个能代表你核心价值的先导指标，把每个赌注表述为一个单一的可证伪假设，并在写代码之前而不是之后扼杀掉那些想法。在五个人的团队里，正式的 OKR 是杀鸡用牛刀；每个周期一个诚实的、可衡量的成果，就足以防止”速度”变成”有动作却没有进展”。

小型企业。 你很可能没有专职的研究员或产品分析师，因此要把探索当作一种习惯，而不是一个职位：和真实客户进行几次结构化的对话，加上一个你已经在收集的简单指标。自建还是购买的问题会占据主导地位，因为大多数质量属性（可靠性、安全性、无障碍性）从一个信誉良好的供应商那里获得，要比自己去规定和执行来得便宜。写下一两个 SMART 目标，这样你就能判断一个购买来的工具或一次小规模构建是否真的推动了成果，并避免把稀缺的预算投入到没有人验证过需求的功能上。

企业。 规模会把探索变成一个横跨数十个团队的协调问题：如果没有一个共享的 OKR 节奏和一个共同的”成果”定义，局部目标就会漂移并重复，错位的赌注会累积成被浪费的投资组合。把具有架构意义的需求如何被量化标准化，并把它们编码为适应度函数，让质量属性受到治理，而不是被想当然地假定。把探索当作一个投资组合来管理，配有明确的终止标准，以及一个把交付出的成果指标反馈回下一个周期的循环，这样领导层就能依据影响力来掌舵，而不是依据一份功能待办清单。

政府。 采购和多年期资金要求坚定的承诺，这会把工作强烈地拉向产出型合同，然而公共价值却存在于成果之中：服务了多少公民、缩短了多少等待时间、减轻了多少负担。围绕可衡量的公共成果和不可谈判的质量属性（WCAG 无障碍性、简明语言、安全性）来框定项目，并让探索证据（包括与使用辅助技术的用户进行的可用性测试）成为监督机构可以审计的记录的一部分。把成功定义为纳税人或公民层面的结果，而不是交付了多少模块，这样”我们按照合同规定建造了它”就永远无法替代一个从未真正实现的结果。

案例

初创企业。 一个为美发沙龙开发排班应用的四人种子期团队，因为有几位声音很大的用户提出要求，很想去构建一个在线预约小组件。他们没有这么做，而是花一周时间做探索：五次店主访谈，一个在营销网站上的假门”在线预约”按钮，以及一个单一的先导指标（以爽约收场的预约所占的百分比）。访谈和点击数据揭示出，真正的痛点是爽约，而不是预约本身，于是他们写下一条 SMART 关键结果（本季度把试点沙龙的爽约率从 22% 降到 10% 以下），先交付一个小型的”预付定金加提醒”功能，并在写下预约小组件的一行代码之前就将其扼杀。

企业。 一家零售银行的支付部门用三个季度性 OKR 取代了一份按功能数量列出的路线图，其中一个是”让日常支付感觉像是瞬间完成”，配有关于 p95 转账确认时间、首次尝试成功率和与支付相关的支持联系量的关键结果。系统质量属性被提前规定好（99.99% 可用性、亚秒级确认、把 PCI-DSS（支付卡行业数据安全标准）适用范围最小化），并以适应度函数的形式接入交付流程。探索环节在投入工程资源之前，每周都进行客户访谈和假门测试。两个候选功能因未能推动先导指标而在探索阶段被扼杀（据估计节省了两个季度的构建工作量），而一个规模较小、并不起眼的延迟修复，反而对关键结果的推动最大。

政府。 一家国家税务机构在推动在线报税现代化时，设定了一个项目目标（）“减轻普通纳税人的报税负担”，配有 SMART 关键结果：把中位报税时间从 45 分钟缩短到 20 分钟，把成功的自助完成率从 60% 提高到 85%，并把满足 WCAG 2.2 AA 级和简明语言标准作为不可谈判的质量属性。KPI（报税季期间的正常运行时间、呼叫中心话务量）被作为护栏来监控。探索环节在每次发布之前，都会与真实纳税人（包括使用辅助技术的用户）进行有主持人引导的可用性测试。因为成功被定义为纳税人层面的结果，而不是交付了多少模块，该项目能够向监督机构展示可衡量的公共价值，而不仅仅是花费了多少钱。

商业案例：动机、投资回报率与总拥有成本

探索流水线的回报，主要体现在被避免的浪费上。行业经验（在大型科技公司的受控实验项目中也得到了印证）一再发现，被构建出来的功能中有相当大一部分（常被引用的数字在一半或更多）没有产生任何可衡量的改善，甚至对目标指标产生了负面影响。假设即使只有四分之一的团队构建能力，被用在了探索本可以廉价扼杀的想法上，这条流水线也能带来数倍于其成本的回报：一周的用户研究和一次假门测试的代价，与一个季度的工程投入相比几乎可以忽略不计，更不用说一个无人使用的功能所带来的持续维护负担。

总拥有成本（TCO）这一框架之所以重要，是因为未经验证的功能在上线之后并不是免费的。每一个已交付的功能都背负着永续的成本：维护、测试、安全暴露面、支持，以及认知负荷（第 10.4 章）。在探索阶段扼杀一个糟糕的想法，不仅能避免构建成本，还能避免整条所有权尾巴上的成本。明确的质量属性遵循同样的逻辑：提前把可靠性和无障碍性规定为 SMART 目标，要比在一次故障、一次数据泄露或一场诉讼之后再去弥补便宜得多。

要向领导层证明这一点，把对话从”我们交付了多少”转向”我们在多大程度上推动了那些真正重要的指标”，并展示几个具体的例子：某个代价高昂的功能却什么都没推动。采纳这套做法的成本是适度的（研究能力、一个 OKR 节奏，以及撰写 SMART 标准的纪律），而不采纳它的主要风险则是无声的、未被计算的，并且会不断累积。

反模式与陷阱

伪装成战略的功能路线图： 产出清单，没有陈述任何成果或度量指标。
实为任务的关键结果： “上线 X”，而不是”把 Y 改善 Z”。
OKR 表演： 目标写好、归档，却从未被评审或打分。
被故意压低或不切实际的 OKR： 目标设定得保证能达成 100%（什么也没学到），或者是没有任何计划的幻想式远大目标。
未被规定的质量属性： 可靠性、安全性和无障碍性被假定，而不是被量化，然后在生产环境中才被发现。
虚荣指标： 总是上升、却什么也预测不了的度量。
把探索当作一次性阶段： 前期做一次”探索冲刺”，之后就不再持续验证。
在测试假定之前就构建解决方案： 因为团队很自信，就跳过了最便宜的实验。
指标执念与古德哈特定律： 一旦一项度量变成了目标，它就不再是一个好的度量；用护栏型 KPI 来平衡它。

成熟度模型

第一级，启动（Initiate）： 工作被定义为路线图上的一系列功能，成功就是”我们把它交付了”。没有明确的成果度量或质量目标；探索即便发生，也是偶然的，决策由声音最大的意见驱动。
第二级，发展（Develop）： 部分团队有 OKR 和 KPI，另一些没有；目标虽然被陈述出来，但往往呈现产出的形态；质量属性被提及，但没有被量化。团队可能会运行一次性的”探索冲刺”，然后一旦开始构建就停止验证，因此这种实践是真实存在的，但在组织内并不一致。
第三级，标准化（Standardize）： 一个与战略对齐的一致 OKR 节奏、SMART 关键结果，以及明确规定、可测试的质量属性，被文档化并在全组织范围内被期望执行。探索是一项得到认可、配有人力的活动，有假设和实验，并且为每个项目识别具有架构意义的需求，而不是想当然地假定。
第四级，管理（Manage）： 整个投资组合都依据基线被度量。先导指标和滞后指标、探索的命中率，以及每一个已交付赌注实际推动的成果，都会依据其 SMART 目标被跟踪；假设依据证据被评分，终止标准被强制执行；适应度函数持续报告质量属性的符合情况，因此对某个既定的可靠性、性能或无障碍性目标的偏离，会通过数据被捕捉到，而不是在一次事故中才被发现。
第五级，协同（Orchestrate）： 持续的双轨探索与投资组合、风险和预算编制整合在一起；经过验证的赌注稳定地流向交付，成果指标自动循环回来，指导下一轮工作。先导指标引导投资方向，组织会依据证据常态化地退役、重新界定和再平衡各个项目，并随着市场和指标的变化不断调整流水线本身。

讨论思路

看看你当前的路线图：有多少条目陈述了一个可衡量的成果，而不只是一个要交付的功能？
你团队的哪些关键结果其实是伪装过的任务，你会如何重新表述它们？
你的产品依赖哪些从未被明确量化过的系统质量属性？
什么样的最便宜实验，本可以在你们构建它之前就扼杀掉你们最近一次失败的功能？
你如何化解预算/采购要求的坚定承诺与良好成果所需要的学习之间的张力？
你的哪些 KPI 即使在产品变得更糟的情况下也会持续上升？

关键要点

探索流水线决定的是什么和为什么，并在交付投入资源之前定义成功。
用 OKR 表达你想要的改变，用 KPI 表达你必须维持的健康状况，并把指标分类为先导或滞后。
把系统质量属性当作明确的、量化的、可测试的需求来对待，而不是假定。
让每一个目标、关键结果和验收标准都符合 SMART 原则。
让探索与交付持续并行运行；廉价地验证风险最高的假定。
主要的投资回报体现在被避免的浪费上：既包括构建成本，也包括未被使用的功能所带来的永续总拥有成本。
闭合循环：交付出的成果指标（第 11.2 章）是下一轮探索最主要的证据。

参考文献与延伸阅读

Measure What Matters, by John Doerr (on OKRs).
Radical Focus, by Christina Wodtke (on OKRs in practice).
Continuous Discovery Habits, by Teresa Torres (opportunity-solution trees, dual-track discovery).
Inspired and Empowered, by Marty Cagan (product discovery and outcome teams).
Lean Analytics, by Alistair Croll and Benjamin Yoskovitz (leading indicators, vanity metrics).
The Lean Startup, by Eric Ries (build-measure-learn, validated learning).
Escaping the Build Trap, by Melissa Perri (outcomes over outputs).
Outcomes Over Output, by Joshua Seiden.
Software Architecture in Practice, by Bass, Clements, Kazman (quality attributes).
Doran, G. T., “There’s a S.M.A.R.T. way to write management’s goals and objectives” (Management Review, 1981): origin of SMART criteria.