技术领导力：四招教你让团队高效运转

要点

• 精简事项；集中精力做好本职工作。

• 依赖会破坏流程。分解并消除依赖关系，以提高团队完成工作的能力。

• 集中注意力推动工作前进，而不是让大家碌碌无为。

• 对客户有用的工作成果才能带来投资回报率。这意味着瞎忙是不行的，完成工作更重要。

• 对于团队来说，能够推动工作前进比保持团队规模更重要。首先让工作进展顺利，然后考虑如何在不影响流程的情况下缩小团队规模。

无论团队或组织的规模有多大，要做的事情总会比能做完的事情更多，所以让工作有条不紊是非常重要的。在本文中，我们将讨论实现运营流程和提高技术团队质量的四个步骤。

不幸的是，工作往往不像奔腾的河水一般顺畅流动。它常常陷入困境，直到有人有时间去推动它前进为止。但这个问题也不是没有解决办法。

下面我们就来讨论能让你的团队重新动起来的四个有用技巧。

一、少做事

这听起来很矛盾，但其实完成更多工作的秘诀是减少工作量。人类处理多任务的能力非常差。一个简单的事实是，我们无法同时专注于多件事。当我们一次只做一件事并一直把它做完时，我们的效率最高。这一事实的背后是多种因素的共同影响：

• 上下文切换。我们的工作记忆中保存了大量信息。当我们专注于一件事情时，很多相关的背景都会留在我们的脑海中。当我们切换到其他内容时就会失去所有的上下文。下次我们开始这项工作时，我们必须重建上下文信息存储。我们切换的次数越多，在上下文切换上浪费的精力就越多。

• 认知负荷。我们一次能处理的事情就这么多。我们能记住的东西是有限的。当我们只做一件事时可以掌握大量相关信息。如果我们必须要同时做两件事，我们能保存的信息量就会减少 50% 以上（工作量增加 + 上下文切换）。我们要做的事情越多，对其中任何一项工作的关注就越少。

我曾经指导过一些领导者，他们发现自己整天都在不停开各种会，直到一天结束却感觉自己没有完成任何事情。

如果这听起来是很熟悉的情况，那么你肯定知道这个问题是怎么出来的。

忙上忙下会给人带来富有成效的错觉，但这往往会导致我们无法完成那些重要的事情。

做一件事，直到做完为止，然后做接下来的事情。

二、去除依赖项

我们的工作进度往往受制于团队之外的人们。有时我们需要一些外部信息，还有时其他团队需要先完成他们自己的那部分工作，然后我们才能继续开展我们的工作。我们希望尽可能打破这种依赖关系。

如果你的工作需要先等另一个团队完成某件事后才能继续下去，那么在他们完成自己的部分之前先不要做事。虽然这个项目可能是你目前的首要任务，但其他团队可能还有其他事情要做，他们有自己的首要任务。你也说不准他们什么时候才开始做你所依赖的那部分工作，或者开始后需要多长时间才能完成。

如果这项工作非常关键，并且对你的团队来说没有什么比这更重要的了，你可以 a) 帮助其他团队完成他们的工作，以便他们可以专注于你需要的任务上，b) 自己完成相关工作，或 c) 改变项目设计，消除依赖项。

消除依赖关系通常需要大量努力。依赖关系往往是组织中另一部分持有的专业知识或过去的架构选择带来的结果。人们常常感觉依赖是不可避免的，去除依赖项也会是痛苦且耗时的过程。这个想法有道理，但问题是它们只需要删除一次，团队就用不着再管这些依赖项了。今天的投资是为了明天获得更好的结果。

几年前，我与一家银行合作，通过举办大型规划会议来处理依赖问题。在这些会议期间（因为大家关系不错，做事利索，参加会议的感觉很好），只要各个团队能把握得住，下一个季度的计划会做得尽可能详尽周到。大家会识别和映射出来各种依赖关系，这样工作将在哪里陷入困境就很清楚了。许多团队的工作往往会依赖于单个团队才能完成（例如安全审批，或平台团队为其他团队准备工具和弹药）。很多团队的工作进行到一半就会停下来，等待他们所依赖的团队有空解决他们的问题。这时候上面一般会给闲下来的团队派发别的任务，但对于组织来说，这些任务永远不会像被卡住的工作那么有价值。

