拉动与 MVP 是什么
拉动式计划按团队实际容量拉取工作，而不是按愿望把工作推入队列：完成一批再拉下一批，让承诺量与实际吞吐匹配。MVP（最小可行产品）是验证关键假设的最小实验，围绕可测假设设计，规模小但结论明确。两者的共同点是把「做了多少」换成「验证了什么」：拉动控制输入节奏，MVP 保证投入对应可判断的结论。
基本信息
| 拉动原则 | 完成再拉新的，容量决定承诺量，队列长度受控 |
|---|---|
| MVP 目的 | 验证关键假设，而不是缩小版的全功能产品 |
| 设计顺序 | 先写要验证的假设与成功标准，再决定实现范围 |
| 后续决策 | 按实验结论决定扩展、转向或停止 |
| 常见误区 | 把 MVP 理解成功能删减版，验证周期被拉长 |
典型使用场景
- 新业务方向投入前需要低成本验证用户需求是否真实存在
- 团队长期超载交付延期，需要按容量重新校准承诺量
- 需求队列堆积上百条，需要限制在制量并让优先级真正生效
- 功能上线后使用率低，需要复盘是否缺少假设验证环节
- 探索性项目需要向管理层说明继续投入或停止的依据
实验设计三问
实验设计三问
假设：我们相信什么、为什么相信，依据来自哪里
指标：用什么数据判定成败，阈值与观察周期是多少
决策：结论触发什么动作——扩展、转向还是停止
补充：确认实现范围是最小验证集，而不是功能删减版拉动与推式对比
| 维度 | 拉动式计划 | 推式计划 |
|---|---|---|
| 承诺依据 | 团队实际吞吐与容量 | 愿望与总体需求清单 |
| 队列状态 | 受控，在制量有上限 | 持续堆积，优先频繁变化 |
| 可预测性 | 按历史数据给出区间 | 按计划日期承诺，偏差大 |
| 成员状态 | 任务聚焦，切换少 | 多头并行，切换频繁 |
实验的结论可以是停止：及时停止无效探索同样是价值，前提是停止决定有明确的判断依据而不是情绪化的转向。