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