В этой книге тот же преподаватель программы MBA, что и в книге "Критическая цепь", но уже более опытный, ведет группу по управлению проектами по теории ограничений. Слушатели разных отраслей задают вопросы: строительной, разработки банковских приложений, R&D… И параллельно второй герой внедряет решения в своем бизнесе.
В проектах ограничением является время. Чем быстрее проект завершим, тем быстрее начнем на нем зарабатывать. Но проектов хочется сделать много и многозадачность людей от этого зашкаливает. Есть иллюзия, что если по чуть-чуть работать над каждым проектом параллельно и давать немного прогресса каждому проекту, то так мы приблизим их завершение. Но это иллюзия. Потому что:
- погрузился в один проект, немного поработал,
– переключился на другую задачу, погрузился в нее, удивился всему, что сделал по ней раньше, начал переделывать,
– переключился на третий проект, погрузился,
- а... нет, не погрузился, оторвался на срочный вопрос,
- опять вернулся к третьему проекту, вот сейчас погрузился, понял, что информации не хватает,
– ушел на обед /в отпуск /на больничный…
Какой прогресс на самом деле?
В книге есть решения, что делать. Некоторые говорят, что они шокирующие. Например, такая рекомендация:
вы начинаете задачу – вы завершаете задачу и только после этого беретесь за следующую. Не страшно звучит? Тогда такая:
мы замораживаем часть проектов, за счет этого ускоряем более приоритетные и только после завершения проекта беремся за следующий из списка замороженных (хотя часть замороженных, возможно, уже давно пора совсем удалить из списка).
В книге описаны и другие рекомендации: дозирование, полный набор и как его добиться, триаж и другое. Есть и про планирование и мониторинг проектов по критической цепи с применением диагонального буфера.
Про критическую цепь и буферы писала тут. Но просто внедрить эти алгоритмы планирования недостаточно для результата. В книге верно написано: