如何衡量人类利用程度？

在《凤凰计划》中，整本书中的单个图形显示，随着一个人的工作量增加到90％以上，他们的等待时间成倍增加。实际上，在书中它声称：

等待时间=（忙碌百分比/空闲百分比）

因此，如果资源每周40个小时中的35个小时处于繁忙状态，则：

Wait Time = 0.875/0.125  = 8

但是，如果每周40小时中有39个资源繁忙，则：

Wait Time = 0.975/0.025  = 39

这乘以工作流中的等待次数。显然，这是我们要关注的事情！

因此，考虑到所有这些，对我们而言，将人们的利用率保持在合理的水平上显然至关重要。鉴于本书坚持该公式的重要性，因此它几乎没有提供有关如何测量这些值的实用建议。我的问题是，您如何实际衡量一个人的忙碌百分比？

TL; DR：测量是错误的事情。通过全面衡量和提高员工的利用率，您会在系统中造成问题并降低总体吞吐量。

吞吐量会计

您实际要衡量的是吞吐量，库存和运营费用，并试图减少库存并减少运营费用，同时最大程度地提高吞吐量。这种方法称为吞吐量核算。

在软件开发中，清单是一项尚在进行中的工作，尚未为客户带来利益。已完成但未发布的所有内容。吞吐量是对释放的客户有用的工作量。所有对客户没有直接帮助的工作均记作营业费用。

系统简单

在一个单人或多人使用独立设备独立工作的简单系统中，每个人所做的工作量都将直接增加整个系统的吞吐量。这导致了常见的误解，这是此问题的基础，即提高人员利用率将导致所有系统的吞吐量增加。但是您仍然可以衡量系统的吞吐量，库存和运营费用。

复杂系统

在复杂的系统中，即使只有两个依赖关系，提高系统一部分的利用率也可以直接导致瓶颈利用率的降低，从而降低整个系统的吞吐量。瓶颈之外的任何生产率提高都是海市rage楼。

例：软件工程师团队的所有代码均已由软件架构师审核，该架构师还制定了新功能的计划。这个人是一个瓶颈，未经架构师审查的代码只会增加库存，如果架构师没有时间，则不会适当规划任何新功能。如果您开始衡量软件工程师的利用率，他们将各自尝试进行更多的更改，而不是进行更好的更改。架构师在每次更改上需要花费的时间将增加，并且随着更改量的增加，审核所花费的总时间将进一步增加，以至于没有时间计划新的更改。最终，整个系统陷入停顿。另一方面，如果他们降低了利用率，甚至闲置了时间，则他们在每次更改或同行评审上花费的时间更长，这可能会减少审核所需的时间，并最终增加吞吐量。这只是一个有2个依赖项的团队。工程师依靠建筑师来计划新的变更并检查变更。

很明显的好处是在妥善管理的瓶颈，并试图获得对来获得的瓶颈生产力，其中小时上涨，是每小时吞吐量的整个系统。

这是“凤凰计划”的真实信息，直接来自Eliyahu M. Goldratt 的“约束理论”。您可能还会阅读有关利用率思考与吞吐量思考的文章。我还建议阅读更多有关关键链流程管理的信息。

记住： 您衡量的是您得到的。而且您绝对不希望提高个人使用率。通往地狱的道路铺就了良好的意图。