small-batch

name	small-batch
description	用小批量方式减少浪费、加速反馈。当产品开发周期过长、团队陷入"憋大招"困境、错误发现太晚导致返工量大时，使用此Skill。

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循环转得更快
• 对比测试 — 小批量发布后，用对比测试快速验证效果