等待时间=（忙碌百分比/空闲百分比）
因此，如果资源每周40个小时中的35个小时处于繁忙状态，则：
Wait Time = 0.875/0.125 = 8
但是，如果每周40小时中有39个资源繁忙，那么：
Wait Time = 0.975/0.025 = 39
>这乘以工作流程中的等待次数。显然，这是我们要关注的事情！
因此，鉴于所有这些，将人们的利用率保持在合理水平上显然至关重要。鉴于本书坚持该公式的重要性，因此它几乎没有提供有关如何测量这些值的实用建议。我的问题是，您如何实际衡量一个人的忙碌百分比？
#1 楼
TL; DR：这是错误的衡量。通过全面衡量和提高员工的利用率，您会在系统中造成问题并降低总体吞吐量。吞吐量核算
您实际要衡量的是吞吐量，库存以及运营费用，并试图减少库存并减少运营费用，同时最大程度地提高吞吐量。此方法称为吞吐量核算。
在软件开发中，库存是在进行中的工作，尚未为客户带来利益。已完成但未发布的所有内容。吞吐量是对发布的客户有用的工作量。任何对客户没有直接意义的工作都记作运营费用。
简单系统
在一个由单个人或多人组成的简单系统中，他们独立工作并使用独立设备与每个人所做的一样多，将直接增加整个系统的吞吐量。这导致了普遍的误解，这是此问题的基础，即提高人员利用率将导致所有系统的吞吐量增加。但是，您仍然需要衡量系统的吞吐量，库存和运营费用。
复杂的系统
在复杂的系统中，即使只有两个依赖项，也可以提高一个系统的利用率系统的一部分会直接导致瓶颈利用率的降低，从而降低整个系统的吞吐量。瓶颈之外的任何生产率提高都是海市rage楼。
示例：软件工程师团队的所有代码均已由软件架构师审核，该架构师还制定了新功能的计划。这个人是一个瓶颈，未经架构师审查的代码只会增加库存，如果架构师没有时间，则不会适当规划任何新功能。如果您开始衡量软件工程师的利用率，他们将各自尝试进行更多的更改，而不是进行更好的更改。架构师在每次更改上需要花费的时间将增加，并且由于更改数量的增加，审核所花费的总时间将进一步增加，以至于没有时间计划新的更改。最终，整个系统陷入停顿。另一方面，如果它们降低了利用率，甚至闲置了时间，则他们在每次更改或同级审阅上花费的时间更长，这可能导致审阅所需的时间减少并最终提高吞吐量。这只是一个有2个依赖项的团队。工程师要依靠建筑师来计划新的变更并进行审查。
显然，在适当地管理瓶颈并试图在瓶颈处提高生产率（在所获得的小时数中，是整个系统的小时吞吐量。
这是Phoenix项目的真实信息，直接来自Eliyahu M. Goldratt的约束理论。您可能还会阅读有关利用率思考与吞吐量思考的文章。我还建议您阅读有关关键链流程管理的更多信息。
记住：您所衡量的就是所得到的。而且，您绝对不希望提高个人使用率。通往地狱的道路是善意铺就的。
评论
通过阅读此答案和链接文章，我绝对学到了一些东西！不过，我仍然想知道如何实际衡量软件开发团队的吞吐量。
– Craig
20-10-17在8:47
评论
这值得引用书Slack amazon.com/dp/0767907698的答案。通过将资源消耗为100％来实现效率的神话也是“约束理论”的主要主题。在我有时间写一个完整的答案之前，我只想补充一点，在ToC中，您放弃了所有地方的效率，只关注约束方面的效率。因为这样可以使其他所有地方吸收多样性并避免造成浪费（在这里引用精益，例如生产过剩，库存过多等），因为这是非增值活动（再次引用精益）。
约束很少是人类，即使在《凤凰计划》中，布雷特也首先是一个约束-但它的“他的工作”才是真正的约束。
@Evgeny期待完整的答案！
这里的答案还应该使用马丁·福勒（Martin Fowler）的“您无法衡量生产率”-martinfowler.com/bliki/CannotMeasureProductivity.html