问题描述
在《凤凰项目》一书中，提到一个图表显示，当一个人的工作负荷逐渐升高至90%以上时，他们的等待时间会成倍增加。书中甚至声称：
等待时间 = （繁忙百分比 / 空闲百分比）
因此，如果一个资源每周工作40小时，其中有35小时处于繁忙状态，则：
等待时间 = 0.875 / 0.125 = 8
然而，如果一个资源每周工作40小时，其中有39小时处于繁忙状态，则：
等待时间 = 0.975 / 0.025 = 39
这个等待时间会随着工作流中等待次数的增加而相乘。显然，我们希望密切关注这个问题！因此，鉴于这一重要公式，书中提供了很少关于如何测量这些值的实际建议。我的问题是，如何实际测量一个人的繁忙百分比？
解决方案
请注意以下操作可能因版本差异或特定情况而有所不同，务必在实施前做好备份。
通过产量会计测量
实际上，测量员工的繁忙百分比是行之不通的做法。通过测量和提高员工整体的利用率，可能会在系统中产生问题，降低整体产出。
更重要的是，应该使用“产量、库存和运营费用”来进行测量，同时努力减少库存和运营费用，同时最大程度地提高产出。这种方法被称为“产量会计”。
在软件开发领域，库存指的是尚未为客户带来效益的正在进行的工作。任何已经完成但尚未发布的工作都被视为库存。而产量是为客户带来效益的工作量。对于与客户无关的工作，将其视为运营费用。
简单系统 vs 复杂系统
在一个简单的系统中，当一个人或多个人独立工作且使用的设备也相对独立时，每个人的利用率增加会直接提高整个系统的产出。这就是基于此问题的常见误解，即提高人员利用率会导致所有系统产出的增加。但是，仍然需要测量系统的产出、库存和运营费用。
然而，在一个复杂的系统中，即使只有两个依赖关系，一个部分的利用率增加也可能直接导致瓶颈部分的利用率降低，从而降低整个系统的产出。在瓶颈以外的任何生产率提高都是一种幻觉。
例如，一个软件工程师团队的代码必须经过软件架构师的审核，后者还要为新功能制定计划。这个人是瓶颈，没有经过架构师审核的代码只会增加库存；如果架构师没有时间，就不会制定新功能的适当计划。如果开始测量软件工程师的利用率，他们每个人都会尽量增加修改的次数，而不是改进修改。架构师需要花在每个修改上的时间将增加，审核所需的总时间还会进一步增加，从而导致没有时间制定新变更计划。最终，整个系统将停滞不前。相反，如果降低利用率，甚至不工作，他们会在每个修改或同行评审上花费更多时间，这可能会导致审核所需的时间减少，最终产生产出增加。这仅仅是一个具有两个依赖关系的团队示例。工程师依赖于架构师制定新变更计划和审核变更。
清楚地说，最好的方法是妥善管理瓶颈，努力在瓶颈处获得生产力，其中“节省的时间”实际上就是整个系统的产出。
这才是《凤凰项目》的真正信息，直接来源于Eliyahu M. Goldratt的《约束理论》。您还可以阅读一篇关于“利用率思维与产量思维”的文章。我还建议阅读有关“关键链过程管理”的更多文章。
记住：你测量什么，你就会得到什么。你绝对不希望获得的是提高个人利用率。善意铺成的地狱之路。