全都重要，但全都没做！【中】

手把手教你解决复杂的团队组织问题，包括单堆等级、团队依赖、建立共识、减少 WIP 工作量、让公司有更好的优先管理方向。

本篇文章分为【上】【中】【下】三篇，欢迎点击下列链接查看全文：

全都重要，但全都没做！【上】
全都重要，但全都没做！【中】（本文）
全都重要，但全都没做！【下】

假设有人（上层管理或其他小组）突然给你了个“火烧眉毛”的项目，说“这个工作要优先完成，必须立即着手开始做”，你就可以参照这个标准来处理，可以直接问：“这个工作排第几？在我现在正处理的工作之前还是之后？"

因为各个项目是相互关联的，我们可以周期性地调整项目的堆栈排序。

要注意的是，调整堆栈排序也是一个非常复杂的过程。因为单堆等级是公司管理工作的一个非常重要且有效的工具，所以非常有“权力”。大家都得根据这个等级排序来确定各阶段最重要的工作和可以暂时延后的工作。

第 4 步：开始工作，“从编号 1 的项目着手，每次只进行一个项目，直到该项目完成”

有了单堆等级之后，就可以从排序第一的项目做起。

尽管听起来很简单，但在实际操作中没这么简单。

我们不惜一切来确保排名第一的项目的交付，为负责该项目的小组扫清一切障碍，给予其征用任何资源的权力。

因为倾尽全公司之力来交付一个项目，所以不可避免地会拖延其他项目。

但这种取舍是对的，不取舍会出现之前那样什么都完成不了的状态。相信大家都知道什么才是正确的选择。

完成了第一个项目之后，就可以进行下一个项目。

当然，完成第一个项目不需要产品工程组全员出动。Fred Brooks 50 年前就说过，“如果一个项目已确定无法按时交付，增加再多的工程师也无济于事”。他老人家说得对！大家一定要明白，往项目上“猛砸”工程师并不能促进项目的成功交付。

我们要把项目看作一列穿越繁华都市的火车：我们最优先的项目包括火车，也包括火车经过时要关闭的闸门。完成一个优先项目不需要所有的工程师和项目经理同时工作，需要的是全局统筹。调配需要的专业技术和人才，审查或增强任何需要的因素，必要时暂停其他项目。正如上面说到的火车一样，火车经过城市时，如果需要扣押任何车，就扣押；如果需要阻拦任何项目，就阻拦；如果任何物品在火车要经过的轨道上，那就撞过去。

第 5 步：找到并解决组织制约因素

每次只关注一个项目很有效，但是久而久之就会有疑问，这种疑问会逐渐增强：“团队一共 40 个人呢，应该不止能做一个项目吧？”

是的，如果我们把全部的精力都放到一个项目上，无论这个项目处理多么完美，其他项目都会因此受损。我们不可能直接停掉其他所有项目，只能勉力维持，但是项目必然会被拖延，因为核心成员都被拉过去支持排序第一的项目了。

Ryan Holiday 说过“逆境才是正路”。我们要勇于直面困难，困难可以让我们认识到自己的组织局限性，了解团队的具体情况、工作流程及基本架构，找出其中导致工作效率低下的因素。

每个团队的组织制约因素都不同，但表现形式都类似。我们公司也一样，主要有三大制约因素：

在多数项目上，我们都表现出高度的跨团队依赖 。没有任何一个小组能单独搭建或部署一个关键项目。每个小组只能在项目交付的过程中作出少量贡献，所以如果项目时间重合就会很麻烦。
因为每个小组都参与所有项目，导致大家都有很多正在进行的项目（WIP）。这个 WIP 通常是隐藏的，因为相关的团队不是很明确。
项目范围过大。项目越大，需要花费的时间越长，面对的风险越高，需求渐变的可能性也越高。

这问题你也可能会遇到。

制约因素 1：高度的跨团队依赖

我们创建统一工作视图的同时，也要确定每个项目具体由谁来交付。每个项目的正式文件上通常会写明由一个小组负责，但一般主导小组会和其他小组合作完成项目。

我们对每个项目的细节进行深挖，发现许多项目需要工程部门的全力参与。纸面上看，我们主要倚重一到两个小组，其他小组负责的项目相对较少。

这似乎是不正常的，所以每次出现这种情况时，我们都记录下来。

如果交付一个项目需要整个工程部门的支持，要么是项目很大，要么是小组独立运行能力不足。

我们是这两个问题都有。我们发现小组独立运行能力不足往往与小组业务能力不均衡密切相关。

我们都依靠工程部门来进行功能开发。各小组都逐渐有了自己的架构，但对整个平台代码不够了解，无法搭建新的跨架构功能。另外，当历史功能变成了关键的平台功能，先前的小组成为了服务维护人员或限制因素。另外，他们不搭建自助服务 API，这是另一个问题。

