本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Full Board, Zero Flow: Why Busy Teams Stop Shipping

More tickets, more tools, and more completed tasks do not automatically mean more productivity. Sometimes, the real improvement starts by removing work and reviewing tasks.

更多的工单、更多的工具以及更多已完成的任务并不自动意味着更高的生产力。有时，真正的改进始于减少工作量和审查任务。

If you work in software development, you probably know the routine. You file tickets, update the board, push commits, review pull requests, answer messages, and attend meetings. By the end of the day, there is plenty of activity to show for your time. Your sprint board has moved. Tickets have changed status. The activity logs are full. But is the project actually moving forward?

如果你从事软件开发工作，你可能很熟悉这套流程。你提交工单、更新看板、推送代码、审查合并请求、回复消息并参加会议。一天结束时，你有很多活动记录来证明你的时间没有白费。你的冲刺看板动了，工单状态变了，活动日志也填满了。但项目真的在向前推进吗？

I’ve been thinking about the difference between doing work and making progress. The two often overlap, but they are not the same thing. A lot of what we do during the day is necessary to get the job done, yet the volume of that activity doesn’t tell us how much useful progress we’ve made. And that’s where measuring productivity gets complicated.

我一直在思考“做工作”与“取得进展”之间的区别。两者经常重叠，但它们并不是一回事。我们白天所做的许多事情对于完成工作是必要的，但这些活动的数量并不能告诉我们取得了多少有用的进展。而这正是衡量生产力变得复杂的地方。

Activity is easy to measure. Productivity is harder. We have tools for practically everything. Project management systems track tickets. Git platforms record commits and pull requests. Communication platforms measure responsiveness. Dashboards summarize activity and turn it into charts. These metrics are useful. They help us understand workload, coordinate teams, and identify bottlenecks.

活动很容易衡量，但生产力则不然。我们几乎拥有处理一切事物的工具：项目管理系统跟踪工单，Git 平台记录提交和合并请求，通讯平台衡量响应速度，仪表板汇总活动并将其转化为图表。这些指标很有用，它们帮助我们了解工作量、协调团队并识别瓶颈。

The problem comes when we start treating them as direct evidence of productivity. A developer who closes twenty small tickets may appear more productive than someone who spends a day investigating a difficult architectural problem. But what if that investigation prevents weeks of rework? What if the twenty tickets were minor maintenance tasks, while the architectural decision determined whether the product could scale?

问题在于，当我们开始将这些指标视为生产力的直接证据时。一个关闭了二十个小工单的开发人员，看起来可能比花了一整天调查复杂架构问题的开发人员更有效率。但如果那次调查避免了数周的返工呢？如果那二十个工单只是琐碎的维护任务，而那个架构决策决定了产品能否扩展呢？

Counting completed tickets doesn’t tell us the difference. The same applies to commits, lines of code, meetings, and hours worked. They describe activity or output, but they don’t automatically establish the value created. This distinction is notable because being busy tells us that we’re using time, not necessarily that we’re using it well.

计算已完成的工单数量无法告诉我们其中的差异。提交次数、代码行数、会议次数和工作时长也是如此。它们描述的是活动或产出，但并不自动等同于所创造的价值。这种区别值得注意，因为“忙碌”只能说明我们在消耗时间，并不一定说明我们利用得很好。

What should we measure instead? At its simplest, productivity is about the relationship between output and the resources required to produce it. In many settings, that means examining output relative to time. For knowledge work, however, the definition of output deserves some attention.

我们应该衡量什么呢？简单来说，生产力是产出与生产该产出所需资源之间的关系。在许多环境下，这意味着根据时间来审视产出。然而，对于知识型工作，产出的定义值得深思。

A developer’s output isn’t necessarily the number of lines written. Sometimes, a small change removes a major source of complexity. Sometimes, a few hours of debugging resolve a recurring production issue. Sometimes, the best contribution is discovering that a proposed feature isn’t worth building. The visible output may be small, while the impact is substantial.

开发人员的产出不一定是编写的代码行数。有时，一个小小的改动就能消除一个主要的复杂性来源；有时，几个小时的调试就能解决一个反复出现的生产问题；有时，最好的贡献是发现某个提议的功能根本不值得开发。可见的产出可能很小，但其影响却非常重大。

The same principle applies outside development. A technical lead who clarifies an architectural decision might save several developers from implementing incompatible solutions. A manager who removes an unnecessary approval step could shorten delivery time across an entire team. Neither contribution is adequately represented by counting completed tasks.

同样的原则也适用于开发之外。一位澄清了架构决策的技术主管，可能会让几位开发人员免于实施不兼容的方案；一位取消了不必要审批环节的经理，可以缩短整个团队的交付时间。这些贡献都无法通过计算已完成的任务来充分体现。

