如何为你真的发得出去的首个版本划定范围

一个拖了八个月的首版，很少是因为团队干得慢。几乎总是因为一个从一开始就活不下来的范围，而它是在一间"裁剪会被当成悲观"的会议室里被敲定的。

划定范围是一项技能，而它主要是"在所有人还很乐观的时候，决定不做什么"的技能。

从那一个循环开始

每个产品都有一个核心循环：用户反复进行、并由此产生价值的那串动作。词典是查、读、懂。交易市场是发布、发现、成交。

把你的循环写成一句话。然后把每一个被提议的功能分成两堆：循环要能跑起来所必需的，以及其余的一切。

第二堆几乎总是比人们预想的大四到五倍，而你的工期就消失在那里。不是因为那些功能不好，而是因为没有一个是承重的，却每一个都被排进了日程。

"MVP"已经不再有意义

这个词现在同时覆盖两种互不相容的东西：一个刻意做小、但在一件事上确实很好的产品；以及一个做得很宽、但做得很糟的产品。后者才是大多数团队实际发布的东西，而它失败的原因是：用户会原谅一个窄的产品，但不会原谅一个坏的产品。

更有用的说法是：窄而完整。更少的东西，每一样都做到位，包括错误状态和空状态。一个把一件事做全的首版，会赢得做第二版的资格。一个把八件事做到 60% 的首版不会。

裁范围，别裁质量。裁质量在计划书上是看不见的，在用户那里是极其显眼的。

通常该裁掉的东西

那些看起来必不可少、而几乎总是能等的东西：

• 账号系统，如果没有它价值也成立。 注册是大多数漏斗里最大的一处流失。先让人用起来，等到有值得保存的状态时再加账号。
• 后台管理界面。 你不是用户。一个数据库客户端或一段脚本，能顶好几个月。
• 设置项。 每一个偏好都是一条要开发也要测试的行为分支。选一个合理的默认值；等有人来问再加开关。
• 新手引导流程。 一个引导教程往往是给"不够明显的界面"打的补丁。先修界面。
• 第二个平台。 先 Web 再移动，或者先一个移动平台再另一个。两个同时做会让工作量不止翻倍，还把拿到反馈的速度砍半。
• 多语言。 除非某个具体市场就是发布市场。翻译一个还在变形的产品，意味着以后要重翻。

三样不该裁的东西

裁掉这些看起来像速度，实际是高利率的债。

1. 不顺利的路径

错误状态、空状态、加载状态、离线。它们大约占工作量的五分之一，却占了感知质量的大部分。一个能体面处理失败的产品，即使很小也让人觉得扎实。一个出问题就白屏的产品，无论顺利路径做得多好，都让人觉得坏了。

2. 度量

不带统计就发布，你的首版什么也教不了你。你不会知道哪些部分被用了、人们在哪里停下、循环有没有闭合。你不需要一个数据仓库；你需要知道核心循环是否走完，以及它在哪里断掉。

3. 快速部署的能力

如果发一个修复要花一天手工操作，你就会少发修复，而发布后的头几周恰恰是修复最重要的时候。一条基本的流水线花两天时间，在头两周就能回本。

按用户旅程切片，不要按分层切

最常见的规划错误是横向建设：先做完所有数据模型，再做完所有 API，再做完所有界面。在一切都能跑之前没有任何东西能跑，而在最后之前你什么也学不到。

改成纵向切片。先端到端造出一条完整的路径，薄但是真的，然后把它加宽。第二周结束你就有了能点的东西。那会把讨论从"想象这个产品"变成"对它作出反应"，而有用的反馈就在后者里。

一个现实的形状

对一个聚焦的首版，大致是：

窄而完整的东西总共八到十六周。如果你的计划写着用六周做一个很宽的东西，那错的是范围，不是估算。

把裁掉的东西写下来

一个零成本、却能阻止一场反复上演的争论的习惯：维护一份明确的"不进 v1"清单，所有人可见，每条附一行理由。

它把"我们忘了"变成"我们决定了"，阻止同一个功能每个月被重新翻出来讨论，并且成为你的 v2 待办清单，而且已经按你们上下文最充分时的那场讨论排好了序。

好范围的检验

两个问题，你需要两个都是"是"：

• 如果只造这些，会有人用吗？ 如果不会，你裁掉了承重的东西。
• 在现有时间里，我们能把这些做到位，包括那些不顺利的路径吗？ 如果不能，继续裁。

大多数计划都过不了第二个问题，而在第十周之前没人会说出来。