并非大公司的所有事情都涉及编写代码。有时，您必须做一堆元数据才能管理项目。这是两个正是这样做的故事。
…
你有没有见过当一个团队有很长的“待办事项”清单并且不知道从哪里开始时会发生什么？您是否不得不坐在那里目睹人们试图将 P0、P1、P2 等优先级值附加到这些项目上的循环对话？他们是否仍然不知道从哪里开始？
“AB-123 是 P0……”
“哦，是的，绝对是” “是的” “绝对是”
“但我们不能这样做，因为 XX-996 还没有完成……”
“XX-996 是 P2，所以不能在 P0 之前完成……”
… 听起来有点熟？
我间接地经历了这样的事情。附近有一个团队与我正在做的事情密切相关，但没有加入我的管理链。他们被困在这种事情上，他们的经理问我是否愿意和他们一起整理他们的优先事项。
这是您有一群人试图提高服务可靠性的情况之一。无论出于何种原因，他们都无法破解这个特殊的组织难题。这就是那天在会议室里最终发生的事情。
由于我们每个人都同时在同一个房间里（我承认这几天很奢侈），我只是问我是否可以解决这个问题，抓起一个标记，然后走向棋盘。我要求有人给我一件他们希望看到的事情。它以一个简短但令人难忘的标题出现在板上，并在其周围画了一个圆圈。我又要了一个，它也出现在了别的地方。
这种情况一直持续到我们有 10 或 15 项人们认为团队出于某种原因应该做的事情。然后我从板子的一端开始，挑选一个项目，并询问它是否依赖于其他任何项目。事实证明，这个确实有依赖关系，所以它被板上的其他项目“阻止”了。我画了一个从第一个到第二个的箭头。
这一直持续到我们访问了板上的所有“节点”，并且我们看到了一些有趣的东西。肯定有一些节点被其他各种东西挡住了，但也有几个被什么东西挡住了。这完全独立于人们对这些任务的重视程度。我暗示，如果你不能取得进展，他们的优先事项就没有任何意义，所以把那些现在可以做的事情拿出来，继续努力。如果你继续这样做，你最终会达到你假设的 P0 并且它会发生。
真的，情况对我来说就像一个巨大的 Makefile。这就是你说的，好吧，要构建 my_project，我需要构建 httpclient.o 和 logging.o。要构建 httpclient.o，我需要在系统上安装 libcurl。我的系统上还没有 libcurl，所以我还不能构建 httpclient。但是我*可以*构建日志记录，因为它不依赖于任何东西。因此，您可以进行日志记录，也可以让 libcurl 运行。或者，如果你有两个工人，同时做两个。万岁。
对我来说，“优先事项”主要是装饰性的。似乎您可以将它们用作决胜局。例如，假设您有一个依赖链阻塞了所谓的 P0 任务（据说是最高优先级），另一个阻塞了 P3（祝你好运）。您可能会尝试投入更多精力来完成前者而不是后者，并且可能首先开始。这是一个提示系统，而不是命令。
…
我们中的一些人大约在同一时间在同一份工作中做了另一件有趣的事情。几个志同道合的人已经决定，我们需要一种更好的方法来运送公司构建的系统软件，该软件运行在机队中的每台机器上——“广泛分布的二进制文件”，如果你愿意的话。我们三个人决定就这样去做。
由于以前没有人真正这样做过，我们知道我们不可能事先制定出“路线图”。我们知道成功是什么样子，但我们也知道我们必须适应一路上遇到的条件。出于这个原因，我们首先手动发送二进制文件，然后记录该过程的哪些部分是糟糕的。一旦我们认为我们已经掌握了它是什么以及如何改进它，我们就会自动执行该步骤。然后我们将堆栈向上移动一级并再次执行此操作。这种情况一直持续到事情几乎自行运行……我们有一个中等体面的清单“你需要有理智地运送 WDB 的东西”。
我之前已经讨论过这个问题，但我没有分享的是我们如何处理一路上出现的“哦，如果我们做这件事怎么样”的想法。我们想出了一个处理这些问题的方法，我认为这是非常人道的，并且没有做出任何我们无法兑现的承诺。这是它的工作原理。
因为我们三个人在做这个项目，而且我们的 unixname（也是我们的 IRC 昵称）是三个不同的首字母（A、B 和 R），我们利用它来发挥我们的优势。我们会跳上 IRC 并聊天，当我们提出想法时，我们会从我们自己的集合中添加另一个项目。也就是说，我的第一个想法是R1，然后是R2，然后是R3，而B先生的想法是B1，B2，B3，A先生的想法是A1，A2，A3，等等。
这让我们所有人都可以在那里提出想法，同时给它们一个唯一的标识符，这样它们就不会丢失，并且不必相互协调以便在增加计数器时不会发生冲突。所有的想法都进入了我们的 Wiki 页面，这与他们在一段时间内得到的一样具体。然后我们都能够看到其他人在想什么，寻找重复的想法，重叠，并通常寻找有助于（或伤害）其他事情的事情。
这些项目都不是承诺。它们只是想法。此外，仅仅因为你有这个想法并不意味着你必须对它做任何事情。我们以我们所做的方式标记它们的唯一原因是这样它们可以被唯一标识，以非阻塞方式分配，因此如果维基页面上的要点不清楚，你会知道该向谁寻求澄清和/或 IRC 聊天记录。
“嘿B，在B5上，你想把那个东西存放在哪里？”
“是的，我想要 svn 中的那个。”
“哦，是的，现在这对我来说更有意义了，谢谢！”
…你明白了。
在某个时候，我们开始将它们拼接在一起，这样 A1 可能依赖于 A5，但随后 A5 依赖于 R2。这样做一段时间后，我们最终得到了几种不同类型的列表项。
有些项目没有阻止任何东西，也没有被阻止。您可以随时选择一个并继续对其进行破解，但与此同时，您不会通过这样做来解除对任何人或任何其他事物的阻止。这可能会让您在一个独立的项目上度过一个愉快的下午。
有些项目被一个或多个其他项目阻止。它们往往相当大。
然后有一些项目本身阻止了一个或多个项目。
如果您正在寻找可以做的事情，那么那些是阻止者但本身并未被阻止的地方显然是开始工作的地方。这是因为如果你从被阻挡的东西开始，你会击中阻挡者！如果你仔细想想，这很明显，对吧？
通过 Wiki 内置的“dot”/graphviz 渲染器将其绘制为一堆链（想想标记为带有指向其他圆圈的箭头的圆圈），我们可以只看它们的末端以找出可能*现在*启动。我们还可以看到哪些项目在畅通未来工作方面影响最大。
当有人决定他们要做某事时，我们会为它创建一个任务。 “任务”是该公司错误跟踪软件中的货币单位。这意味着它有一个数字和一个漂亮的小快捷 URL，因此 wiki 将被更新以链接到它。任何好奇的人都可以通过该链接进入任务工具以查看发生了什么。
我会注意到，该图表已被安排为根据它们是否被阻止以及它们是否已完成来显示具有不同颜色和渲染样式的事物。
有时，我们会检查并修剪图形，以删除已完成且仅占用空间的节点。看着事情被击中然后从列表中消失，图表感觉很棒。
这里有一个重要的一点：其中一些项目从未离开过列表。据我所知，它们可能仍然存在于埋在该公司腹部的某个公司 wiki 页面上。这些项目只是某人有一天的想法，但随着服务投入生产，事实证明我们并不那么需要它，或者完全有错误的想法。然后，就这样结束了。他们中的一些人实际上在没有完成的情况下就被删除了，并附有解释原因的说明，这样我们就不必一直考虑它们。
这种做事系统让我很开心，因为它没有让我们拿着一个装满承诺的袋子。只是谈论某事并没有让我们以后花时间在这上面。通过将谈话与承诺分开，这让我们可以自由地谈论各种事情，而不必担心会以某种方式结束在路上的大量愚蠢和无用的东西。当然，我们仍然做出了承诺——这就是任务的目的。
你如何避免拥有令人心碎的任务/门票/任何永远不会消失的东西？在您确定它需要存在之前，您不会创建一个。
警告：如果你有太多的事情发生，你冒着“丢失”某些东西的风险，因为它只是某个地方的 wiki 页面上的一个项目，你可能不想在你的项目中尝试这个。 （你可能还想逃离那个项目，因为那里发生的事情太多了。）