当循环周期接近尾声时，我们在之前介绍的诸多技巧应当已经保证了开发组的项目进展良好。我们增加了塑造工作来避免他们迷失方向。通过逐个完成分区保证不会又半成品产生。难易度和优先级的排序则是为了预防未知因素潜伏到项目末期。

尽管我们做出了许多的努力，但是可以改进的内容永远都会比可用的时间多。想要及时发布成果就难以追求尽善尽美。我们需要扪心自问的是：现在的成品是否达到了发布的标准？

与基线进行对比

程序员与设计师们常常在追求完美的道路上钻进牛角尖。其实按钮设置在登录页面的中心还是后两页并不重要，但是设计师却会对此反复斟酌。而最好的程序员也总是希望代码库能够协调统一，并且能够尽可能地兼顾任何边缘场景。

成就感对于维持团队士气和产品质量是非常关键的，但是我们需要对其给予正确的引导。如果我们将目标定为一个完美的设计，我们就成了逐日的夸父。当然，我们也并不希望这成为降低高标准严要求的借口，所以我们需要思考一下我们的标准应该如何制定呢？

在这里我们应该调整我们进行对比的角度，与其和我们自己构思的理想效果进行对比，不如以实际用户场景为基线进行对比。所谓基线，也就是用户在没有这个功能的情况下的做法。我们要反思这个功能所要解决恼人场景是什么？当我们在 A/B 方案间举棋不定时，用户还要为此受煎熬多长时间？

当我们发现我们目前为止所做的努力让用户成功摆脱了那些麻烦的替代方案，这感觉真是棒极了。这也鼓舞着我们去解决那些会拖累我们进度的问题。这不是我们的主观判定，而是站在用户的角度来看，「还有缺失」和「比他们现在所有的好」是有很大区别的。我们的方案或许不够完美，但是我们的方案足够给用户体验带来改善，这就够了。

不是向上与理想状态对比，而是向下与基线对比，以此来削减分区

限制推动取舍权衡

回想一下我们之前在循环中设置的断路器——无法完成的项目等同于没有建项。

这迫使开发组必须做出权衡。当有人提出「如果这样是不是会更好？」或者发现了一个边缘场景时，他们首先应该反思：我们还有时间做这个么？如果没有截止日期，会很容易把时间投入到一些无关紧要的内容上从而导致项目延误。

我们希望开发组能自主地做出权衡并且对分区保持质疑，而不是按部就班地去完成它们。我们的工作内容也是自主设立的，当有新的任务需要加入进来时，我们应该先对其进行审视。

分区异常扩增

分区膨胀是一个正常的现象，这并不是糟糕的用户、项目负责人或者程序员的错。项目在宏观层面来说本就是不透明的。在实际开工前你本就无法看到项目所有的微观层面的细节。你会在实际工作中不断发现意料外的复杂问题，而且还会不断找到可以改进的内容。

每个项目都充斥着我们不需要的分区。产品的每个功能不需要都一样醒目、快速、精致。每个用户场景也不是同样普遍、关键或者和我们的目标市场同样吻合。

正因如此，与其试着阻止分区的扩增，不如把工具、权利与责任交付给开发组来不断削减它。

削减区块并非降低品质

我们要学会选择执行哪些事情以及执行到什么程度以保证产品中不会遗留下漏洞。有所选择会使得产品一部分功能优于另一部分，以避免同质化。区分核心场景于边缘场景会让我们形成对比意识。也让我们的产品和竞品更加的接近或者更加的不同。

分区的改变并不意味着要牺牲产品质量。我们对于代码的质量、视觉设计、界面交互依旧十分挑剔。关键在于找到真正的核心场景，以及对核心场景有帮助的内容。

锤炼分区

人们常说要「削减」分区。其实我们可以用一个更有力的词汇——锤炼，锤炼更能反映出为了找出和我们的时间规划最契合的分区我们所需要投入的精气神。

当我们的项目中需要修复、添加、改进或者重新设计一些内容时，我们应该先问问自己：

这对于新功能来说是「必不可少」的么？
缺少了这一部分我们可以发布么？
如果我们不做这一部分会怎样？
这是一个新问题还是一个用户已遇到的问题？
这个场景的出现频率高么？
当这个问题发生时，哪些客户会遇到？它是否核心——是所有人都会用到或者只是一个边缘场景？
这个问题有什么影响？
在某个特定场景下会出现一些问题，这个场景和我们的目标受众重叠度有多高？

固定的截止日期会促使我们思考这些问题。可变的分区则允许我们进行精简处理。通过对分区进行雕琢与锤炼，我们会专注于那些能帮助我们发布内容的工作上，那些能在工期最后给我们带来成就感的工作。

在整个循环周期中，你都会听到我们的开发组在分析项目时讨论「不可或缺」和「锦上添花」。「不可或缺」的内容会被创建为任务留在分区中。只有这些任务都完成了，这个分区才算完成。「锦上添花」的任务则可以保留在一个已经完成的分区中。它们的标题前会被标记一个「～」。若开发组在循环末期有多余的时间就可以去完成，如果没有就将它们去除。通常来说它们都不会被完成。将它们标记为「锦上添花」的行为就是在锤炼分区。

一个已完成的分区中包含的一个锦上添花任务（前面标记了「～」），它并未被完成

质检员的责任不是监控质量

按照 Basecamp 目前的规模（数百万用户和大约12人的产品团队），我们设置有一名质检员。他会在循环周期接近尾声时加入项目，探寻核心功能外的边缘场景。

程序员和设计师已经保证了他们的产出的基本质量，因此质检人员的加入能够有效地限制边缘场景对他们的干扰。产品测试是由程序员自行书写的，而开发组则一起确保项目开发是按照塑造地结果来落实的。这也正是将整个项目托付给开发组，而非直接为他们分配任务的原则。（参见第九章）

多年来我们都并未设置质检员的角色。但是当我们的用户基数成长到了一定规模后。我们发现一些小的边缘场景也会影响成百上千的用户的使用。额外增加质检步骤能够改善这些用户的体验，也降低了对他们提供技术支持所带来的负担。

因此我们认为质检应当是一个进阶工作，而不是项目流程必经的一个环节。有质检优于没有质检，但是我们的质量并不依赖于质检，它在开发阶段就应当被保证。

质检员发掘的任务都默认归类为「锦上添花」。设计师和程序员根据严重程度和预估时间成本将它们进行分流，并将其中一些加入到「不可或缺」中。最严谨的方法是将质检收集的任务放进一个单独的待完成任务清单中。当开发组认为其中某个任务是「不可或缺」的，就将它拖动到与其相关的分区中。这样以来，完成这个分区的标准中就需要追加上这个新任务了。

我们对代码的复查也采用同样的方式。开发组可以不进行代码复查就发布内容。我们并不常设检查点。当然，代码复查肯定是有好处的，所以如果时间允许并且也确有必要的话，高级程序员或许会看一看代码并进行问题反馈。这不是我们在流程中固定添加的环节，更类似于抓住机会进行一次教学活动。