14 章节12: 展示进程
雷欧雷欧 保存 显示目录
温和的项目负责人并不喜欢追问进展，啰啰嗦嗦的让人感觉很尴尬。但更糟的是，他们又不得不问一些后续的问题来搞清楚项目情况。
它们当然更希望在需要的时候可以自行查看项目状态。在上一章节中，我们介绍了通过对待完成任务进行分区来帮助开发组提高效果。但这对负责人来说作用并不大，这里仍有一大堆的未完成任务在干扰他们的判断。
潜在任务
试想这里有一个清单，其中包括一些已完成的和未完成的任务。这个清单目前可能已经被完成了，但是也可能意味着开发组知道这里还有一些潜在的任务，只是尚未被发现。
有时候，开发组会在项目早期就创建出一个空的分区。这意味着此处有内容需要完成，但是具体的任务还有待探索。
或者是因为考需要在分区最后进行一些质检工作。现有的任务已经解决了，但是在质检过程中还会产生新的任务来填充这个分区。
这又回到了预想的任务与探索的任务的概念上。我们可能会天真的以为，分区可以预先规划，然后逐步将填充它的任务完成掉。但在现实中，新的问题总会随着原问题而产生。换句话说，任务清单是会随着开发进程不断扩充的。
如果我们试着在 T2 的时间点来推测项目的进展情况，很显然就被误导了。从旁观者的角度来看，未完成任务的数量会不会增减根本无从得知。要了解这一点，你需要更了解分区间的依赖关系，一些特殊任务是否完成了以及是否还会产生新任务。
预估的不确定性
有些开发组试着给他们的任务或者分区加上预估来报告项目状态。但是预估的问题就在于它们受工作本身的性质影响是具有不确定性的。
当你对两个任务的预估都是四小时。但是其中一个任务开发组已经做过了10遍，那么你会对于预估很有信心。而另一个任务是开发组从未尝试过的，或者其外部关联尚不明确，如果一切顺利的话它只需要4小时，但考虑到其中的未知因素，它可能会延续到两至三天。将预估写作「4小时，或者3天」就毫无意义了。
在认识到这一点后，我们想出了一个不用计算任务数和预估数值就能查看项目情况的方法。我们采用的方法是将关注点从「已完成的任务&未完成的任务」切换到「已解决的问题&尚不清楚的问题」。为了实现这种切换，我们采用了山型图。
工作就像是一座山丘
任何工作都有两个阶段。首先是上山阶段，我们需要找出我们的目标是什么以及我们要做什么。当我们理清了工作的相关内容，就到了下山阶段，开始具体地实施。
我们举个日程安排的例子来理解上山下山的比喻吧。
假设你准备举办一场晚宴。距离你确定的日期还有数周时间但你还没想好要烹饪什么。你不清楚应该做什么菜系或者具体要做什么菜肴。那么你还处在山丘的左侧山脚。
接下来你留意到受邀出席的嘉宾中有一些素食主义者。这就需要排除一些选项（比如烧烤）了，但是仍然还有很多菜系可供。你权衡了印度菜与意大利菜。考虑到印度菜烹饪起来更加有趣，而且素食主义者也会有更多有趣的选择，所以你决定去找印度菜的菜谱。
此时你还是无法回答「项目完成进度百分比」。如果有人问你采购和准备工作的预计用时，你也给不出，因为你连一道菜品都没有确定下来。你只能回答：「我已经好确定菜系了，但是我还没有落实菜单。」现在我们可以把你移动到山丘「确定菜品」的阶段来代表当前进展。
此后，为了找到一份有趣但是配料又不太难准备的菜谱，你翻阅了网络菜谱以及你的私藏菜谱集，然后敲定了菜单并罗列出了采购清单。
现在你的进度已经从「我要做些什么」来到了「我接下来需要再去做这些」。此时的你已经爬到了山顶。
从这个视野至高点，你可以看到接下来的每一个进程，甚至可以预估接下来的工作需要多少时间了（去杂货店需要 1 小时，准备工作需要 30 分钟，烹饪需要 45 分钟等等）。
在晚宴前一天，你按计划去杂货店购买食材，这标志着你迈入了下山阶段，距离你完成所有工作又近了一步。
下一步就是准备和烹饪的工作了。
晚宴后则只剩下了一个工作：清扫。
请留意这座山丘体现了工作推进到不同阶段时的感觉。上山阶段满是不确定性、未知性以及待解决的问题。下山阶段则带着自信、全局视野以及明确的待完成内容。
分区在山丘上的分布
我们可以将这座山丘和上一章中分区的概念结合起来。分区给我们带来了「定位」、「响应」等项目属于，山丘则描述了每个分区所处阶段的状态：「上山」、「下山」。
要查看分区的状态，我们可以给山丘上的每一个部分加上一种颜色。
这是 Basecamp 中一个用于实现重复事件的项目截屏。在这里「Future-applying edits」对应的是一个尚待填充的阶段，还有这许多的未知数需要去落实。到了另外两个阶段已经没有真正意义上的未知数了，而到了「Global recurring events」阶段时项目已经趋于完成。
无需询问状态
我们在Basecamp中开发了一个独家功能：创建山丘图，并且可以通过数次点击就可以进行更新。开发组的成员都可以完整地看到工作当前阶段的前后关联，直观地将区块拖拽到对应的位置，并在项目中保存一个更新。（参看附录：如何在 Basecamp 中实现塑造）。
对负责人而言，可以和历史记录做对比的功能是一个大杀器。它不仅展示了项目当前的进展，还展示了它的推进情况。
从这种第二人称的视角，负责人可以判断出项目在各个阶段何时推进良好，何时出现了停滞？他们还可以看到开发组对于问题的选取，以及在「上山」、「下山」阶段各花费了多少时间？
当负责人对项目的进展感到焦虑时，这份报告就能成为他们的第一剂强心针。由于是完全自助的，所以也不需要打断开发组的工作来询问一些令人尴尬的问题。当察觉到有哪里看上去不太对时，负责人大可以直接切入到对应部分进行交谈。「自动保存」似乎在上山阶段停留有段时间了，是否有什么问题阻碍了它？负责人可以针对这个阶段进行考察，而不需要将它从流程中彻底剥离出来。
没人会说「我不知道」
没人希望对负责人的提问回答说「我不知道怎么解决这个问题？」但是这也会导致开发组将问题藏起来草儿导致风险增加。当某个成员开始止步不前或原地打转时，这正是最大的风险与机会并存的时候。如果我们能尽早捕获到这些时刻，我们就可以重新定义这些概念或者向前辈寻求帮助以解决问题。如果我们捕捉不到，这些未解决的问题很可能就会在周期中停留太久，最终危及整个项目。
山形图可以让所有人看到每名成员可能被阻碍的地方。即便他们不说，一个停滞不动的点就仿佛一只举起的手：「这里可能有些问题」。
一旦问题被发现，项目术语就能帮助你促进讨论效率。卡壳问题更多的是针对工作内容而非某名具体成员。关键的问题是：我们要解决什么才能越过山丘？
重新划分的征兆
有时候我们会在研究一个卡壳的阶段时发现，其实问题是出在分区上
比如这里有个叫做「通知」的分区在山丘上停滞太久了。
但我们检查工作小组的工作情况时，发现他们其实进展顺利，问题在于「通知」不是一个独立的内容，而是包括了三个不同的部分：设计一封邮件、在后端发送邮件、在应用程序中推送消息。开发组已经基本完成了发送邮件部分的代码，设计邮件部分也基本厘清了，但是他们还没有开始做应用内部推送的部分。因此「通知」作为一个分区而言，处在了一个很微妙的位置，因为它的一部分跨越了，而另一部分还没有。
这种情况的解决方案就是将分区切割成更小的独立分区。
这样开发组就可以更加精确地移动进度点来现实目前的工作进展了。
第二个好处在于，随着分区的进一步划分，他们也可以随时间独立地进行迁移。开发组可以更加频繁地去现实进展成果了。
探寻你的攀爬之道
一些团队在初次尝试山形图时会遇到进度回退的情况，当他们认为一个分区已经完成后，就将定位移动到了山顶。但是后续遇到了一些意料之外的问题让他们又不得不将其进行回退。
发生这种情况往往是因为有些成员光想不做。在大脑中想出一个方案只是上山的第一步。要找到一个解决方案是很容易的——「我只用那个 API」，但是事实证明现实往往会比预想更加复杂。最好的方法就是，把上山分为三段，前三分之一是「我已经考虑过了」，中间部分是「我已经验证了」，最后三分之一则是「我想清楚了，也验证了，不会再有意外了」。
正确的答题顺序
除了可以看项目进展外，我们还可以借助山形图来为工作排序——先做什么后做什么。
一些分区的风险可能会比其他的更大。假设有两个分区：一个涉及到地理编码数据——这是开发组不曾涉足的。另一个是设计和实现电子邮件通知。两者都存在未知因素，也都需要从山脚出发，但此时开发组需要考虑清楚：我们目前处在循环的尾声阶段，虽然两个选择都可能会遇到意外情况，但是哪一个会更加棘手呢？
这会促使开发组先将最难的工作的进度推进到山顶，一旦这些工作完成了上山阶段，就可以让它们先留在那里，在完成了攻坚后再来做下山的工作。先难后易是一个很好的规划方式。
最大化利用可调度的时间。如果开发组首先从电子邮件模板下手，他们很容易就会投入数周的时间去迭代复制，或者开发出最棒的电子邮件设计，但这毫无必要。一些电子邮件模板在最后一周抽出一天区完成就足够了。另一方面，地理编码器的工作则可能会出现新问题，需要开发组花上几周的时间来解决。显然，他们不会希望在循环周期快结束时再出现这种意外。
新闻工作者们有一个“倒金字塔”概念。 他们的文章会从最本质的信息开始，然后按重要性递减顺序添加细节和背景信息。这让印刷版的排版设计师可以在头版上就找到故事的关键部分，并根据需要删减结尾，而不会导致任何重要内容丢失。
高效的开发组会以同样的方式排列他们要解决的问题。 他们会首先选择最重要以及最具未知性的问题来解决，然后把最常规或最不令人担忧的问题留到最后。
当循环周期接近尾声，开发组应该已经完成了最重要的工作，只留下许多的「锦上添花」和「或许会做」四处散落。这些将被我们进入下一章：「适可而止」中。