10 章节8: 赌上6周
雷欧雷欧 保存 显示目录
现在我们已经准备好了许多安利作为潜在赌注，那么我们就应该来决定将那些项目加入到我们的计划中了。
六周循环制
如果我们不能明确成员是否有空，有多少空闲时间，那么就很难安排人员和时间投入。如果大家只能在交错的项目中挤出时间，项目规划就成了一个让人头疼的俄罗斯方块游戏。循环工作制可以极大地改善这个问题，一个周期就为我们划定了一个项目的规模与进度表。
一些公司会采用两周循环制（又叫做「冲刺」），我们认为实在是太短了，难以去完成一些真正有意义的产出。更麻烦的是，做规划也需要时间支出，两周循环的成本太高了。你在两周时间产出的成果并不值得你花费几个小时坐在桌边讨论「冲刺计划」，也不值得打断每个人的推进计划去进行重组。
这种情况促使我们尝试更长的周期，我们期待能有一个足够长的循环周期来让我们从头至尾地完成一个完整的项目。同时周期也需要足够短，短到能够一眼看到尽头，这样才能有截止日期带来的压迫感，促使我们作出权衡。如果截止日期太过遥远或模糊，则会容易让人走神，效率降低，直到迫近终点线才感到真实的压迫感。
经过了多年的实验我们摸索出了六周循环周期，六周长短适宜，既足以完成一些有意义的工作，也能真切地感受到截止日期。
冷却
如果我们接连不断的地进行六周循环，我们会感到窒息而且也无暇做长远的思考。循环的末期是最不适合进行会议或者做计划的时候了，因为在最后关头，所有人都忙于为项目的及时发布进行最后的权衡与冲刺。
因此在每个六周循环后，我们会安排两周来进行冷却。在这两周中我们不安排任何固定的规划，并借此机会来调整呼吸，进行必要的会议，以及思考接下来的安排。
在冷却期间，项目组内的程序员和设计师可以自由做自己想做的工作。在六周的紧张开发后，他们很享受这段完全自我掌控的时间。他们利用这段时间来修复 bug，探索新的想法，或者尝试新的技术可能性。
团队与项目规模
除了规定每个循环周期的长度外，我们还粗略地规范了我们所下注的开发组和项目的类型。
我们的开发组由一名设计师和两名程序员组成，或者由一名设计师和一名程序员组成。在循环后期进行成品检测的质保人员负责组织这个小组。
这些开发组会用一整个周期完成一个大分支项目，或者完成多个小分支的项目。我们将前者叫做「大分支项目组」，而将后者叫做「小分支项目组」。每个小分支项目通常需要一到两周，我们不对它们做单独的安排，而是交由小分支项目组以准时发布为前提自行调整安排。
既然我们对于周期的开发工程量有了衡量标准，接下来我们就可以思考如何确定计划了。
赌局
研发相关成员会在冷却期间进行会议来决定在下一个循环周期我们的计划，我们将之称作赌局。我们的潜在赌注既可能是在过去六周产出的安利，也可能是一两篇更早的安利被成员提出来重新评估。正如我们在上一章中所讲，我们不需要组织「梳理」或者挤压可选项，我们只需要几个不错的选项。
在 Basecamp 中，我们的赌局由 CEO（他也是最终的拍板者）、CTO、一名资深程序员以及一名产品策略师（我自己）构成。
首席级会谈的时间是非常有限的，所以整个氛围都充斥着：「不要浪费时间」，并且时长也很少会超过一两个小时。每个人都应该在会议前抽空了解安利。在之前几周中进行一对一沟通也会有助于会议背景了解。一旦会议开始，就应当集中于赌局内的抉择权衡。
会议的结果应该是一个循环周期的计划。在座的所有人都应当清楚，谁有可安排的时间、业务核心是什么以及我们近期的进展。这些都会反应在之后所做的决策中——要做什么和安排谁来做（更多见下文）。
这里已经聚集了公司所有的高层成员，所以没有再下一步的验证审核批准了。在决定后就不能有人再来插入内容或者打断计划安排。
这种由顶端来做投注的操作对于维持循环周期正常运转非常重要。会议时间短、赌注塑造完整、参会人数精简，当这些条件齐聚一堂时，赌局就不再是一个争夺资源或者争执优先级的地方，而是真正掌控产品的方向。放心投入足够长的周期使得我们可以取得实质性的进展，并做出切实可行的产品，而赌局能让领导层们感受到一种前所未有的「大局在握」的感觉。
赌注的含义
我们使用「赌注」而非计划，当然自有其深意。
第一，赌注是有回报的。我们不是把一个循环周期的时间填满就可以了，也不是把两周的时间投入到一个功能上然后希望逐渐推进。我们是特意将工作安排进一个为期六周的循环中的，这样我们就会在循环结束时得到一些有价值的成果。安利则明确了投入的收益是值得我们的下注的。
第二，一个赌注也同样是一个承诺。当我们下注了六周时间后，我们就会给团队提供六周的时间专注于工作不受干扰。我们不会去拘泥于程序员每一个小时的工作内容，我们关注的是六周后的进展。
第三，明智的下注也是一种止损方式。我们在一个选项上投注了六周时间，我们最多损失的也就是六周时间。这使得我们避免了这样一种境地：我们花了几倍于最初预估的投入却一无所获。
让我们再具体看看后两点。
连贯的时间
如果我们决定投入六周但是中途又让开发组撒手去做其他工作，那么这并不算是真正的下注。
当你投入赌注后，这就是一个承诺。我们不允许开发组被打断或者去做其他的事情。如果有人要求中断小组的工作，那么就破坏了我们的承诺。我们将不会再给小组安排以六周为计划进行塑造的项目。
当有人用「只需要几个小时」或者「只需要一天」来请求时，别被欺骗了。势头与进展都是二维的概念，你无法用一个点去解释它们，你的曲线是由连续的点构成的。当你要求一名成员脱离一天以修复一个缺陷或者去帮助另一个小组，你损失的不仅是一天的时间，还破坏了这个前进的势头，也失去了重新获得冲劲的缓冲时间。失去几个小时就能毁掉一天，毁掉一天就能拖累一周。
那么如果发生了突发情况怎么办呢？我们仍然不会打断团队，这就是一个承诺。我们最多需要等待的时间也就是六周，然后才能够对新的需求或者想法采取行动。当循环结束后，如果这件事依旧拥有最高优先级，那么我们就可以对其投注并放到接下来的循环中。这也就是为何只提前计划一个循环周期非常重要，因为这时的我们对于新生事物仍有机会做出及时的反应。当然，我们还是可以为重大危机而及时刹车的，但是这种情况是非常罕见的。
断路器
我们将这种连贯时间策略与一个强硬而有力的政策相结合，工作小组必须在我们投注的时间内发布成果。如果他们没有完成，这个项目不会延期。我们自己制造了一个风险——项目无法发布。这听起来似乎很严重，但实际上这对于每个成员都很有帮助。
首先，它消除了任务失控的风险。我们在项目成型前就已经明确了我们的预计投入，此时的项目已经塑造完成并且撰写了安利。如果一个项目只值得投入 6 周的时间成本，那么再投入两倍三倍的时间进去就太愚蠢了。少有项目是值得「不惜一切代价的」并且需要立刻执行的。我们认为这个机制就像是一个断路器，它保护我们永远不会被一个耗时太久的项目拖累而止步不前，也不会妨碍优先级更高的新任务加入队列。
其次，如果一个项目在六周内无法被完成，就说明我们在项目的塑造阶段就已经出错了。与其在错误的方向投入更多的时间，断路器使得我们可以重新定义问题。我们可以在下一个六周循环中的塑造轨道上探寻更好的解决方案，避免我们再次陷入第一次尝试时遭遇的无底洞问题。之后我们会在赌局上重新审视这个方案，看看成功率是否有提高，是否要再投入六周。
最后，断路器机制也鼓励工作小组更加自主地掌控项目。我们在下一章节会说到，项目的执行权将被全权授予开发组。这包括了对于细节实现的权衡以及对于范围缩减的选择。如果你无法在何处止步、何处妥协、何处放弃间做出艰难抉择，你就无法顺利发布成果。严峻的截止日期和无法发布的可能性迫使工作小组会定期反思他们的设计与实现决策带来的影响。
如何处理 bug ？
如果团队在六周的循环周期中不被打断，那么 bug 该怎么处理呢？
首先，我们应该回退一步反思我们对于 bug 的假设。
bug 没有任何特别之处使之自动比其他问题拥有更高的优先级。存在 bug 不是我们打断自己或者别人工作的借口。所有的软件都能存在 bug ，问题在于它们到底有多严重？我们如果处于真正的危机之中——数据出现丢失、应用程序停止运行、或者大量用户看见错误页面——那么我们应该放下手中的工作优先修复它们。但这种危机是罕见的，大多数的 bug 可以放置六周甚至更长时间，有些甚至不需要我们去进行修复。我们永远不可能消除所有的 bug，如果你奢求产品完美无缺，那么你将无法开发出任何新产品。
换句话说，没有人喜欢 bug ，我们还是希望可以将它们解决，那么有三条策略可以帮助我们。
- 利用冷却期 问问程序员们是否有什么是他们希望折回去进行修复的，他们会给你一个清单。利用循环周期间的冷却期就有足够的时间可以处理。对于大多数 bug 来说，等待六周并不算久，实际上每隔六周我们就有两周可以用于做修复。
- 将它放入赌局 如果一个 bug 的问题较大，无法在两周内进行修复。那么就应该将其加入到赌局中来争夺资源。比如后台进程正在减慢应用程序的响应速度，程序员希望将其有同步改为异步。程序员可以提出修复问题并将方案塑造成一篇安利，然后将其加入到赌局中来做权衡，而不是打断其它的工作。时间的使用需要有策略性。推迟其它工作来修复 bug 与预先判断是否投入时间来修复 bug 是不同的。
- 安排一次 bug 大清理 我们在每年的最后——通常是在假期前后——我们将安排一个完整的周期来处理 bug ，我们称之为「bug大清理」。假期正是个好时机，因为人们在旅行时或者在休假时很难去完成一个标准的项目。开发组可以自行组织，挑选出最重要的 bug , 解决前端和后端长期存在的问题。
保持工作台整洁
控制工作量的关键在于每个周期都给自己保留一个整洁的工作台。换言之就是一次只下注一个循环周期，不要将旧工作的碎片未经塑造就视作一个潜在的赌注代入进来。
最大程度地增加未来的选择余地是非常关键的。我们不清楚在下一个六周循环周期中是否会发生紧急情况或者孕育出惊艳的想法。
即使在这六周的循环期间，我们产生了一些想法，我们也应该将其保留在我们的脑海中。每隔六周我们就能搞清楚什么是有用的什么是没用的，哪些是重要的哪些是无关紧要的。留出足够的选择余地是百利而无一害的，并且极其有助于我们应对突发情况。
那么对于那些无法在一个循环周期完成的项目该怎么办呢？即便如此我们依旧每次只下注一个六周周期。假设我们规划了一个功能的开发需要两个循环周期，可以先给一个六周循环塑造明确的目标，在六周后我们一定可以得到一些成果，这能够极大地降低风险。如果一切都符合我们的理想情况，我们就能很好地继续为下一个六周循环进行下注。但是如果不顺利，下个周期我们就可以安排一个完全不同的项目。或者我们可以将这个需要持续多个循环周期的项目暂停并着手一些更加紧迫的工作。重点是我们每周都有明确的塑造目标，并且留出了足够的辗转空间。
提问时间
这里是一些你会在我们的赌局交流上中常常听到的问题。
这个问题重要么？
就像在写安利时一样，我们要时刻注意不要将问题和解决方案剥离。如果问题不值得特意去解决，那么解决方案也就不重要了。
当然，任何对用户造成影响的问题都是重要的，但是我们必须要学会在重要性间做出取舍，因为新问题永远都会比解决问题的时间多。我们要在问题间权衡重要性。
局中人对于问题的评判标准取决于他们的视角、所处角色和接收的信息。比如，一个问题可能会给一小部分用户造成影响，但是修复这个问题却需要担负不成比例的成本。你对这个问题的权衡将取决于你对于解决方式的了解程度以及所接触到的业务领域。
有时候过于复杂或者笼统的解决方案会带来新的问题。我们是否需要对应用做出这么多改变？我们对于问题的了解是否足够具体了？也许这里能有一种方式能简化问题，用20%的调整获得80%的收益。
预计投入是否适宜？
解决方案有合理的时间规划框架是很好的，比如两周或者六周。但我们仍然有可能会争论是否值得投入时间。假如一名决策参与者表示没有兴趣投入这么多时间在给定的安利上，那么后续争论将有可能就此向着两个方向发展：
- 也许是这个问题表达得还不够清晰，那么塑造者可以立刻在交流中补充一些信息来改变反对者的观点，比如，「这个问题确实不是经常发生的，但是当用户遭遇到后会反应得很激烈，这不利于我们的口碑。」或者「也许听起来是个微不足道的小问题，但是要解决它需要经过11个耗时的步骤」。
- 有时候对规划时间说「不」的本质是在对其他事情说「 不」。也许他们不喜欢的是解决方案或者技术问题。询问「如果我们能在两周内完成它，你怎么看」可以看出问题是否在于时间，CTO 可能会回答「我不想在应用的那个区域引入一个依赖关联」。
- 收益太低也会让塑造者放弃想法。
- 如果塑造者认定这个问题是有必要去解决的，只是表达得还不够明确。那么塑造者会回到工作台前去打造一个更精简的版本（降低预计投入）或者更深入地进行研究。
解决方案是否有吸引力？
问题也许很重要，开发计划也很合理，但是解决方案上可能存在分歧。
举个例子，在界面上添加界面元素会带来无形的成本：放弃空间。也许在主页的角落中添加一个按钮就可以解决这个问题。但是空间是很有价值的，如果我们现在动用了它，未来就无法再利用了。我们是否为了解决这个问题而过于轻易地挪用它了。
如果有人提供了即时的解决方案，比如「我们将按钮移动到一个操作菜单上如何」，我们可以进行讨论。但是我们在赌局中通常会避免花费超过数分钟的时间来讨论设计方案或者技术问题。如果我们发现自己在细枝末节上耽搁太久，我们会提醒自己「我们不应在这个层面做设计」并返回到更高的层级。
时机是否合适？
我们近期所做的项目将会决定接下来要做的项目。也许我们已经很久没有研发新功能来引起关注了，或者我们已经开发了太多的新功能，应该去处理一下长期存在的客户问题了。又或者开发组已经在应用的同一个部分进行了数周时间，再安排类似的项目或许会使得他们变得沮丧。
这些都是我们可能放弃一个项目的原因，即使它塑造得很好也很有价值。项目很棒，可惜不是时候。
是否有合适人选？
我们会安排不同成员在每一个组中但任务不同的角色，这也是投注的一部分。也就是说我们会将项目和特定的工作小组进行绑定，小组由一名设计师和一两名程序员构成。我们有一个由程序员和设计师组成的「核心产品」小组，在每个周期分派小组时，我们都会进行挑选。小组会共同协作一个周期，然后在下一个周期又更换新的小组。
不同的项目将会需要不同的专业知识。也许我们在这个项目上需要许多的前端程序，而在另一个项目中则时常会遇到需求扩展，那么我们就需要擅长做范围控制的成员。
每个人的工作类型则是另一个因素。完成了一连串小分支项目的成员会更加愿意去做一个大分支项目，反之亦然。
此外，成员的可利用时间也会形成一个日程拼图。假期和公休假都会影响我们在下个周期安排的项目。
我们还看到一些公司使用其他的模型，他们让小组成员自行挑选想要进行的项目而非分配。从团队文化上来说，我们很反感这个额外步骤，但是听说它对于不少团队都有成效，因为项目小组有了更多的选择权。
发表声明
在完成下注后，我们中的一人将会推送一条通知告诉成员我们接下来的周期将要做什么项目以及都由谁来参与。
Jason 在 Basecamp 讯息中发布了下一个周期的投注