其他分享
首页 > 其他分享> > 软件开发人员不应针对利用率进行优化。改为这样做。

软件开发人员不应针对利用率进行优化。改为这样做。

作者:互联网

软件开发人员不应针对利用率进行优化。改为这样做。

挑战您的基线假设,以便您有意识地针对正确的事情进行优化。

我注意到,当留给自己的设备时,人们倾向于优化利用率。

Tiles of letters spelling LIVE WELL.

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 版权协议,转载请附上原文出处链接和本声明

本文链接:https://www.qanswer.top/23236/21510921

标签:开发人员,利用率,工作,任务,软件,团队,优化,我们
来源: https://www.cnblogs.com/amboke/p/16674008.html