7 章节5: 风险与无底洞问题
雷欧雷欧 保存 显示目录
要记住，我们的要塑造的是在六周内能够完成的项目。根据我们的经验，我们在上一章节中所充实的要素是可以在六周内完成开发的。但我们仍然需要格外留意，因为只要在概念上掉进一个坑，我们的开发就可能会偏离轨道。假设我们对一个项目进行了下注，然后交付给了一个团队。如果他们遇到了一个需要两周才能解决的意外，这就将花去我们三分之一的预算。
更糟的是，有时会你会遇到一些问题，不仅会使得项目延误。而且也没有明确的解决方案。我们曾经在一个「重新设计项目在 Basecamp 首页显示给用户的方式」的项目上下注。我们一厢情愿地认为设计师会想出好的方案解决，所以我们在塑造阶段完全没有验证过是否有可行的方案。这个项目一启动，我们就遭遇了远超出我们预期的困难。在六周的规划预算中我们都没能找出一个合适的设计方案。我们最终只能放弃了这个项目并在之后重新去考虑它。
当然，未知数永远都会存在。这也是为什么我们在第三部分中应用了这么多实践，这是为意外情况留出缓冲的空间，也便于团队从容的以正确顺序处理正确的问题。但这不等于我们在下注一个项目前可以不去预先去探查并排除陷阱。在我们认为足够安全进行下注前，一个塑造项目应该尽可能去排除漏洞。
不同类型的风险
就风险而言，一个塑造良好的任务的准时发布几率应该是呈现正态分布的，有很小的几率可能会需要追加一周。除此之外，既然解决方案的要素已经定义的很明确了，没有理由拖延更长的时间了。
但是如果在塑造过程中存在无底洞问题——技术上的未知数，未解决的设计问题，错误的交互——项目可能就需要比最初多几倍的时间才能完成。右边的尾巴就会伸展出去。
我们希望能够抹除去项目中的不确定性以及棘手的问题，这样我们的右侧尾部就会尽可能地窄小。这也意味着一个项目的各部分构成都独立、易于理解，并且按照已知的方式组合在了一起。
寻找无底洞
充实解决方案的要素是一个快速推进的探索过程。它更看重宽度而非深度。在这一步中，我们放慢脚步，用批判的眼光来审视我们的产出。我们有没有遗漏什么？我们有没有做出不客观的技术假设？
有一种分析解决方案的方法是慢慢地复现一遍用户场景。在我们绘制的解决方案草图中，用户在这个流程中会实践什么？慢慢地便利一遍这个过程能让我们发现缺陷和设计的缺失。
在这之后，我们还应该对我们认为已经解决的每个部分的可行性再次进行审视。我们应该问问自己这些问题：
- 这需要我们做一些前所未有的工作么？
- 我们是否是在假设各个部分能组合在一起？
- 我们是否假设了存在一个我们自己都想不出的解决方案？
- 是否有什么艰难的决定应该提前敲定以免拖累团队？
场景研究: 修补漏洞
举个例子，当我们定义「待办任务分组」项目时，我们引入了在待办任务清单中添加分隔符的概念:
我们喜欢分隔符这个概念，将待办任务分为未分组和分组对我来说很有意义。但是当我们仔细思考时，我们意识到我们没有解决已完成任务的显示问题。在现有的设计方案中，最近完成的几个任务会显示在清单的下方。那么现在我们已完成任务应该在每个分组的下方显示而非整个清单下方么？还是说我们应该沿用之前的方式在清单底部显示，并在已完成任务中也重复一遍相同的分隔符？我们是否应该先重新考虑一下如何处理已完成任务呢？
这就是藏在概念中的一个漏洞。如果我们不解决它，我们就会将一个深层次的设计问题交付给团队，还蛮横地要求他们在截止日期前交出解决方案。把一团乱麻扔给团队，然后让他们在有限的时间内解开它，这是不负责的。
根据经验我们清楚，彻底地改变待办任务的呈现方式对于用户体验、导航、性能方面都有着复杂的影响。为了消除项目中的不确定性，我们决定在已塑造过的概念中指定一个解决方案。对于已完成任务我们保留原有的模式。我们无需将其进行分组或者划分，只需要将它们所在的分组名附上就可以了。这可能有一点麻烦，但我们证明了这种权衡是合理的:它极大地简化了问题，而且我们仍然可以在分组详情页面上显示分组中已完成的任务。
当你在周期内负压工作时，要这样做出权衡是很困难的。有很多的原因都可以在客观上解释为何一个不同的设计或者一个对待办任务进行深度的重设计会更好。为什么不试试在每个分组中显示它们呢？一个设计师完全有可能会这么想，「如果我在视觉效果上多尝试一下，我能让他们融合得更好。」这样的死胡同会让他们很容易在仅有的几周内再浪费几天。
作为塑造者，我们更关心基本质量和风险，而不是最后的设计。在概念上进行妥协可以使我们将项目中值得开发的要素保留下来，比如在这个安利中是「未完成任务的分组」，我们也得以避免在延误风险上提高数值。
屏蔽场景干扰
由于团队的成员都想将任务做到极致，他们会理所当然的去尝试覆盖所有的用户并且认为这是很有必要的。随着团队对分区的锤炼越发熟练（请参看 章节十三 ）这将得到改善。但是为了让项目能够符合团队的预计投入，如果你有特别不认同的场景最好还是要提出来。
举个例子，我们有一个想法，支持在 Basecamp 中对成员分组发送通知。你可以直接点击「程序员」分组就可以通知他们了，而不用逐一点击五名程序员。当我们把目光投向产品，其实有很多地方也会有这种想法。既然在发送通知时可以选择一个成员分组。那么分配待办任务或者在聊天室中 @ 时为什么不加上这个呢？
出于项目的考量，我们的核心思想是通知的对象范围应当缩小。我们明确地将其他场景标记为越界。并且仅仅专注于我们寻求的初衷：更加迅速的消息发布。
削减
在草图绘制阶段，我们可能会对解决方案的一些部分格外有兴趣，但这些部分其实并非必不可少的。当我们设计待办任务分组功能时，我们认为用颜色来做分组管理是个好主意。毫无疑问用颜色来做分组会让页面看上去更有趣，而且这个功能也可能会更好用。但是我们还是决定将其标记为不必要的，并且从项目的核心中移除。我们可以将它作为一个锦上添花的选项来向团队提出。但是团队的起始点都应该基于即使没有它，功能本身也是很有价值的。
邀请专家
到目前为止，塑造工作一直都是在闭门造车。在你准备将想法写下来并广泛地分享之前，你可能需要投入一些精力去处理概念中你不太确定的部分。有些技术上的预设你需要与更了解代码的人进行核对。或者你希望确认使用数据不会同您对当前用户行为做出的假设矛盾。
这是抓住一个值得信任的技术人员并同他们就你的想法进行咨询的好机会。你要传达出这只是一个想法。它是你正在塑造的一个潜在的赌注，而非即将落实的一些内容。采用的也应该是一种友好而私密的模式：「我正在考虑一件事——但是我还没有准备好展示给其他人——你怎么看」？
这里有一件事很重要，在软件中，一切皆是可能的，但是所有的成果都需要投入。我们想要了解的是，项目在我们的预计投入限制下是否可行。不要问「有没有可能实现某某」，而是要问「某某有没有可能在六周内实现」。这是完全不同的两个问题。
探讨基于现有的预计投入而言，解决方案的优越性，让你的交流伙伴也承担起为你的项目限制规模的责任。并且要强调你正在搜索可能摧毁项目的潜在风险。这不仅仅是一个「你怎么看？」这么随意的交谈——我们是非常认真的在寻找可能在交付团队后会摧毁项目的定时炸弹。
尽量保持模型处于一个可塑的阶段。与其编写文档或者制作幻灯片，不如邀请他们来到白板前重新绘制出要素，就像你之前所做的那样，从头开始构建出概念。首先你要坚持你已经构建的概念，这样才能获取对你已完成工作的反馈。但是推进进度超过你已完成的部分后，你就应该开放这个项目并且邀请他们提出建议。在看到这个概念后，他们对于如何彻底简化问题或者以不同的方式处理问题是否有其他见解？
根据对话的进展情况，你或许能验证自己的思路，或者发现一些问题，这些问题会让你重新开始进行塑造。
消除风险，准备写「安利」
在这一阶段的末尾，我们有了解决方案的要素、用于应对潜在无底洞的补丁以及我们预先划定的界限。我们已经将一个有潜在风险的粗略解决方案，变成了一个我们希望压上赌注的可靠想法。
这也意味着我们已经准备好从私下塑造以及小范围交流反馈扩展到将其放上赌局了。我们需要阐述解决方案并限定清边界，以便没有太多接触的上下文的人也可以理解和评估它。这个「安利」将是我们用来争取资源以及在必要时收集更广泛的反馈时所需的文件，或者只是为了捕捉这个想法用以在后续更成熟的时机采用。