5 章节3: 设定界限
雷欧雷欧 保存 显示目录
塑造的第一步就是为我们的目标设置好界限。我们是在讨论一个用于改进的小方案，还是一个需要重新设计的大工程，将使得我们的对话截然不同。
关于功能开发的讨论都是始于一个原始想法的，比如「用户要求群通知功能」。在我们掉进讨论解决方案的无底洞前，我们应该先设置一些宽泛的概念，以使之更有成效。
明确计划投入
我们常常会因为灵光一现而兴奋不已。在这种情况下，我们需要平复心情，检验一下这个想法是否真的值得我们投入时间。如果我们不假思索地就投入资源，可能只是在一些无用方案的讨论上浪费时间。
另外一些想法就不那么让人兴奋了，而且更像是我们非自愿接受的挑战。用户想要日历功能，但是我们并不太想去做一个日历，只是我们又觉得应该对这个要求做些回应。
不管是热情洋溢还是不情不愿，设定好界限都有助于我们明确可以投入的时间和精力。这个问题我们是否有把握快速解决？这是一个值得投入这个周期的构思么?我们需要去重新设计现有的内容么？如果小小的调整就能生效，我们会考虑么？
我们将其称之为预计投入。你可以将其看作是标准规模团队的时间预算。我们通常将预计投入划分为两种尺寸。
小分支：这类项目，由一名设计师和两名程序员组成的工作小组可以在一到两周内完成开发。我们将这些项目整合进一个六周循环周期（稍后详细介绍）。
大分支：同样规模的工作小组需要花费整整六周的项目。
在极少数的情况下，还会出现范围极大甚至已经超出了一个六周周期的项目，我们会尝试着缩小其范围，如果仍然无法将其缩小，我们会截取出最重要的部分，将这一部分塑造为一个可以在六周内完成的项目。
时间固定，范围可变
预计投入与预估是完全不同的。预估是起于设计，终于数字。而预计投入则是起于数字，终于设计。我们将预计投入作为设计过程中对于创造性的约束。
这就是「时间固定，范围可变」原则，这也是成功定义与发布项目的关键。就以本书为例，如果总是不断地增加内容、解释内容或者修改已有的内容，那么本书将很难顺利出版。但是当你有截止日期后，你就不得不做出取舍。当我只剩余一周的时间，我只能在检查错别字或者为章节添加新段落之间做出选择。这是关于时间、质量以及范围间的掣肘。而我不想出版一本有着尴尬的拼写错误的书，因此我只能舍弃掉额外的段落来缩小本书的涉猎范围。如果没有固定期限带来的压力，我就不会做出取舍。如果范围是不可变的，我必须加上额外的段落，我就会没有时间来解决质量问题。
这个原则我们应该用于整个流程的每一个阶段，从塑造潜在项目到开发和发布它们。首先，预计投入限制了我们在塑造阶段要设计出怎样的解决方案。之后，当我们将工作交给一个开发组，固定的时间限制会促使他们判断什么是项目的核心，什么是次要的或者没必要的。
「好」是相对的
什么是「最佳」解决方案，这是没有标准答案的。「最佳」是与约束条件相关的，如果没有时间限制，总能够做出更好的版本。终极晚餐或许会是满汉全席，但是当你饥肠辘辘时，有一根热狗就已经很完美了。
我们根据我们的预计投入而限定的时间会将我们引向不同的解决方案。我们可以在一个繁复的版本中为一整套数据库列建模，或者仅仅在一个简单的版本中提供一个平面文本区域。我们可以重新设计主要页面以适应新功能，或者我们可以将其回推至设计受限较小的页面。我们只能通过我们预计的时间投入以及项目的重要程度来决定什么是「好」的方案。
回应原始想法
我们对任何想法的第一反应都应该是：「有意思，说不定某天会用上」。换言之，一个委婉的「不」会留给我们更多的选择余地。我们不应该就将其放进待办事项中，而应该留出更多的空间来分析它是否重要以及它究竟是需求什么。
一开始就回答「是」或者「否」有些为时过早，即使我们对此感到兴奋不已，也不应该对还没有搞清楚的需求做出承诺。我们需要对这个想法进行研究，然后才能倾注资源。如果我们总是对接收到的请求说「是」，最终我们会得到一堆不断增长的工作。
保持冷静以及稍稍有些冷淡的态度是很重要的。我们不希望否决一个我们不理解的想法。因为明天可能就会有新的信息让我们产生不同的看法。另一方面，立刻表现得太过热情则会让人报以期望，但是当我们将这个请求同其它我们想做的工作关联起来后，我们恐怕就不能这样做出承诺了。
缩小问题范围
除了明确预计投入外，我们常常还需要缩小理解问题的范围。
曾经有一位用户要求我们提供更加复杂的权限系统，要开发她所需求的功能调整至少需要六个星期的时间。我们并没有停留在表象的需求上，而是进一步的做了需求挖掘。原来是因为有人对文件进行了归档操作，但是他不清楚这样会让其他使用该系统的成员也无法看见该文件。我们意识到我们需要做的是为归档操作增加一个警告，来解释这个操作可能带来的影响，而不是开发一个规则来防止一些使用者进行归档操作。这个改动只需要一天，而非六个星期。
另一个例子就是上一个章节中的「日历视图」。大家都知道什么是日历视图。但是将其展开思考后会发现大量的不确定因素和取舍抉择，这些会对范围造成很大的影响。如果我们希望只用六周而非六个月来开发一个大型日历，该如何缩小这个问题的范围呢？
在这种情况下，我们不再思考「我们能开发什么？」，而是「到底是什么出了问题？」日历功能听起来当然很棒。但是是什么导致了这个需求呢？在提出需求前，具体是在流程的哪一个点上导致了他们的工作中断。
案例研究：定义「日历」
在要求「日历」的案例中，我们联系了提出此要求的用户。我们没有问她为什么想要日历或者想要什么样的日历。而是询问她是在何时以及做何事的时候需要日历。
她告诉我们，在她办公室的黑板上画着一个很大的日历。她的同事会在日历上标记出他们有限的会议室的占用时间与占用情况。一天，她正在家中工作。她的客户联系她并需要安排一个会议。为此她不得不驱车前往办公室查看日历。那天的交通非常糟糕，而且最终她也未能找到会议室接待客户。如果她能够通过家里的电脑检视日历，她就可以能节省一个小时的路程以及许多烦恼。
这个需求的重点很显然不是「电脑上使用日历」。就我们看来，在这个场景中重要的是「查看空闲时间」，而不是「实现所有日历能做的事」。
这个案例以及其他相似的情况为我们为您提供了一个具体的设计准则。Basecamp 中对于日程有一个清单视图。它很适合列出主要的截止日期，但不适合用于资源调度，因为在上面是看不到空白的。而我们将需求的范围从「日历所做的每件事」缩小到了「帮我查看空余时间，这样我就知道如何安排日程了」。
我们仍然没有一个解决方案，但是这个问题已经足够具体并且符合我们的预计投入了。也就引导我们做出了上一章中的「点阵图」。
如果我们无法找到一个具体的痛点或者场景呢？我们的预计投入也会让我们明白细致分析的巨大价值。如果情况不是非常紧迫，我们也没有想好如何处理这个问题，我们就会将其暂且放在一边，并且去做其他的事情。也许之后会有新的场景或者需求来让我们更好地理解这个问题。
当心「福袋」
当我们的想法不够清晰时，最糟的情况就是就是脱离用户的需求和使用场景，自行「重构」或者「重新设计」。当有人提出类似于「重新设计文件部分」这样的建议时，这并非是一个项目，而是一个「福袋」。我们很难弄清楚它到底是指什么，它的起点和终点是什么？更有效的出发点应该是这样的：「我们需要重新考虑文件部分，因为共享多个文件需要太多的步骤了。」那么我们就可以开始思考：到底是哪里出问题了？在什么情况下会有太多的步骤？当前的设计可以保留哪些，又需要修改哪些？
「福袋」的典型标志就是「2.0」标签。我们曾经未经斟酌就鲁莽地启动了一个「文件 2.0 项目」。可以对 app 进行改进的兴奋劲占据了上风。我们知道自己的文件功能还有很多问题，但是我们没有想清楚我们具体要做什么。这个项目最终一塌糊涂，因为我们对怎样叫「完成」根本没有概念。为了挽救这个错误，我们将项目拆分为了更加细化的小项，比如「更好的文件预览」和「自定义文件夹颜色」。我们对每个项目都设置了明确的预计投入限制和成果期望，最终成功地进行了发布。
界限划定完毕
当我们有了这三样东西——一个原始想法、一个预计投入以及对问题的细化定义，就可以进入下一个步骤，定义解决方案的要素了。