9 章节7: 多下注少囤积
雷欧雷欧 保存 显示目录
现在我们已经写好了安利，那么接下来我们要做什么呢？我们不能让这篇安利就进入仓库中堆积起来。
不要囤积
囤积是我们不需背负之重，当任务累积了几十个甚至上百个时，我们心知肚明这些存货是永远不会去完成的。越来越多的囤积量让我们感觉一直在落后于进度，即便有时候我们并没有。仅仅因为某人在一个季度前认为某个想法很重要，并不意味着我们就要一遍又一遍地去调研它。
囤积是对时间的极大浪费，把时间都花费在整理回顾旧想法会让阻碍大家在当下真正重要的项目中取得进展。
一些潜在的赌注
那么我们应该怎么做呢？在每个六周周期开始前，我们会向所有相关成员开放一个赌局来下注接下来的周期中我们需要做些什么。在赌局中我们会回顾过去六周的安利——或者某人特意提及并提议完成的旧安利。
除此以外，赌局中就不应当再有其他的东西了。没有长串的想法需要去回顾，也没有时间用于整理积压下来的旧想法。只有几个完成了塑造并排除了风险的选项等待评估。这些安利都是潜在的赌注。
如果我们决定要在一个安利上下注，那么它就会在下一个周期中进行开发。如果我们不打算下注，就会直接放弃它，而不会持续追踪或者保留什么。
如果在一个不合适的时机看到了一个很棒的安利该怎么办呢？任何看好并且希望坚持这个安利的成员都可以独立地去进行追踪，然后在六周后再次提出这个倡议。
分散的清单
我们不必在「积压内容」和「忽视过期想法」间左右为难。每个人都可以在没有积压的负担下独立追踪安利、bug、需求以及任何他关注的内容。
客户支持小组可以将高频需求和问题整理一个清单。产品组追踪有望在后续的开发周期中进行塑造的想法。工程师在有余裕时去处理一个待修复 bug 清单。这里并不存在核心列表或者积压问题。这些清单都是未经赌局下注而直接去完成的。
部门间定期低频地进行一对一交流有助于确定下一步需要做什么。比如客户支持组可以告诉产品组，他们接触到的最严重问题是什么，这个问题也许可以作为潜在项目由产品组去独立追踪。可能产品组现在只会在其中挑选一个来完成，其余的后续再逐个完成。客户支持组则可以将当下仍未解决的重要问题一次又一次的同产品组进行交流。
这种方法将优先级和追踪的职责分离开了，使其容易管理。来自不同部门的成员可以选择他们认为重要的事，并用任何行之有效的方法进行追踪。
这样的谈话总是时新的，任何反馈的内容都是带有背景的，被一个人基于某个目的引入的。每件事都是关联并且及时的。
重要的想法是会回来的
人们常常高估一个想法的价值，事实上想法是很廉价的。它们无时无刻不在产生然后囤积成堆。
真正重要的想法是不会搞丢的。你何曾忘记过一个真正非同寻常的想法呢？如果想法不是太有趣（可能是只是一个偶发的 bug ）——当用户再次抱怨它或者新用户遇到它时——它会再次唤醒你的记忆。如果一个问题你只听过一次，那么它绝不会是真正重要的任务。如果你时常会听到某个问题，你就会有动力去制定一个解决方案，并在下一个开发周期中实现。