相比之下，我最近在与一家大型企业合作，这家企业将它的所有系统都做成松散耦合和独立的结构。每个团队都拥有完成自己优先事项所需的所有能力。依赖性对他们来说完全就不是问题。他们可以根据业务需要，以适合市场的速度行动，不过一开始他们也不是这样的。五年前，他们的处境和上面提到的银行差不多。关键的区别在于，他们没有管理依赖关系，而是有意把它们分解掉了。

打破依赖关系是用短期痛苦换取长期收益的典型例子。

三、专注于推动工作前进，而不是让人们碌碌无为

工作本身并没有价值。为了让它变得有价值，它的成果必须在正确的时间出现在正确的客户面前。在那之前，它不会产生任何收入。这意味着仍在进行中的工作本身没有任何价值。客户付钱不是让我们瞎忙，而是让我们解决他们的问题。更重要的是，客户拿不到工作成果意味着客户不会掏钱。

这牵扯出很多问题。如果工作只有向客户提供了成果才有价值，那就意味着正在等待某人完成的工作是没有价值的。更糟糕的是，拖时间的工作正在赔钱，因为客户在成果就绪之前不会付款。准备时间越长，损失的潜在收入就越多。

因此，组织的重点应该是（以高标准）完成工作并将其呈现在客户面前。根据我们上面了解到的情况，这意味着看大家每天有多忙是没意义的。要跟踪的最重要的指标是一项任务从开始到结束，在系统中移动所需的时间。

更重要的是，如果不同区域之间存在依赖关系，那么其中一些区域应该闲下来。如果我们的目标是在系统中快速推动一项工作前进，那么等待人们理解上下文、放下他们正在做的其他事情或完成其他事情所花费的任何时间都会减少我们从这项工作中获得的潜在收入。一些员工应该提前空出手来，为这项工作随时做好准备。

毫无疑问，这意味着有些人会闲下来。事实上，为了从组织中获得最大的价值，从而获得最大收入，让一些员工闲下来是绝对必要的。

在从高依赖到低依赖的转变过程中，我之前提到的公司经历了一段依赖关系被打破但还没有消失的时期。为了保持工作进展，他们会排定各项工作的优先级，每当一项任务从一个团队转移到另一个团队时，重心也会随之转移。结果是最高优先级的工作以最快的速度在组织中流动，因为它是每个团队的最高优先级，这意味着它总是最先完成的。

这与我在与企业合作时经常看到的情况形成鲜明对比，其他公司总是会让大家随时都有事情做。无论是通过衡量利用率还是让团队超负荷来做到这一点，结果都是一样的。当团队一直疲于奔命时，他们就会失去对变化做出反应的能力，延误会失控，工作进度也会慢下来。由于我们已经确认，工作成果只有在正确的时间出现在客户面前时才变得有价值，因此闲置、等待有人空出时间后才能继续的工作从定义上来说是毫无价值的。

下面是我与银行合作的真实例子。一项网站变更预计每周可带来 200,000 美元的收入，并且只需要一周的工作量。由于重心不清和优先级不匹配，这个项目被排到了另一个团队的任务队列中，结果被推迟了 9 个月。银行在这 9 个月（约 40 周）内损失的收入是：8,000,000 美元。如果需要完成这项工作的团队那时没在做其他事情，只是腾出手等待任务，那么他们每周的空闲成本约为 20,000 美元。显然，在财务上更精明的做法是让团队闲下来待命，直到最重要的工作出现。不要用次要工作分散他们的注意力——那是捡芝麻丢西瓜。

团队的任务列表中的工作越多，那些工作需要等待的时间就越久，因此损失的未实现价值（即金钱）就越多。

所以重点在于推动工作前进。

四、消除孤岛

摆脱依赖是一个开始，但有时这可能做起来很难。如果一个团队需要的知识并不在团队内部，或者需要达成的条件只有另一个团队中的人员才能实现，那么这里就会存在天然的依赖性。解决这个问题的传统方法是向其他团队提出需求，然后等待他们完成。

如果我们采取另一种方法，将团队在系统中推动一项工作前进所需的所有技能都提供给这个团队，那么速度就会快得多。然后团队就有能力独立完成所有步骤了。它不必依赖于另一个团队，谁都不应该依赖别人来做事。

几年前我曾合作过的一家健康保险公司在交付方面遇到了困难。他们过去没遇到过这种问题，需要我们帮助弄清楚这里面到底发生了什么。在调查中，我们发现他们采用的新运营模式将软件的构建和运行区分开了。构建软件的团队支持这个模式是因为：

• 质量更高

• 响应时间更快

