Skill: 小批量原则
Metadata
- ID: leanstartup-007
- 类型: framework
- 来源: 《精益创业》第九章
- 验证状态: ✅ 三重验证通过（V1: 9章完整+多案例, V2: 开发效率核心, V3: 反直觉）
R — Reading（原文引用）
"用大批量的话，我们一直要到接近流程终点才会发现问题。而用小批量的话，我们几乎能马上发现问题。"
"这个结果在很多研究中已经得到证实：一次封装一个信封看似较慢，却能更快地完成工作。"
I — Interpretation（方法论骨架）
小批量的反直觉洞察：慢即是快，少即是多。
大批量的诱惑：看起来效率高——可以专注做一件事，不用反复切换。
大批量的代价：
- 反馈周期拉长到几周甚至几个月
- 错误在后期才暴露，修正成本成倍增加
- 团队在"错误方向"上投入了大量资源
小批量的本质：
- 把大工作拆成小块，每完成一小块就获取一次反馈
- 不是"把事情做完才交付"，而是"持续交付，持续验证"
小批量的极致 = 持续部署/持续交付。
A1 — Past Application（书中案例）
信封实验：父亲一次装一个信封赢了比赛，因为孩子们大批量处理（折100个→封信口100个→贴邮票100个），但中途发现问题只能最后返工；父亲发现问题立刻调整，总时间反而更短。
丰田的精益生产：丰田面对资源匮乏，无法像美国工厂那样大批量生产。被逼走上小批量道路，最终发现这种方法比大批量更高效——因为能快速发现问题，不用在错误的基础上继续投入。
财捷TurboTax的快速实验：每周进行70项不同的测试，每次测试周期只有几天。每个测试完成后立即分析结果，周四部署新测试，周一看数据，周二决策。传统软件公司的产品开发周期是季度或年度，财捷是每天。
A2 — Future Trigger（何时调用）
当你听到以下问题时，就应该调用这个Skill：
- "产品开发了好几个月，但还没有给用户看过"
- "开发团队说'等发布再看看市场反应'"
- "我们花了半年做的功能，用户反馈完全不是我们预期的"
- "团队感觉工作很忙，但产品好像没有进展"
- "每次发布都像一场战役，因为积累了大量改动"
E — Execution（可执行步骤）
步骤1：识别大批量行为
信号：
- 产品开发的某个阶段超过2周没有任何用户接触
- 团队说"功能做完了，等发布日期"
- 一次性发布大量功能，而不是逐个验证
- 错误/问题总是在发布前一周才集中爆发
步骤2：拆解大批量为小批量
原则：每个批量的完成标志是获得了关于这个批量的用户反馈，而不是"代码写完了"。
方法：
- 产品功能：拆成"核心功能+次要功能"，先发布核心，验证后再加
- 开发任务：把"开发→测试→发布"的大循环，变成每个功能的小循环
- 会议/决策：把大议题拆成小议题，逐个解决，逐个确认
步骤3：测量批量大小的影响
问题：当前从"想法"到"用户反馈"需要多长时间？
- 目标：越短越好，核心功能≤1周
- 如果>2周，问："能否拆成更小的部分发布？"
步骤4：建立持续反馈机制
- 持续部署：代码合并后自动发布到测试环境
- A/B测试：每次发布都是一个实验
- 快速回顾：每1-2周回顾"这批工作和预期相比如何"
B — Boundary（何时不适用）
| 不适用场景 | 原因 |
|---|---|
| 硬件/制造业 | 物理产品的小批量成本远高于软件 |
| 合规要求严格的产品 | 医疗/金融产品的发布需要完整审批流程 |
| 极其稳定的业务 | 这类业务的大批量发布反而成本更低 |
作者盲点提醒：小批量需要组织文化支持——如果团队习惯于"功能完成后才算成绩"的绩效考核，小批量会让团队感觉"什么都没完成"。需要在绩效评估上同步调整，让"快速验证"本身就是成绩。
关联Skills
- MVP构建法 — MVP是产品开发中小批量的极端实践
- Build-Measure-Learn循环 — 小批量让BML循环转得更快
- 对比测试 — 小批量发布后，用对比测试快速验证效果
