软件开发人员不应针对利用率进行优化。改为这样做。
挑战您的基线假设，以便您有意识地针对正确的事情进行优化。
我注意到，当留给自己的设备时，人们倾向于优化利用率。
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。