Одним из первых действительно эффективных методов борьбы с ложной многозадачностью (да-да, именно так называется наша неспособность оценивать силы и риски задачи), был «метод критической цепи» Э. Голдратта («Критическая цепь»).


Уже в 1997 году Голдратт, создатель теории ограничений, понял, что для внедрения методики в жизнь, она должна быть максимально простой и понятной. User-friendly подход через 20 лет после создания теории ограничений вылился в её бизнес-версию — CCPM — Critical Chain Project Management. А так как всё новое — это хорошо забытое старое, то CCPM оказался похож и на ТОС того же Голдратта, на метод «барабан-буфер-канат» (DBR) и на метод PERT. Последний был разработан для вычисления ожидаемой продолжительности реализации проекта или времени достижения задач на определенных его этапах, и в модификациях использовался во многих организациях.

Говоря о методе критической цепи, невозможно обойти вниманием один из популярных методов сетевого планирования — PERT (Program Evaluation and Review Technique).

Впервые его использовали при создании подводной лодки Поларис в 1958 году для построения графика, включающего работы более 3300 подрядчиков. В этом проявляется специфика PERT как метода сетевого планирования для крупных проектов (в среднем, выше 300-400 операций).

По методу, длительность каждой задачи имеет пределы, которые рассчитываются согласно статистическому распределению.

Ключевой момент — для оценки времени каждой задачи используется сразу 3 значения:

1. оптимистическое (наилучшее);
2. ожидаемое (вероятное);
3. пессимистическое (наихудшее).

Они используются в формуле оценки средневзвешенного времени завершения операции (проекта):

• где tE —время операции (проекта);
• tO — оптимистическое (наилучшее) время;
• tM —ожидаемое (вероятное) время;
• tP — пессимистическое (наихудшее) время.

Как и в любых расчётах, здесь возможны ошибки. Метод PERT по своей специфике занижает предполагаемую продолжительность выполнения проектной задачи.
А значит, чем больше будет задач — тем с большим количеством ошибок вы можете столкнуться.

Проведу простую аналогию: в боевых исскусствах в активной серии ударов бессмысленно бить наотмашь. Сначала нужно блокировать соперника, затем найти 1-3 уязвимых места, и затем нанести 1 точечный удар, ненадолго затормозив его пыл.

Как это работает в проектах:

1. Блокируем косвенные моменты, которые тормозят работу: например, нелогичное стихийное поступление задач;

2. Ищем уязвимое место: например, я сильно проседаю на задачах, в которых нет четкого ТЗ;

3. Наносим один точечный удар по проблеме: я делаю простой скелет верстки без наворотов и согласовываю его с заказчиком на этапе получения задачи: так я меньше трачу времени на додумывание за клиента и быстрее получаю от него обратную связь.

WIP-лимит один из многих инструментов, используемый для фокуса команды на выполнении важных задач и обеспечения быстрого производственного потока.

Он определяет, какое количество задач может одновременно находиться на конкретной стадии — производства или повседневной жизни. При достижении лимита новые задачи не могут перейти в эту стадию, а значит сразу можно обнаружить «бутылочное горлышко» и проблемные места в процессе.