塑造的第一步是设定我们试图做的事情的边界。如果人们认为我们在谈论一个小改进或一个重大重新设计，我们的对话将完全不同。

关于构建功能的讨论总是从一个 初始想法 开始，比如“客户要求群组通知”。在我们深入讨论如何解决这个问题之前，我们应该首先设定一些广泛的讨论条件，来让讨论富有成效。

设定胃口

有时一个想法会立刻让我们兴奋。在这种情况下，我们需要抑制这种兴奋，认认真真检查这件事情是否值得我们投入时间来做。如果我们不停下来思考这个想法的价值，我们可能会很快跳入要么承诺资源，要么进行长时间讨论潜在解决方案的境地，而这些讨论最终可能毫无结果。

其他的想法没有那么令人激动，感觉更像是一个不是我们主动请求的挑战。客户想要一个日历：我们并不特别想要构建一个，但我们确实需要对这个请求做些事情。

无论我们是迫不及待投入还是不愿意投入，明确界定这个主题值得多少时间和注意力还是很有帮助的。如果我们能解决，这是值得快速解决的问题吗？这是一个值得整个周期的大想法吗？我们会重新设计现有的东西来适配它吗？还是说我们将其作为一个小调整来实施解决？

我们称这个为“胃口”。你可以把胃口看作一个标准团队规模的时间预算。我们通常将胃口设定为两种大小：

• 小批量：这是一个由一名设计师和一到两名程序员组成的团队可以在一到两周内完成的项目。我们将这些项目分批放入一个六周周期内（后面会详细介绍）。

• 大批量：这个项目需要标准规模团队整整六周的工作时间。

在极少数情况下，如果项目范围太大以至于无法再六周内完成，我们会尝试通过缩小问题定义来压缩范围。如果我们仍然无法缩小范围，我们会拆分出一个有意义的部分，将其调整为六周的工作量。

固定时间，可变范围

胃口和估算截然不同。估算起于设计，止于数字。而胃口则是起于数字，止于设计。我们将胃口作为设计过程中的创造性约束。

这个原则，被称为“固定时间，可变范围”，是成功定义和交付项目的关键。以这本书为例。当你总是想要添加更多、解释更多、或者优化现有内容的时候，你很难交付。当你有一个截止日期，突然间你必须要做决定。只剩下一周的时候，我可以在修复错别字和为章节添加新内容之间做出选择。这就是时间、质量和范围之间的张力。我不想发布一本有尴尬错别字的书，所以我会选择去掉多余的小节来减少范围。如果没有固定截止日期的压力，我不会做出这种权衡。如果范围不可变，我将不得不包括额外的小节。那样的话就没有时间修复质量问题。

我们在流程的每个阶段都应用这一原则，从塑造潜在项目到构建和交付它们。首先，胃口限制了我们在塑造过程中设计的解决方案类型。之后，当我们将工作交给团队时，固定的时间框架迫使他们决定什么是项目的核心，什么是外围或不必要的。

“好”是相对的

从来就没有“最佳”解决方案的准确定义。最好取决于你的约束条件。如果你没有时间限制，总是会有最好的版本。终极的晚餐版本可能是十道菜的完美晚餐。但如果你很饿而且非常匆忙，热狗就是完美的。

我们为胃口设定的时间会引导我们找到不同的解决方案。我们可以在复杂版本中构建一整套数据库列，或者在简单版本中只提供一个简单的文本区域。我们可以重新设计主登录页面来适应新功能，或者我们可以将其放到一个更少的设计约束的新界面。我们只能够在有限时间和重要程度的条件下界定这个解决方案是否是个“好方案”。

回应原始想法

我们对任何想法的默认回应应该是：“有趣。再等等吧。”换句话说，这是一个非常温和的“不”，它让我们所有的选择都保持开放。我们不会把它放在待办事项中。我们给它空间，一遍我们可以了解它是否真的重要以及它可能涉及什么、

初次接触就回答“是”或“否”为时尚早。即便我们对此感到兴奋，也不应该在我们还没有理解的情况下就承诺投入。在想法被塑造之前，还需要对想法做更多工作进行优化。如果我们对收到的请求总是说“可以”，最终只会留下堆积如山的工作，而且还在不断增长。