试想一下，一个小组为了创建“用户配置”功能，已经花费了一年多的时间，最终形成了自己的配置架构。他们拥有每个功能的所有用户配置权限。如果项目搭建任何新功能，而新功能需要用户配置权限时，就需要该小组的参与。因为几乎所有功能都需要用户配置权限，所以这个小组变成了一种限制因素。

这就是我们说的隐藏依赖。没有小组能独立交付项目。简单来说，我们要解决业务问题，但用错了小组，而且组织设计也不对。用人没有问题，只是对人进行了错误的分配。因为这些小组不是随机分配的，所以反映了一个潜在的问题，即各部门的组织设计和业务需求不匹配。这些小组是根据自己的人员选择和技术所有权这些内部逻辑发展的。

发现这些隐藏依赖就会引出另一个问题：

制约因素 2：同时进行的工作太多

因为隐藏依赖或确实有很多工作，小组需要同时处理多项工作，导致投入到每个项目上的精力就会被分散。

我们发现，同时处理的项目的数量与完成单个项目的难度呈正相关，这就是 WIP 问题。

讨论 WIP 影响项目进程的文章有很多，根据这些文章，出现 WIP 问题一般因为以下四种模式：

模式 1：分配给每个项目的时间
项目数量增加，分给每个项目的时间就随之减少。假如每人每天的工作时间是 8 小时，如果只用处理一个项目，就可以把 8 个小时都用在这一个项目上。但是如果要同时处理两个项目，要么把 8 个小时都投入到一个项目上，要么把时间均摊，每个项目 4 小时，当然也可以随机给两个项目分时间。如果需要同时处理 8 个项目，要么把时间平均分给每个项目，每个项目 1 小时，要么给其中一个项目分好几个小时，直接忽视掉一些项目。结论就是，要处理的项目越多，能分配到每个项目上的时间就越少。大家可以用这个公式计算一下：一天的工作时间（或一周的工作天数）/项目数量
模式 2：个人切换成本
随着项目数量和在项目间切换的次数的增加，个人在多个项目间的切换成本（时间、生产力）也随之成倍增加，重新熟悉一个项目的背景和代码库要花费时间，还要与其他人员协调，排除各种干扰，一个小时的工作时间里大概一半时间在浪费在“元”准备工作上。
模式 3：时间碎片化
工作人员需要长而完整的时间段来工作，但模式 1 和模式 2 导致的时间碎片化会打乱大家的工作节奏。经理能在短时间内中跨越许多项目，因为他们只需要了解项目的高层抽象内容，但项目负责人需要了解项目所有的具体细节和执行细节，所以时间碎片化严重影响管理效率。
模式 4：因为严重的跨团队依赖，我们创建了组织协调税。与切换成本不同（转换成本会因个人的参与程度和专业程度的不同而不同），协调税是统一的，对任何人都一样：

所需的连接（以及协调）的数量可以建模成 N(N-1)/2，其中 N 是人数。换句话说，随着问题中人数的增加，协调量会越来越大。*

制约因素 3：项目范围过大

另一个组织制约因素是项目太大!

这种“大”表现在各个方面：工作范围太大、交付期太长、每个项目都需要有太多人参与。

项目的范围过大会出现下列情况：

项目交付期很长，这意味着很长一段时间都被锁定在这个项目上，这段时间没有创造价值。
换句话说，项目交付后有人使用，才能创造价值，在项目被交付之前，创造的价值都为零。
项目交付期长就可能会出现需求渐变——不，必然会出现需求渐变。随着时间的推移，客户会发现更多的需求，客户的偏好、管理和模式等都会变化。项目进行的时间越长，引入新请求的日历窗口就越大。客户提出的请求越多，就越难拒绝，不然会被认为无法满足新的新业务需求、不合作或响应迟钝。
反过来说，项目工作窗口越短，需求变化的机会面就越小。两周的冲刺项目比两个月或两年的项目的机会面更小，而且因为工作间隔更短，就可以更快地响应客户的需求。随着每个间隔的结束，你可以在不影响当前工作的情况下改变范围。
项目交付期过长，就会出现人员离开（或新管理层进入）、合同/预算/业务需求改变等系统性风险。每一项都代表了项目范围过大的潜在风险，并且项目进行的时间越长，这些风险就出现的可能性就越高。

本篇文章分为【上】【中】【下】三篇，欢迎点击下列链接查看全文：

全都重要，但全都没做！【上】

全都重要，但全都没做！【中】（本文）

全都重要，但全都没做！【下】

原文作者：Roman Kudryashov
原文链接：When Everything is Important But Nothing is Getting Done