This doesn’t mean every discussion, investigation, or management activity is productive. It means we need to look beyond the activity itself. What did the work produce? What changed as a result? Did it improve reliability, reduce uncertainty, remove a constraint, or help someone else make progress? Those questions are more useful than simply asking how much work was completed.

这并不意味着每一次讨论、调查或管理活动都是富有成效的。这意味着我们需要超越活动本身去看问题：这项工作产生了什么？结果带来了什么改变？它是否提高了可靠性、减少了不确定性、消除了约束，或者帮助他人取得了进展？这些问题比单纯询问“完成了多少工作”更有意义。

Your tools can create work of their own. Here’s another trap: once we have a tool, we tend to build processes around it. We introduce a project management platform to improve coordination. Then we create additional fields, require more status updates, build dashboards, and schedule meetings to review the information. Eventually, maintaining the system becomes another part of the job.

你的工具可能会创造出额外的工作。这是另一个陷阱：一旦有了工具，我们往往会围绕它构建流程。我们引入项目管理平台来改善协调，然后创建额外的字段、要求更多的状态更新、构建仪表板，并安排会议来审查这些信息。最终，维护这个系统成了工作的一部分。

Some of that overhead is justified. We need enough structure to make work understandable and to coordinate dependencies. But a tool can become an additional source of work without producing a corresponding improvement in results. The fact that a tool is available doesn’t mean we need to use every feature. And the fact that a process is automated doesn’t mean the process needs to exist.

其中一些开销是合理的。我们需要足够的结构来使工作变得可理解并协调依赖关系。但如果一个工具在没有带来相应结果改善的情况下，反而成了额外的工作来源，那就得不偿失了。工具可用并不意味着我们需要使用它的每一个功能，流程自动化也不意味着该流程本身就有存在的必要。

Automating a report nobody reads simply makes unnecessary reporting faster. Tracking a metric that doesn’t inform a decision adds information without necessarily improving anything. The same applies to our daily routines. We can spend considerable time organizing work, updating work, and reporting on work while leaving less time to perform the work that matters. Tools should support the work, not become the work.

自动化一份没人看的报告，只会让不必要的报告生成得更快。跟踪一个无法为决策提供参考的指标，只会增加信息量，而不一定能带来任何改善。这同样适用于我们的日常工作。我们可能会花费大量时间来组织工作、更新工作和汇报工作，从而留给真正重要工作的时间就变少了。工具应该支持工作，而不是成为工作本身。

Full utilization isn’t the same as fast delivery. There is a related problem with keeping everyone fully occupied. In development, work rarely flows without interruption. A pull request waits for review. A feature depends on an API change. A production issue takes priority over planned work. A technical decision blocks three other tickets.

“充分利用”并不等同于“快速交付”。让每个人都处于满负荷状态存在一个相关的问题。在开发中，工作很少能不间断地流动：合并请求在等待审查，功能开发依赖于 API 的变更，生产问题优先于计划内的工作，一个技术决策阻塞了其他三个工单。

If everyone’s schedule is already full, dealing with an unexpected dependency means postponing something else. Work accumulates, context gets switched, and tasks spend more time waiting. This is the utilization paradox: keeping every person busy can make the overall system slower. A team needs some capacity to handle variability, review work, resolve blockers, and respond to unexpected problems.

如果每个人的日程都已经排满，处理突发的依赖关系就意味着必须推迟其他事情。工作堆积，上下文频繁切换，任务在等待中耗费了更多时间。这就是“利用率悖论”：让每个人都忙碌起来反而可能使整个系统变慢。团队需要留出一定的余力来处理变数、审查工作、解决阻塞并应对突发问题。

That capacity may look unused on an individual schedule, but it can help work move through the system more quickly. This is also why maximizing the number of active tickets is a poor objective. Ten tasks in progress aren’t necessarily better than three tasks moving steadily toward completion. More work in progress often means more context switching and more unfinished work to manage. The goal isn’t to keep everyone occupied at every moment. It’s to help valuable work reach completion reliably.

这种余力在个人日程表上看起来可能像是闲置，但它能帮助工作在系统中更顺畅地流动。这也是为什么将“活跃工单数量最大化”作为一个目标是很糟糕的。十个正在进行中的任务并不一定比三个稳步推进的任务更好。更多的在制品通常意味着更多的上下文切换和更多需要管理的未完成工作。目标不是让每个人时刻保持忙碌，而是帮助有价值的工作可靠地完成。

Try subtraction before optimization. When productivity feels low, the instinct is often to add something: another tool,

在优化之前，先尝试做减法。当感觉生产力低下时，人们的本能往往是增加一些东西：另一个工具，