保持冷静的态度和一点扑克脸很重要。我们不想在不理解一个想法的情况下就直接把它关掉。明天也许就有新的信息让我们以不同的方式看待它。另一方面，立即表现过多的热情会让人期待这件事一定会发生。一旦我们将它与我们想做的事情发在一起考虑的时候，我们可能无法承诺去做这些事情。

缩小问题范围

除了设定胃口之外，我们通常还需要缩减对问题的理解。

我们曾经有一位客户要求我们提供更复杂的权限规则。如果构建她要的这些功能轻轻松松就得花上六周。我们并没有直接接受这个请求，而是深入挖掘了需求。结果发现是有人在不知道后果的情况下就归档了文件，后果是所有使用这个系统的其他人都看不到这个文件了。我们并没有创建一个规则来阻止某些人归档，而是意识到在归档操作本身上加一个警告，解释其影响。这是一个只需要一天就可以完成的修改，而不需要整整六周的时间来完成。

另一个例子就是前一章提到的“日历视图”。每个人都知道日历视图是什么。但拆解它之后，发现了大量的未知因素和决策，这些都会极大地影响范围评估。如果我们只想花六周而不是六个月来构建一个庞大的日历，我们该如何缩小范围？

在这种情况下，我们就从“我们可以构建什么？”转到了“真正的问题是什么？”当然，日历听起来很诱人。但是是什么推动了这个请求？在没有人们所要求的这个功能下，他们在工作流的那个环节出现了问题而崩溃。

案例研究：定义“日历”

在对日历功能的请求案例中，我们联系了一位需要这个功能的客户。我们没有问她为什么她想要一个日历以及这个日历功能是什么样的，而是问她什么时候需要日历。她在想要日历功能的时候在做什么？

她告诉我们，她在一个办公室里工作，办公室里有一面大日历画在黑板墙上。她的同事们在日历上标记了他们何时在几个会议室里会见客户。有一天，她在家工作。一个客户打电话来要求安排会议。她不得不开车去办公室查看墙上的日历。路上的交通非常糟糕，最后没有找到合适客户的开会时间。如果她能够在家里的电脑上查看日历上的空闲时间，她本可以节省一个小时的交通时间和很多烦恼。

这个洞察并不是“将日历电脑化”——这是显而易见的。我们学到的是，对于这个用例来说，“查看空闲时间”才是重要的，而不是“做日历能做的一切”。

这个故事，以及其他类似的故事，为我们提供了一个特定的基线来设计。Basecamp 有一个事件议程视图。它适用于列出主要截止日期和里程碑，但不适用于资源调度，因为你无法在上面看到空白空间。我们将需求从“做日历所做的一切”缩小到“帮助我看到空闲时间，以便我可以确定何时安排某事。”

我们还没有解决方案。但现在我们觉得我们有一个足够具体的问题，可以激发一个符合我们胃口的想法。这使我们想到了上一章中更简单的“点网格”概念。

如果我们无法确定一个具体的痛点或使用场景怎么办？我们的胃口也可以告诉我们多少研究是值得的。如果现在不关键，而且我们无法理解这个问题，我们会放弃它，转而处理其他事情。也许将来会出现一个新的请求或故事，让我们更好地理解这个问题。

注意大杂烩

当涉及到不明确的想法时，最糟糕的情况是那些并非由单一问题或使用案例驱动的“重新设计”或“重构”。当有人提出类似“重新设计文件部分”的建议时，那只是一个笼统的想法，而非一个项目。这将很难弄清楚它的含义、起点和终点。一个更有成效的起点是：“我们需要重新思考文件部分，因为共享多个文件需要太多步骤。”现在我们可以开始提问：哪些地方不奏效？在什么情况下步骤过多？现有设计的哪些部分可以保持不变，哪些部分需要改变？

“大杂烩”的一个明显标志是“2.0”标签。过去我们犯了一个错误，启动了一个“文件 2.0”项目，却没有真正考虑这意味着什么。我们对改进应用程序中一个重要部分的热情让我们失去了理智。我们知道文件功能存在很多问题，但我们没有问自己具体要做什么。结果这个项目变得一团糟，因为我们不知道“完成”是什么样子。我们通过将项目拆分为更小的项目来恢复，比如“更好的文件预览”和“自定义文件夹颜色”。我们为每个项目设定了目标和明确的期望，并成功发布了它们。

边界已到位

当我们拥有这三样东西——一个原始的想法、一种渴望和一个狭窄的问题定义——我们就准备好进入下一步，定义解决方案的要素。