• 失败的事情更少，并且

• 交付了更多工作。

这一变化虽然在纸面上合乎逻辑，但增加了交接摩擦，这意味着：

• 支持团队对软件不够了解，因此不得不打扰交付团队以获得帮助

• 交付团队对支持团队所求助的软件也没那么熟悉了，因为他们已经转向了新的东西

• 移交文件占用了很多时间

• 移交文件总是不完整（这是不可避免的）

• 有些事情被错过了

新的规划未能考虑到交付团队花费在帮助支持团队上的时间，这意味着每项工作到最后都会面临时间紧张的压力。

同样的变化意味着数据库更改和查询不再那么容易访问了，这引入了另一组延迟。事实上，唯一没有受到影响的团队是大型机团队，因为没有人理解他们在做什么，他们只能独自处理事情。

如果团队结构保持原样，这家健康保险公司就不会转变为闪闪发光的全新运营模式...... 并且也能够提供客户想要的东西。

如果完成工作需要 30 项技能，那么无论组织结构如何，你的有效团队规模就是 30 人。调整组织结构，将他们每个人都放在同一个团队中，比受制于组织结构并让每个人都围着体制打转要有效得多。一旦每个人都在同一个团队中，并且工作开始流动，团队就可以考虑如何减少依赖性和复杂性，一如前面所建议的那样。

不要将团队安排在职能孤岛中，而是要让他们能够独立提供价值。这种安排可以让更多的工作同时在系统中移动，因为各项工作都不会给其他团队造成延误。

上面每一个步骤都有助于改善流动性。但如何提高质量呢？有趣的是，上面每个步骤也都提高了质量。

团队每次做的事情更少意味着认知负荷的减少，这样团队就更容易完成更高质量的工作，而减少上下文切换则让他们不太可能错过重要的事情。质量提高时，返工就会减少，最终形成围绕质量和速度的积极反馈循环。

消除依赖性意味着团队可以专注于自己需要完成的事情上。当他们等待另一支球队时，他们不必再找其他事情来填充自己的空闲时间。这将进一步减少上下文切换和认知负担，让团队更好地了解他们在做什么、为什么做以及为谁在做。

专注于保持工作进展将从系统中消除那些就是瞎忙活的任务，空出时间让人们可以用来学习、改进、增强自动化或者做其他有意义的事情，从而实现更高质量的工作、更快乐的员工、更好的士气，最后获得更好的结果。

问题的最佳解决方案是具有不同思想、知识和经验的人们组成的团体才能找到的。通过减少孤岛可以创造一个环境，让每天一起工作的人们从不同的角度看待事物。他们将更有可能预防错误、偏见和不正确的假设，因为他们将拥有更全面的视角。此外，向其他团队移交的工作将会减少，这意味着信息或知识丢失的机会也会减少。质量将因此而提高。

只要对公司思考和处理工作的方式做一些简单改变，就能实现更高的质量、更好的流程。这些改变需要付出时间和精力，但这样的代价是值得的。工作会顺利推进，质量会提高，客户会得到他们想要的成果，收入会提高，士气会更高。这是一项长期投资，会带来巨大的回报，并且随着积极的反馈循环不断增强，未来它还会继续带来回报。越早开始改变，组织就能越早实现效益。

采用上述四个步骤将改变你的组织。少做事意味着你可以更加关注自己正在做的事情。消除依赖性使团队能够灵活地响应客户的需求。推动工作前进可确保尽快交付价值。消除孤岛可确保团队在工作中能够协作且高效。总而言之，它们会让你感觉像是在一家完全不同的公司——一家以你无法想象的速度生产优质产品的公司工作。

 作者介绍

Noah Cantor 是一位经验丰富的技术领导力教练、技术领导者和人员领导者。他与很多技术领导者合作过，这些领导者面临着员工积极性低落、团队难以交付成果以及巨额技术债务的问题。Noah 帮助他们解决不知所措、压力重重和力不从心的困境。他使组织成为更令人惊叹的工作场所，减少员工流动和缺勤，为领导者腾出时间来制定战略，并帮助他们清晰、真实和有目标地展现能力。

参考

使用团队拓扑减少敏捷 DevOps 团队的认知负荷  (https://www.infoq.com/articles/reduce-cognitive-load-devops-teams/)

原文链接：

Four Steps to Achieving Operational Flow and Improving Quality in Tech Teams (https://www.infoq.com/articles/achieve-flow-improve-quality/)