一抹斯文的粉笔灰做AB测试这几年，我越来越觉得，AB测试最难的从来不是统计显著性，而是让产品、运营、开发、数据四拨人在同一个节奏里干活。这篇就当第13期复盘，重点聊聊团队协作这件事。起因是去年我们有一个挺重要的改版实验：产品判断方向没问题，开发提前两天就切了全量流量，数据同学到周末才从看板里发现有个核心埋点少传了参数，最后整个实验只能标记成无效。不是哪个人的技术不行，而是流程接口决定结果。如果你正在带实验团队，或准备在公司里推动AB测试机制落地，这篇内容应该能帮你少走不少弯路。
1. 需求一句话，实验跑半年：协作上最大的隐患，往往从源头就埋下了
很多团队把AB测试当成“一个功能上线后顺便看一眼数据”，所以压根没有把实验当作一个需要多人协作推进的项目来管理。等到实验跑起来，需求方、开发、数据各按各的理解执行，问题就开始堆积。源头上的乱，会顺着流程一路放大。
1.1 “上了看看效果”不叫实验需求，叫事故预告
我曾经收到过一条相当典型的实验需求：运营同学想调整push推送时间，Brief只写了一句话——“现在20点发push，我想改成21点测试一下”。我问了三件事：想提升的指标是点击率还是次日留存？目标用户是所有活跃用户，还是只看近7天未回访的用户？准备跑多久，什么算赢？对方一个都答不上来。
这不是个例。很多需求方把AB测试当成了“换个方案碰碰运气”，脑海里只有一个模糊方向，没有把假设、目标、受众、判断标准想清楚。一旦这种需求被开发接走，结果往往是：开发按自己的理解做了改动，数据按自己的猜测埋了点，最后实验周期拖得很长，跑出来的数据却谁也解释不了。
我后来在团队里立了一条规矩：凡是不能一句话说清“我改了什么、希望影响谁、拿哪个指标判断输赢”的实验需求，不进入排期。这条规矩看起来严格，实际上帮所有人省了很多时间。实验需求不需要长篇大论，但它必须是一个可被验证的假设，而不是“试试看”。
1.2 实验Brief不用写成长篇论文，但五个问题必须回答
后来我们整理了项目协作中通用的一页纸实验Brief，要求和实验一起创建。发现只要把这个Brief填完，后面80%的协作摩擦都会提前消失。Brief里其实就五个问题：
- 背景：现在用户的行为数据是什么样？哪个环节不够好？
- 假设：我们准备改变哪一件事，预期哪个指标发生变化？变化的幅度预估是多少？
- 实验对象：实验在哪个用户群体里做？是全量用户、新用户，还是近7天活跃但近期没有下单的用户？
- 实验方案：对照组是什么、实验组是什么？流量分配打算用几比几？
- 判断标准：用哪个主指标做最终决策？最短运行多长时间？不允许低于多少样本量？
比较关键的一点是“预期变化幅度”这一栏。很多人不愿意填，因为填了就有被考核的风险。但如果没有预估效应量，数据同学根本算不出最小样本量，实验周期也就只能靠拍脑袋。反过来，即便最后实际效果和预估不符，只要复盘时把预估值和实际值放在一起看，也能看出业务判断哪里出了问题。这不是为了追责，而是为了让假设在校准中越来越准。
1.3 需求评审不该只评审“该不该做”，更该评审“能不能得出结论”
不少团队的实验评审会，演变成了“老板拍板会”。会上讨论最多的是按钮应该用红色还是蓝色、这个活动要不要上，而不是这个实验在技术上是否成立。有一次我们评审一个首页弹窗实验，业务同学坚持要全量上线，理由是“之前做过类似实验效果不错”。我问了一个问题：之前的实验结果，实验组和对照组的流量均不均衡，样本量也远小于标准，这个结论本身就不够可信，你现在用它来支撑新方案，判断依据从哪来？
AB测试的评审逻辑和普通的方案评审是不一样的。普通评审只需要判断“这个方案好不好