软件开发人员不应针对利用率进行优化。改为这样做。
软件开发人员不应针对利用率进行优化。改为这样做。
挑战您的基线假设，以便您有意识地针对正确的事情进行优化。
我注意到，当留给自己的设备时，人们倾向于优化利用率。
Photo by Brett Jordan: https://www.pexels.com/photo/wood-connection-technology-computer-5651559/
优化利用率感觉很有效。
这就是它的样子。您正在执行一项任务，但不知何故遇到了需要一些时间才能解决的障碍——比如说半天。因此，当有人为您消除障碍时，您将继续执行不同的任务。
从表面上看，这似乎不是问题。毕竟，您不想浪费时间和您的前进工作。有几种方法可以解决这个问题。
无论您采用哪种方法，都要挑战您的基线假设，以便您有意识地针对正确的事情进行优化。
一种方法是您的第二个任务需要很长时间才能完成。说两天吧。因此，即使在第一个任务被解除阻塞并且您可以返回它之后，它也会在您完成任务二时处于空闲状态。
另一种选择可能是停止任务二，返回任务一并完成它，然后返回任务二。从完成任务一的角度来看这很好，但现在任务二将花费比预期更长的时间。
有时您可能会在任务一和任务二之间来回切换，从而增加两个任务的运行时间。两项任务彼此越不相关，每次执行任务时产生的间接费用就越多 上下文切换 .
在平均工作日内，一天中切换上下文超过 2 或 3 次可能会破坏当天的所有生产力！
这种切换失败的另一种方式是任务二也可能被阻塞。所以现在你有两个任务，在继续之前你正在等待一些外部解决方案。像任何好人一样，你不想浪费时间，所以你接了第三个任务。
现在我们刚才描述的问题都被放大了。对于你接手并开始处理的每一项额外任务，问题都会成倍增加。每个额外的任务都会增加更多的时间！
如果您在团队中工作，则会出现一个额外的问题。您可能会排空积压工作。现在，当团队成员正在寻找下一个任务时，无事可做。当您同时处理三项任务（并且没有完成任何任务）时，您的队友无事可做。
当您优化效率时会发生这种情况！你的队友饿死了，你狼吞虎咽，什么也做不了。相当有效率！？！？！
大多数人不知道或不承认他们正在优化效率。感觉就像你是一个认真而细心的团队成员。意图绝对是积极的。不过，这些假设可能是隐藏的。问问你自己和你的团队“我们在优化什么？”
还有什么 可以 我们正在优化？
让我们看一个不同的模型。
让我们从头开始，你已经拿起了任务一，它被阻止了。你可以在这里做什么，而不是接受另一项任务？我想到了几个选项。
你可以让你的队友知道你有空，并要求帮助完成任何已经开始的任务。这可能包括与队友配对、执行代码审查、进行设计审查、测试应用程序。它也可能会削减某人任务的一部分，这些任务可以独立完成。
这些方法都有助于加快现有工作，而无需开始任何新工作。这就是限制 WIP 的精益概念——“进行中的工作”。但是限制听起来不像你对任何事情的优化。这是怎么回事？
挑战您的基线假设，以便您有意识地针对正确的事情进行优化。
您正在限制正在进行的工作，以最大限度地提高现有任务的完成速度。我们对一个指标施加了约束，以便我们可以影响另一个指标。我们在这里优化的是吞吐量——任务开始后完成的速度。
吞吐量是经过时间的度量。所以这不是你投入任务的时间。这是一项任务从开始到结束所花费的总时间。如果你每周工作一天，超过四个星期，你会看到一个有趣的结果。你付出的努力是 4 天，但经过的时间是 7 倍——4 周！对于这项任务， 周期 是28天！
如果您能够直接完成该任务，那么肯定会花费不到 4 天的时间，因为上下文切换会更少。不要误以为没有成本。
软件开发领域的上下文切换成本约为 15-30 分钟。您切换的不同域越多，成本就越高。您启动的域越复杂，成本就越高。
在平均工作日内，一天中切换上下文超过 2 或 3 次可能会破坏当天的所有生产力！
现在我们有第二种方法，我们正在优化以减少周期时间并增加吞吐量。对于一个专注于交付和完成的团队——对于一个专注于成就的团队—— 这个 应该是优化的默认模型。
第一种方法将开发人员置于模型的中心。我们正在优化以充分利用开发人员。毕竟，我们为我们的开发人员付出了很多，所以我们应该优化让他们保持忙碌。 你看到了吗？ 忙碌（利用）变得比有效（完成工作！）更重要
当您优化效率时会发生这种情况！你的队友饿死了，你狼吞虎咽，什么也做不了。
第二种方法将工作置于模型的中心。对于支付开发人员的方式，我们需要采用不同的思维方式。我们付钱给他们是为了让他们把事情做好。我们正在为工作的有效性和流程投入源源不断的资金。这听起来更崇高，不是吗？
我们还能优化什么？让我告诉你我最近的一次谈话，让我们看看我们是否可以提取正在发生的事情。
谷歌试图优化什么？
伙伴 （ 不是他的真名） 最近加入 Google，担任 SRE 团队的经理。巴迪是一个有才华和有动力的人。他拥有计算机科学博士学位。他喜欢把事情做好。他以成就为动力，为他自己和他的团队。
Buddy 对我发表了关于在 Google 工作的评论。 “在谷歌的生活很奇怪……我得呆在我的车道上。”这激起了我的好奇心，所以我们安排了一些时间去聚会和聊天。
Buddy 描述了一个工程师通常有几个项目在进行中的环境。这些项目有一个方向，但没有明确的目标，也没有最后期限或时间表。经理们在那里提供帮助，成为仆人式的领导者。他们不是来指导、指导、判断或管理的。
这种模式与 Buddy 追求成就的动力背道而驰。他怎么可能 帮助 他的团队在这个模型中完成任务？
此外，管理层通过 OKR 指导团队和组织，但这些通常会在此过程中发生变化。高层也有“金票”的概念，威利旺卡的风格。这使他们能够猛扑并“加速”某些项目的优先级。
Buddy 还描述了一个似乎适合工程师的福祉和关怀的环境。谷歌在校园内提供许多服务和设施，包括所有膳食、洗衣、按摩、财务规划、健身、健康、按摩、冥想。这听起来像是一个旨在让您摆脱许多烦恼的环境，以便您可以专注于工作。
在我们的谈话中，我们陷入困境的地方是“工作”。谷歌优化的目的是什么？
这与利用率无关，因为尽管每个人都有多个项目，但这些项目没有“管理”，也没有推动集体成就。这也与吞吐量无关，因为每个人都有多个项目同时运行。
我将其描述为创造力和创新的某种融合。谷歌正在提供空间和环境，以便真正有才华的工程师能够做到最好。他们消除了很多照顾自己的压力。他们还积极消除外部力量的压力，如市场、客户、利益相关者和人为的最后期限。
什么是正确的方法？
我们的默认行为是优化感知效率。我们通过使自己超负荷使用来做到这一点。这导致回报缓慢。
另一种方法针对正在完成的工作进行优化。限制进行中的工作可以增加流量。结果是源源不断的工作。
Google 针对开发者体验进行了优化。他们已经建立了一个环境，以最大限度地发挥创造力和创新的机会。
无论您采用哪种方法，都要挑战您的基线假设，以便您有意识地针对正确的事情进行优化。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
