团队核心成员介绍英文_利用率和非核心团队成员

团队核心成员介绍英文

“但是我们在团队之外有专家，我们必须乞求……借钱……偷别人……我们在想要他们时永远无法得到他们，我们必须等待，我们无法得到足够的他们。”

我一遍又一遍地听到关于有献身精神，稳定，一致的团队的信服并不重要。 没人听我说话吗？ 没人读Xanpan或Continuous Digital吗？

我不知道： 本周花了多少管理时间来争论谁（哪些人）在做什么？

那不是零散的资源微观管理吗？

还是只是为“经理”做工作？

没有比争论谁在做什么更好地利用管理时间了？ 如果这样或那样拉扯，相关个人如何才能“站起来”并承担责任？ 当他们下周不知道自己在做什么时，他们如何才能真正“投入”工作？

尽管如此，问题还有另一个答案：“当人们需要一次处理多个工作流时，如何管理人员编制？”

通常，这是因为某些人具有专业技能，或者因为团队无法证明拥有全职的100％专职专家是合理的。

在我给您答案之前，让我们提醒自己为什么传统解决方案会使情况变得更糟：

• 当资源（人员或其他任何资源）稀缺时，将使用队列来分配稀缺资源，并且队列会产生延迟
• 队列会拖延完成工作的时间–不利于士气
• 队列是替代成本：在这种情况下，价格来自延迟成本
• 队列破坏了时间表和可预测性
• 在延误中，人们尝试做一些有用的事情，但有用的事情是较低的价值，并可能为他人带来更多的工作，甚至在专家到位后，甚至可能造成冲突

该解决方案是一种通用解决方案，可在某些稀缺资源（人，床，跑道）时使用：

拥有比必要更多的稀缺资源。

我想这听起来很明显吗？

您想要的是有足够的稀缺资源，以便不形成队列。 由于开放的gambit拥有的资源比您预期的要多25％，因此不要计划将稀缺的资源使用超过可用时间的75％。

例如，假设您有几个团队，每个团队每周需要1天的UX设计人员。 乍一看，一个设计师可以为五个团队提供服务，但是如果您这样做，仍然会有队列。

为什么？

由于可变性。

Team-1可能需要几周的时间来设计设计师，而且要确保他们在不到一周的时间内需要设计师，但是任何变化都会导致波动或“牛鞭效应”。 由变化引起的中断会随着时间的流逝而逐渐消失。

您需要在这里平衡几个因素：

• 使用率
• 变化性
• 等待时间
• 可预测性

即使需求和容量完美匹配，可变性也会增加等待时间，从而降低可预测性。 如果可变性和利用率高，那么将存在队列并且可预测性将低。

• 如果您希望100％的利用率，那么您必须接受队列（延迟）和可预测性的损失：曾经降落在希思罗机场吗？ 机场的利用率超过96％，没有能力吸收变化性，因此空中出现队列。
• 如果要通过高度可变的工作来最大程度地减少等待时间，则需要的利用率较低：为什么消防部门总是让所有这些消防车和消防员整日无所事事？

以100％的利用率运行业务，尤其是服务业务是疯狂的-除非您的客户对延迟和可预测性感到满意。

廉价航空公司始终使用相同类型的飞机，而一类座位的原因之一就是为了限制变化。 仅当他们获得经验时，他们才添加其他功能。

任何试图以100％的速度运行软件开发的人都将延迟交付，并且将无法满足结束日期。

我怎么知道

因为我对排队理论有所了解。 排队论是一种理论，就像爱因斯坦的相对论是理论一样，也就是说，它不是经过证明的理论。 在两种情况下都是数学。 如果您想了解更多信息，我建议您使用Factory Physics 。

那么，您可以利用什么呢？

好吧，这是一个复杂的问题。 有许多参数需要考虑，数学非常复杂。 实际上如此复杂，以至于数学家通常转向仿真。 您无需运行模拟，因为您可以观察现实世界，可以自己进行实验。 （看板方法使您可以看到队列的形成。）

也就是说：76％（最大）。

或更确切地说：在最简单的排队理论模型中，一旦利用率超过76％，就会开始形成队列（并且可预测性受到损害）。

鉴于您的环境可能比最简单的模型复杂得多，因此，如果要缩短交货时间和可预测性，则可能需要将利用率保持在76％以下。

作为一个非常广泛的经验法则：如果您共享某人，则不要花更多的时间在他们的四分之三上。

鉴于此，敬业的专家毕竟看起来并不那么昂贵。 回到我进来的地方。

翻译自: https://www.javacodegeeks.com/2017/09/utilisation-non-core-team-members.html

团队核心成员介绍英文