全都重要，但全都没做！【下】
手把手教你解决复杂的团队组织问题，包括单堆等级、团队依赖、建立共识、减少 WIP 工作量、让公司有更好的优先管理方向。
本篇文章分为【上】【中】【下】三篇，欢迎点击下列链接查看全文：
- 全都重要，但全都没做！【上】
- 全都重要，但全都没做！【中】
- 全都重要，但全都没做！【下】（本文）
目录
解决制约因素
单一堆栈等级解决了“我应该做什么”这个问题。
针对范围过大的问题，我们花费了大量的时间，将大型项目分解成小项目。我们并不是把六个月的项目一下子转变成两周的冲刺项目，而是把六个月的项目被分解成一个个周期为两个月的功能开发项目，我们的集体实践就是在大型项目中找到更小的可交付部分。历经近 9 个月的时间（其中包括完成无法重新调整范围的项目的时间），我们成功过渡到了一个较好的状态，大多数小组每两周（或更短时间）可以对产生价值的项目进行生产部署。
我们规定只有排名第一的项目才可以让所有人都参与，暂时解决了“太多的 WIP 让每个项目陷入困境”的问题，如果一次只做一个项目，就不会有太多的工作。
但这是一个渐进的过程。
我们仍然收到了很多质疑：“你们有一个 40 多人的工程团队，应该能同时做多件事吧！”
正如我前面提到的，当考虑到有效的并行化时，团队的规模并不重要，重要的是团队的独立程度。
完全独立的团队能够在处理正在进行的项目的同时处理新项目。如上所述，由于协调和沟通等间接成本，有依赖关系的团队的时间线被拉长了。
我们把全部团队能力集中在排序第一的项目上，有效地创建了一个伪独立团队，拥有交付项目所需的全部资源。这个方法很有效:第一个项目成功完成，交付速度更快，缺陷率更低，并且开发人员对这个项目有更高的满意度。
这一成功说明解决小组间的依赖可以扫平项目障碍，为将来依据业务需求进行的更广泛的部门重组提供支持。
阶段性管理重组
截至目前，团队重组是单一堆栈等级最难处理的问题，也是最重要的，因为团队重组让我们的工作并行化的能力有了质的提高。
从高依赖性到低依赖性，工作的平行化只有在高度独立的团队中才有可能。提醒大家，要注意隐藏的工作和依赖。
这种改变并不容易；随着项目的发展，我们不断发现隐藏的依赖，并发现我们的架构中存在很多阻碍端到端交付效率的因素。我们还知道了我们在哪方面存在技能差距或技能过剩，了解了我们的团队的可替代性。
最重要的是，这种组织变革影响了工程师个人和管理人员的心理安全。人们害怕打破管理关系会影响他们的职业发展轨迹和年度目标评估，担心学习新的代码库及与新人合作会降低效率。
我们缓慢而渐进地进行重组。一开始，我们不太确定究竟需要什么样的组织，但因为我们有一个稳定的方向，所以我们认为这是一个动态变化的过程，要通过下层的投入来为上层的决定提供信息。
我们考虑的三个关键因素是：（1）心理安全；（2）建立共识并投入；（3）解决沟通问题，防止信息在传递过程中出现失真。
实施每个“改革”的会议节奏如下：
-
介绍/预售
首先，介绍我们面对的挑战以及我们的解决方案。 通常会有两到三次这样的介绍，首先是在一个小的工作小组，然后是对所有的经理/主管，然后是对整个团队。每次会议都是一次测试信息的机会，我们根据大家的反应，判断大家会对哪些做法有抵触情绪，然后进一步完善解决方案。 -
通过 1 V 1 的方式进行研讨
然后，我们将与尽可能多的关键团队成员进行 1 V 1 会谈，解决他们的担忧和问题。许多人不愿意在公共会议上提出问题，或者有个人的具体问题。1 V 1 谈话也可以让我们提前与有影响力的高级管理人员沟通，毕竟如果他们不买账，很可能会成为破坏者。针对高级管理人员，我们有时会举行两到三次会议来解决他们的顾虑。我们也会利用这个机会对行动计划进行“深度推介”，将每次谈话作为一次机会，对计划和沟通进行测试，这一步非常重要。 -
最后的路演/说服
然后，我们将举行最后的“路演”会议，推出计划的最终执行细节。这就是我们在之前的各种与个人的谈话中讨论的所有内容，现在传达给所有人。每个人都得到了同样明确的信息，强化了之前已经讨论过两次的内容。
后来，一位新来的副总裁告诉我，日本有一个术语“Nemawashi”，意思是为任何大的变革打下基础。我当时不知道，但我熟悉这个模型： Lippit-Knoster model of managing complex change。这个模型是整个过程的宝贵指南：
如果读完这篇文章只记得这个模型，就已经很有价值了。
第 6 步：确定一个明确的终点/完成线
我们做的最后一件事是关注结局：工作如何结束。
这样做是因为许多项目有演变成“僵尸项目”的倾向。如果你对“完成”的定义不够严谨，就有这样的风险：一个项目被关闭了但没完全停止，然后它又神奇地复活了，干扰对其他事情的处理。因为隐藏工作和 WIP 的增加，就会立即导致工作效率的下降。
在僵尸电影中，“完成”的定义是：僵尸的头被炸掉，或者被点燃变成灰烬。当然，我们没有要把项目经理消灭掉，但我们实施了一个严格的标准，划了一条明确的项目完成线。在这条完成线之后，与该项目相关的任何新工作或返工都必须作为一个独立的工作放进堆栈等级，与其他项目进行排序。
关于“完成”的定义有三个关键问题：
-
用户的问题解决了吗？
我见过的常见的需求渐变是将终点从解决一个问题转移到了解决另一个问题。这表现为“是的，用户现在可以做那件事了，但他们还想做另一件事。”但“另一件事”是另一个项目，不是当前项目的终点线。有可能这个项目很重要，有可能会被列为下一个排名第一的冲刺项目，但在项目之间划出分界线非常重要，因为“还有一件事！”这句话有可能毫无止境。 -
项目被部署到生产中了吗？
我们有很多项目都是“代码完成”，但没有部署，他们只是处于静止状态，等待成为僵尸项目。我们要考虑测试和生产部署，因为“代码完成”通常只是一个项目的 25~50% 的工作。在测试和部署期间，经常需要额外的开发工作(“它在我的笔记本电脑上运行良好”之类的问题)。 -
它已经被用了“足够长”的时间了吗？
“足够长的时间”比较模糊，其实你要找的是一些验证：(a)该功能确实正在被使用；(b)没有大量的 bug 或因使用产生的bug；(c) 使用该项目确实解决你设定的问题（再看第一个标准）。根据数据和反馈循环，这“足够长”的时间有可能短至一周，但也可能很长，要根据个人需求而定。
你在任何项目中的目标都应该是解决用户的问题，而不仅仅是交付功能。如果你交付的东西没有解决问题，那么实际上还没有完成项目，就需要重新开始。可以参见脚注 7 对组织成熟度的解释。重点是，一个公司从功能导向转变为解决方案导向需要时间，如果你的公司目前仍以功能为导向，标准(a)和(b)仍然是有用的。
代码后的等待期一开始很痛苦，因为团队觉得他们是在浪费时间。我们把这些“未使用”的时间重新集中到计划、回顾、更合理的工作时间、偶尔的重构和其他元工作上。这也促使我们开始把团队的思维从开发导向（搭建更多的软件）转向解决方案导向（解决问题）。
建立从用户和数据到产品经理和工程师的反馈回路，告诉他们的“完成度”是提高团队满意度的重要一步，因为大家能够开始看到他们对用户体验及公司发展的影响。
第 7 步：循环整个工作流程（这是一个过程）
在这一点上，我们已经围绕正在进行的工作建立了可见性，对工作进行了排序，改变我们的团队结构，使其以解决方案为导向，而不是关注内部，开始解决组织上的制约因素，为获得认可和解决沟通问题建立了一个循环，并建立了明确的完成线。
我们花了大约 6 个月的时间来完成这一转变，又花了 3 个月的时间来继续完善这一过程，目前一切朝着积极的方向发展。项目的障碍被扫清了，我们按时交付了两个重要的紧急合同，缺陷率也是历史最低水平。整个团队士气高涨，员工调查的满意度得分变高了，更重要的是，离职率大大降低 （从 50% 的季度离职率变成了大约 4% 的季度离职率，其中一个月零离职）。
但我们仍然不能放松。我们按顺序工作，逐步解决问题，但每一步都有人在抱怨问题，试图在不了解导致问题的原因的情况下解决问题。每一步都有一些领导想提前开始重组或承担新的项目，不先解决依赖或 WIP 问题。我们没有解决这些问题的灵丹妙药，只有耐心和详细地沟通，让他们理解我们为什么这样做。
我唯一的建议是警惕那些导致不良模式的决策，并尽量与这些人沟通。尽管我感觉自己一直在说重复的话，但我从来没觉得多沟通有什么坏处，也没人抱怨我告诉他们太多事情。大多数情况下，人们会有选择性地听，或心不在焉地听，所以当我第二周（第三周）重复说过的内容时，听众会不断接收到“新”信息。
我再重复一遍：那些糟糕的决定和要求从来没有消失过，我们一直在努力解决这些问题。当我们取得的进展越多，人们就越信任这个流程。每天的向上/向下管理仍然很重要，但我们理顺了公司的工作流程，重建了信任。如果有一天这种模式不再适合公司，需要新的模式，团队结构需要再次改变，评估项目的标准也需要再次确定，但只要继续保持能见度，管理 WIP 和其他制约因素，继续建立跨部门共识，我想公司很快就会好起来。
小结
这是一篇很长的文章。但我读过很多关于人们如何解决工作中的挑战的文章，有人笼统地说：“我们实施了[x]，它解决了我们的问题！”我会很失望。为什么能成功？问题和背景是什么？
我想强调的是，对于具有挑战性的组织问题，并没有“只需一个简单的技巧就能解决”的解决方案。这些问题经过长时间的积累，形成了根深蒂固的、有时是无意识的组织行为模式。没有人打算建立不起作用的流程，但有的流程反而会错上加错，随着时间的推移，足以造成组织的僵局。
此外，很难预测什么会导致这个问题，这就是为什么我写的是我们如何摆脱它，而不是陷入它。公司不同，解决方案就会有所不同，但我发现这个解决问题的模式在三个不同的公司中都是有效的，大家可以根据问题严重程度和背景进行调整。
这也不是永久性的解决方案。这是一个需要管理的流程。就像一个组织一样，这些流程也会僵化成模式，导致拖慢效率，阻碍工作的完成，所以也要警惕这个问题。
此外，这是一个需要全公司参与才能维持的过程，我说的改革不仅涉及产品和工程团队。我们的目标也是全公司的目标，其他部门也要参与我们的项目。我们希望每个关键利益相关者和决策者都参与进来，使团队真正实现端到端。所以我们需要销售、市场、运营、财务甚至人事等部门的同事都参与进来。
这段时间里你会经常听到我说，任何部门所面临的核心问题并不完全在该部门内部，而往往体现在他们与其他部门的合作上。例如：我们的产品管理团队所面临的挑战不能完全在产品管理部门内解决，因为他们要依靠工程部门来执行。工程团队所面临的挑战源于产品管理方面的决策，也源于销售方面的决策。当我们作为一个团队走到一起，并同意在同一方向上同时工作时，奇迹就出现了。
因此，即使你读到这里，认为“哦，这与我面对的问题不一样”，但如果你能够理解这个行为模式，能够观察其他人所做决定的因果关系，并试图解开某些决定实施背后的 “原因”，这篇文章对你就仍旧有价值。
总结
文章太长，总结一下主要内容：
-
就存在的问题达成共识，并就寻求解决方案达成一致。如果人们不同意，你就会受到阻碍。如果没有目标，就会感到困惑。
-
创建一个所有现有工作的统一视图。我们创建了一个所有项目的统一视图，将所有项目组织到一个统一的电子表格中。如果没有可见性，你将不断被“未知情况”所蒙蔽，这是基本的态势感知。
-
创建和实施项目的比较标准。我们创建了一个评估工作的影响和紧迫性的标准，这是帮助我们评估项目的相对优点的元数据。
-
对项目进行排序并按照顺序处理项目。一旦我们有了比较元数据并评估了所有的项目，我们就可以开始对工作进行排序。这是一个艰难的过程，因为人们对相对价值有非常强烈的意见，排序中的相对位置也是如此。
-
一次做一个项目，按顺序进行。在有了单一的队列/堆栈等级之后，我们开始处理项目，从 1 号开始往下做。我们确保当前的 1 号项目有一个全权负责团队，并且提供给该团队所有便利条件，他们有权征用任何资源来实现项目的交付。
-
识别并解决你的组织制约因素。每一个在第一优先级之外的项目所遇到的问题是我们确定制约因素的指南。对于我们来说，主要制约因素有：进行了太多的工作、团队高度依赖以及项目范围太大。
-
建立明确的终点线。作为解决制约因素的一部分，我们创建了一个明确的“完成”定义，使项目与业务目标保持一致，防止再次出现制约因素。
-
继续整个过程循环。当引入新的工作和新的项目时，将其排在堆栈等级的适当位置上。这不是一种破坏，而是一种理想的结果，让所有员工的工作总是与最高价值保持一致。
结论
• 更高的效率：项目更快交付。
• 更高的工作质量：拥有所需的支持意味着更少的走捷径、更多的测试以及更好的交付。
• 更低的协调成本：协调和支持问题被单一的堆栈等级所取代，每个人都清楚工作的权重。
• 更高的满意度：更少的冲突和成本意味着有更多的时间工作，不搞办公室政治。同样，更高的效率意味着更好的结果和反馈回路，更好开展工作。
谢谢你的阅读。
这篇文章有用吗？有趣吗？有什么不足之处吗？如果你有任何想法，欢迎随时联系我。
我非常愿意倾听读者的意见，所以请随时给我留言，也可以通过邮件联系我（hi@romandesign.co），我一定会回复的！
本篇文章分为【上】【中】【下】三篇，欢迎点击下列链接查看全文：
- 全都重要，但全都没做！【上】
- 全都重要，但全都没做！【中】
- 全都重要，但全都没做！【下】（本文）
原文作者：Roman Kudryashov
原文链接：When Everything is Important But Nothing is Getting Done