TL; DR : это неправильно измерять. Измеряя и увеличивая коэффициент использования сотрудников по всем направлениям, вы создаете проблемы в системе и снижаете общую пропускную способность .
Учет пропускной способности
То, что вы на самом деле хотите измерить, - это пропускная способность, товарно-материальные запасы и эксплуатационные расходы, все вместе, и попытайтесь сократить запасы и снизить эксплуатационные расходы, одновременно увеличивая пропускную способность. Этот метод известен как учет пропускной способности .
В разработке программного обеспечения инвентаризация - это незавершенная работа, которая пока не приносит пользы клиенту. Все, что было сделано, но не выпущено. Пропускная способность - это объем работы, полезный для выпускаемого клиента. Любая выполненная работа, которая не является непосредственно полезной для клиента, учитывается как операционные расходы.
Простая система
В простой системе с одним человеком или несколькими людьми, работающими независимо с независимым оборудованием, столько, сколько каждое из них, напрямую увеличивает пропускную способность всей системы . Это приводит к распространенному заблуждению, которое является основанием для этого вопроса, что увеличение использования человеком приведет к увеличению пропускной способности во всех системах. Но вы все равно измеряете пропускную способность системы, инвентарь и эксплуатационные расходы .
Сложная система
В сложной системе, даже с двумя зависимостями, увеличение использования одной части системы может напрямую привести к уменьшению использования в узком месте, что снижает пропускную способность всей системы. Любое увеличение производительности за пределами узкого места - мираж .
Пример:Команда разработчиков программного обеспечения имеет весь код, проверенный архитектором программного обеспечения, который также планирует новые функции. Этот человек является узким местом, код, не рассмотренный архитектором, просто увеличит инвентарь, если у архитектора не будет времени, никакие новые функции не будут должным образом спланированы. Если вы начнете измерять использование программных инженеров, каждый из них попытается внести больше изменений, чем улучшений. Время, которое архитектор должен будет потратить на каждое изменение, будет увеличиваться, а общее время, затрачиваемое на проверку, будет дополнительно увеличиваться за счет увеличения количества изменений до такой степени, что не останется времени для планирования новых изменений. В конце концов вся система останавливается. Если, с другой стороны, они уменьшают использование, даже проводят время на холостом ходу, они тратят больше времени на каждое изменение или экспертные оценки, это может привести к сокращению времени, необходимого для проверки, и в конечном итоге к увеличению пропускной способности. Это всего лишь одна команда с двумя зависимостями. Инженеры зависят от архитектора для новых изменений, которые будут запланированы и для изменений, которые будут рассмотрены.
Очевидно, что преимущества должны быть получены в правильном управлении узким местом, и попытка повысить производительность в узком месте , где полученный час , является пропускной способностью всей системы .
Это реальное послание Проекта Феникс и пришло непосредственно из Теории Ограничений Элиягу М. Голдратта. Вы также можете прочитать статью об использовании мышления против мышления пропускной способности . Я также предложил бы прочитать больше на Критическом Цепном Управлении процессом .
Помните: что вы измеряете, то и получаете . И вы определенно НЕ ХОТИТЕ увеличить индивидуальное использование. Дорога в ад вымощена благими намерениями.