研发改进实验的核心做法是：先从一个可度量的效能指标里挑出具体问题，写出改进假设和预期变化，固定实验范围、周期与对照方式，再小范围执行并记录过程数据，最后用同一口径对比结果，决定推广、调整还是停止。整个过程的关键产物是实验卡、过程记录和复盘结论，指标口径必须在实验开始前固定，否则事后很难判断变化来自改进动作还是统计方式。
要点总览（TL;DR）
- 选题从已有度量数据里的异常点出发，把问题写成含指标、现状和影响范围的一句话，再判断它是否适合做实验。
- 实验开始前用实验卡固定假设、主指标、护栏指标、范围、周期和对照方式，指标口径一旦确定，执行期间不做实质性修改。
- 执行期按周记录动作落地情况、干扰因素和异常事件，基线与实验期使用同一数据来源和排除规则，保证前后可比。
- 复盘时先做数据对比，再判断指标变化与改进动作的关系，按推广、调整、停止三类触发条件给出结论并写明限制。
- 实验结束前逐项核对假设是否事前固定、数据是否完整、结论是否有支撑、记录是否可检索，确保实验可判定、可复用。
先定实验对象：从度量数据里挑一个可改的问题
改进实验的起点是一个具体、可观测的异常，而非“提升研发效能”这类笼统目标。团队可以先翻看已有的度量数据，从中寻找偏离常态的点。常用的观察对象包括需求交付周期、缺陷密度、发布频率和返工率：交付周期在某个环节明显拉长，缺陷密度在某个版本后持续上升，发布频率长期低于计划，返工率集中在某类需求上，这些都是可以进一步追问的线索。
找到异常点后，需要判断它是否落在度量驱动改进的范围内。适合做实验的问题通常满足三个条件：有可重复采集的数据来源，问题与团队的具体做法相关，改进动作能在数周内落地。如果异常主要来自外部依赖、组织审批或人员大幅变动，单靠团队调整工作方式难以改变，就不适合作为本轮实验对象。
接下来把问题写成一句可验证的表述，包含指标、现状和影响范围。例如“支付模块需求从开发完成到上线的平均等待时间为6天，高于团队其他模块的3天，导致该模块每月约四分之一的需求延期交付”。这句话说明了看哪个指标、现状是多少、影响了谁，后续的假设和对比都围绕它展开。
问题定义清单可以按以下结构整理，作为实验卡的输入：
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 指标名称 | 选定的度量指标及统计口径 | 需求交付周期，从需求进入开发到上线的时间 |
| 现状值 | 最近一个统计周期的数值 | 支付模块平均6天，其他模块平均3天 |
| 异常表现 | 偏离常态的具体现象 | 上线前等待时间长，集中在测试环境排队 |
| 影响范围 | 受影响的团队、项目或需求类型 | 支付模块，近两个月约四分之一需求延期 |
写实验卡：假设、指标、范围、周期一次说清
实验卡的作用是让实验在开始前就有可核对的依据，避免执行到一半才发现指标没定义清楚。一张完整的实验卡至少包含问题、假设、主指标、护栏指标、实验范围、周期、对照方式和负责人。
假设采用“如果采取某动作，则某指标将从A变化到B”的句式。A是基线值，B是预期目标，两者都要有明确口径。例如“如果将支付模块的需求拆分为开发完成即进入测试的小批次交付，则需求交付周期将从平均6天降到4天以内”。假设中的动作要具体到可执行，目标值要合理，既不能低到没有改进意义，也不能脱离团队实际能力。
主指标用于判断实验是否成功，只选一个，避免多目标互相干扰。护栏指标用于确认改进没有带来明显副作用，例如在缩短交付周期的同时，观察缺陷密度是否上升、线上事故是否增加。护栏指标不要求改善，但需要设定可接受的边界。
实验范围要写清参与的团队、项目和需求类型，周期要给出起止日期和统计窗口。对照方式根据条件选择：能设置平行团队时，用相似团队做对照；不具备平行条件时，用实验前的历史数据做前后对比，并在结论中说明这一限制。负责人需要明确到人，参与角色包括执行团队、数据负责人和复盘主持人。
| 字段 | 填写要求 |
|---|---|
| 问题 | 一句可验证的问题表述，含指标、现状和影响范围 |
| 假设 | 如果采取某动作，则某指标将从A变化到B |
| 主指标 | 一个判断成败的指标，写明统计口径和基线值 |
| 护栏指标 | 一至两个副作用观察指标及可接受边界 |
| 实验范围 | 团队、项目、需求类型 |
| 周期 | 起止日期、数据统计窗口 |
| 对照方式 | 平行对照或前后对比，并注明局限 |
| 负责人 | 实验发起人、数据负责人、执行团队代表 |
执行与记录：让过程数据能支撑结论
实验执行期最重要的工作是保证数据可比。基线数据和实验期数据必须使用同一统计口径：同一个指标定义、同一数据来源、同一统计周期和同样的排除规则。如果基线按自然周统计，实验期也按自然周统计；如果基线排除了紧急插单，实验期也要用同样规则处理。口径一旦在实验中途调整，前后对比就失去意义。
过程记录需要覆盖三类内容。第一类是动作执行情况，记录计划中的改进动作是否按预期落地，哪些需求走了新流程，哪些没有。第二类是干扰因素，例如人员请假、版本封板、外部依赖延迟，这些因素可能影响指标但不属于实验动作。第三类是异常事件，例如线上故障、需求范围临时变更，需要记录发生时间和影响范围。
执行期间设置周中检查点，由数据负责人核对数据采集是否正常、动作执行是否偏离计划。发现偏差时先判断偏差性质：属于执行不到位，及时纠正并在记录中注明；属于外部干扰，记录影响并评估是否需要延长实验周期；属于指标口径问题，原则上不中途修改，而是在复盘中说明并作为下一轮实验的改进点。
实验执行记录表可以按周填写，包含日期、计划动作、实际执行情况、指标当期数值、干扰因素和异常事件。记录由执行团队指定人员填写，数据负责人核对数值，实验发起人每周查看一次整体进展。
复盘与判定：推广、调整还是停止
实验结束后，先做数据对比。前后对比看实验期指标相对基线的变化幅度，同时检查护栏指标是否越界。有平行对照时，比较实验组与对照组的差异，并确认两组在实验前的基线是否接近。无论哪种方式，都要把变化幅度与统计窗口内的正常波动做比较，避免把小幅波动当成改进效果。
判断因果关系需要满足几个基本要求：改进动作确实在执行期落地，指标变化的时间点与动作实施时间吻合，护栏指标没有出现无法解释的恶化，且没有明显的替代解释。如果实验期同时发生了组织调整、人员更替或需求结构突变，结论中必须写明这些限制，不能把指标变化全部归因于改进动作。
复盘结论分为三类。推广的触发条件是主指标达到或接近预期目标，护栏指标在边界内，且执行记录显示动作落地情况良好。调整的触发条件是主指标有改善但未达目标，或护栏指标出现需要处理的副作用，此时保留有效部分，修改动作设计后进入下一轮实验。停止的触发条件是主指标没有改善，或改善伴随不可接受的副作用，或实验过程数据不足以支撑判断，此时记录原因，避免重复投入。
| 结论 | 触发条件 | 后续动作 |
|---|---|---|
| 推广 | 主指标达到预期，护栏指标在边界内，动作落地良好 | 扩大到更多团队或项目，更新团队工作约定 |
| 调整 | 主指标部分改善，或护栏指标出现副作用 | 保留有效动作，修改设计后开始下一轮实验 |
| 停止 | 主指标无改善，副作用不可接受，或数据不足 | 记录原因和限制，释放资源，转向其他问题 |
复盘结论的沉淀形式包括一页复盘记录和更新后的实验卡。复盘记录写明实验背景、执行情况、数据结果、结论类型、限制条件和后续建议，存入团队可检索的文档空间，供后续实验参考。
角色分工与交付物：谁在什么时候交出什么
实验涉及四类角色。实验发起人通常是团队负责人或效能改进的推动者，负责选题、组织实验卡评审、在复盘时做最终决策。数据负责人负责确认指标口径、采集基线和实验期数据、核对记录表中的数值。执行团队负责按实验卡落地改进动作，并填写过程记录。复盘主持人可以由发起人兼任，也可以由不直接参与执行的成员担任，负责组织复盘会议、汇总结论。
| 角色 | 主要职责 | 交付物 | 提交时点 |
|---|---|---|---|
| 实验发起人 | 选题、组织评审、最终决策 | 问题定义清单、实验卡 | 实验开始前 |
| 数据负责人 | 确认口径、采集与核对数据 | 基线数据、数据采集口径说明 | 实验开始前及每周 |
| 执行团队 | 落地改进动作、填写过程记录 | 实验执行记录表 | 每周及实验结束 |
| 复盘主持人 | 组织复盘、汇总结论 | 复盘记录、处置决策表 | 实验结束后一周内 |
跨团队实验需要额外约定协作接口：由发起团队的数据负责人统一口径，各参与团队指定一名联系人负责本团队的动作执行和数据提交，周中检查点由各联系人汇总后统一核对。实验卡和复盘记录放在参与团队都能访问的共享空间，避免信息只留在个人手里。
当实验卡、过程记录和复盘结论需要在协作工具中承载时，可以把实验本身作为一个工作项管理：实验卡作为工作项描述或关联文档，过程记录按周追加，复盘结论作为关闭前的必填内容。ONES Performance 提供交付效率、交付质量、资源效率、完成情况等维度的效能数据展示，并自动收录系统内流转的研发数据形成分析指标，团队可以直接用这些数据确认基线和实验期数值，减少手工整理数据源的工作；实验卡与复盘记录则可以放在项目文档中，与相关工作项关联，便于后续检索和复用。
一个完整示例：缩短需求交付周期的实验
以下为演示情景，数据为示例，用于说明各字段如何填写，不代表真实团队的实际结果。
问题与基线。某团队负责会员模块的需求开发，近两个月需求交付周期平均为9天，其中开发完成到进入测试的平均等待为3天，测试到上线平均为4天。团队其他模块的交付周期平均为6天。问题表述为：“会员模块需求交付周期平均9天，高于团队其他模块的6天，主要等待发生在开发完成到进入测试之间。”
实验卡填写。假设：如果将开发完成的需求改为每日固定时间批量移交测试，并提前一天同步测试范围，则会员模块需求交付周期将从平均9天降到7天以内。主指标为需求交付周期，口径与基线一致。护栏指标为缺陷密度，边界为不高于实验前水平的两成。实验范围为会员模块的开发与测试人员，周期为六周，对照方式为与团队其他模块做平行对比，同时参考实验前历史数据。负责人为模块负责人，数据负责人为团队效能接口人。
执行期记录要点。第一周记录每日移交是否按计划执行，有几天因需求未完成而顺延；第二周记录测试环境排队情况；第四周记录一次线上故障对测试进度的影响。每周记录当期交付周期和缺陷密度，数据负责人核对口径未变。
复盘结论。实验期会员模块平均交付周期为7.4天，较基线下降1.6天，但未达到7天以内的目标；缺陷密度与实验前基本持平，护栏指标未越界。执行记录显示每日移交在四周内有三周正常执行，一周因版本封板中断。结论为“调整”：保留每日移交动作，补充封板期的移交规则，下一轮实验将目标设为7.5天以内并延长两周观察。复盘记录存入团队文档，实验卡更新后归档。
完成检查：实验是否可判定、可复用
实验结束前，用以下清单逐项核对，确认结论有依据、经验可复用。清单中的每一项都应有对应的文档或数据可以查证，口头确认不算完成。
- 假设、主指标、护栏指标和统计口径是否在实验开始前写入实验卡，执行期间未做实质性修改。
- 基线数据是否覆盖实验前一个完整统计窗口，实验期数据是否覆盖整个实验周期，两者是否使用同一数据来源和排除规则。
- 过程记录是否按周填写，动作执行情况、干扰因素和异常事件是否都有记录，缺失的周次是否说明原因。
- 复盘结论是否写明数据结果、结论类型和限制条件，是否区分了指标变化与改进动作的关系。
- 推广、调整或停止的决策是否有对应的触发条件支撑，后续动作是否明确到负责人和时间点。
- 实验卡、过程记录和复盘结论是否存放在团队可访问的位置，命名和归档方式是否便于后续实验检索。
- 如果实验涉及工具中的数据统计，指标口径是否与工具中的实际定义一致，是否在实验前完成核对。
清单全部通过，说明这次实验达到了可下结论的质量；存在未通过项时，在复盘记录中注明缺口，并把补齐方式写入下一轮实验的准备事项。
常见问题
团队没有专门的数据分析人员，实验数据由谁负责？
数据负责人的核心工作是确认口径和核对数值，可以由团队里熟悉度量指标的成员兼任，例如效能接口人或迭代负责人。关键是把职责写进实验卡：实验前确认指标定义、数据来源和排除规则，实验期间每周核对记录表中的数值是否按同一口径采集。如果团队使用协作工具沉淀研发数据，可以由工具按既定口径输出指标，数据负责人把重点放在核对口径是否与实验卡一致，减少手工整理的工作量。
实验进行到一半发现指标口径定义错了，能不能直接改？
原则上不在中途修改口径，否则前后数据失去可比性，结论也无法成立。可行的处理是：保留原口径继续采集到实验结束，同时在过程记录中注明口径问题及其影响范围；复盘时把这一轮结论标记为受限，并将口径修正作为下一轮实验的准备事项。如果口径错误导致数据完全不可用，可以提前终止本轮实验，记录终止原因后重新设计实验卡，避免在错误数据上继续投入。
小团队找不到平行对照团队，实验结果还可信吗？
不具备平行对照条件时，可以用实验前的历史数据做前后对比，但需要在实验卡和复盘结论中写明这一限制。提高可信度的做法包括：基线取足够长的统计窗口以覆盖正常波动，实验期与基线使用同一口径，记录实验期间发生的组织调整、人员变动等替代解释，并观察指标变化的时间点是否与改进动作实施时间吻合。结论表述上宜写成“在本实验条件下观察到变化”，避免直接断言因果关系。
一轮实验结束后，调整后的动作要不要重新走一遍完整流程？
建议重新填写实验卡，而不是在原实验上直接延长。调整类结论通常意味着动作设计有变化，主指标目标、实验范围或周期也可能随之改变，重新写实验卡可以把新的假设和口径固定下来，避免与上一轮数据混在一起。上一轮的复盘记录作为附件关联，说明哪些动作保留、哪些修改、依据是什么。这样每一轮实验都有独立的起止边界，后续检索和复用也更清晰。
实验卡、过程记录和复盘结论放在哪里，才能被后续实验用上？
存放位置要满足两个条件：参与实验的成员都能访问，后续做类似实验的人能检索到。常见做法是在团队的项目空间里为实验建立独立的工作项或文档，实验卡作为描述或关联文档，过程记录按周追加，复盘结论在关闭前补齐，并用统一的命名规则标注实验主题和时间。ONES Performance 提供交付效率、交付质量、资源效率、完成情况等维度的效能数据展示，并自动收录系统内流转的研发数据形成分析指标，团队可以用这些数据确认基线和实验期数值；实验卡与复盘记录放在项目文档中与相关工作项关联，便于后续检索和复用。
