如何少做事：摆脱工作过载的实用方法

你现在可能需要少做点事。

优先级排序有两种宽泛的定义。你已经做了第一种，第二种你也算做了……勉强算吧。但不知怎的，你仍然焦头烂额。

这不是一种可持续的工作方式，但你感觉被驱使着在短期内做出牺牲，继续做你已经在做的那些事情，而且做得更多。

你对未来的那种不确定感？那是一连串即将到来的失败。你困在一个陷阱里，挣扎是出不去的。

你可以通过停止当前的做法、去做一些新的事情来逃离这个陷阱。深吸一口气，准备好终于做出那些艰难的决定。你要刻意地矫枉过正，削减进行中的工作（WIP），然后在此后维持一个健康的量。本文剩下的部分就是讲怎么做到这一点。

首先，你需要尽快降低所有人的期望值。你必须把自己从糟糕的状态中拉出来。在这里，半吊子的措施没有意义。人都很聪明，他们能识别出你在含糊其辞。你周围的人会知道你是否对自己的计划没有决心。你需要做出艰难的决定，然后去做真正困难的部分——坚持这些决定。

保持运转，并让维持运转变得更便宜。你的团队已经拥有的一切（那些真正对客户重要的东西）都需要趋近于零维护成本。如果不把长期成本降到最低，你的人力和时间就会被吞噬，每个新功能的交付都会比预估的慢。指定一个负责人，主动寻找并减少团队中最大的oncall和支持负担。这项工作可以说比任何新功能都重要——确保你以这种方式传达它。这是光荣的工作，因为那个负责人维护的是今天已经有价值的东西。这看起来像是：为用户写自助文档、修复偶发的bug、添加预发布测试来捕获那些导致故障的问题。

问问你的团队最大的维护成本是什么。想办法用一种你的团队能够接受的方式来衡量它们。你可以用“oncall呼叫次数”，或者“涉及不止是链接到文档的支持请求数量”，或者类似的东西。深入你的数据，弄清楚团队的拖累来自哪里，然后把它降下来。在此基础上，写一份维护路线图来降低团队的成本。

把整个新功能路线图削减到一次只做一件事。把所有的WIP列出来，准备好砍掉几乎全部。我知道你在砍掉关键的东西——我们已经确认你已经砍掉了所有P2及以上的。列出你当前正在做或计划做的所有新事项，把它们放进新功能路线图文档。对它们做优先级排序（第一种），然后除了列表上最顶上那一项之外，全部砍掉。

不喜欢这个结果？不要把它想成是选择了一堆关键的事情去失败。把它想成是选择了一个关键的事情去真正成功。你现在有了一个列表，可以分享给团队内外的人，解释正在发生什么。

但是工程师X呢？他之前对项目Y特别兴奋。他可能会因为新被砍掉的功能失去势头而感到失望。但如果他真的关心业务影响，他会坚定地支持交付一个优秀的、长期有用的功能。如果他不在乎……那他关注的是技术而不是业务问题。反正你也不想要太多这样的人在身边。

我预测你的团队几乎会立刻因为有了一个连贯的焦点而感到如释重负。但是利益相关者A呢？他原本期待功能B在接下来几周/几个月内交付。我期望你的利益相关者也关心业务的长期健康。他们会因为你专注于交付业务影响而被说服一小段时间。预期这种效果会消退，喧嚣会回来。捍卫你的团队及其路线图将是一场永恒的努力，我会在下一节讲到这一点。

但是失去势头怎么办？我们已经投入到设计和启动其他工作中的努力怎么办？你之前确实有势头——你有很多小小的势头，意味着很多项目将要迟交且粗制滥造。这是沉没成本谬误，而且是一次性的、短期的问题。如果你能设法把WIP降到最低，你就不必再付这个代价。如果项目没有完全完成，所有那些工作都没有意义。顺便说一句，任何会拖慢实际承诺优先事项的部分工作都应该被视为拖累，并被移除。版本控制会为以后保留它。

那功能D呢？CTO刚给我发消息说这是一个紧急的业务需求。默认说不。不涉及政治斗争，我只说这一点：除非你在一家10个人的公司工作，否则CTO对你“地面上”的现实情况掌握的信息比你少。你可以给他们看你当前的新功能路线图，解释最高优先级在哪里。如果他们想让你把他们新的工作直接插在你当前最高优先级之后，那很好。

你真的在告诉我对CTO说不？CTO对你“地面上”的现实情况掌握的信息比你少。好的管理者知道这一点。他们可能会问你很多细节，但他们不会开除你。任何会因为坚持计划并真正为业务交付价值而开除你的管理者或高管，都不值得你为之工作。

所以现在，你已经承诺要进行一次大规模的、一次性的努力，对所有人说不。你已经把大量关键功能从WIP栏里砍掉了，你团队里的每个人一想到大家齐心协力实现少数几个艰难的目标，就开始感到振奋。你如何避免“WIP蔓延”，避免掉回陷阱？

你并不是在真空中掉进这个什么都做的陷阱的。你之所以这样做，是因为来自你自己和你的客户持续不断的压力，要求你立刻交付一切。你可以通过在事前大量地说不来应对这种压力。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）