После поста про Канбан получил хороший комментарий.

Смысл был в следующем: сама доска может показать, что задача остановилась, но если следующий участник процесса узнает об этом только на планёрке через два дня — проблема уже не в доске.

Согласен.

И здесь, на мой взгляд, начинается главное отличие визуального управления от управления результатом.

В строительстве задача редко существует сама по себе.

Один участник завершил свою работу → результат должен получить следующий → он должен выполнить свой этап → передать дальше.

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

Поэтому для меня Канбан — это не просто:

«Сделать → Делаю → Готово».

В рабочем варианте я бы смотрел ещё на четыре вещи:

— где сейчас находится задача; — что блокирует её движение; — кто отвечает за следующий шаг; — сколько времени задача находится в ожидании.

Именно последний пункт часто недооценивают.

Мы привыкли считать, сколько дней выполнялась работа.

Но иногда гораздо важнее понять, сколько дней результат просто ждал следующего действия.

Например:

подрядчик выполнил этап → результат необходимо согласовать → согласование не состоялось → следующий участник не может начать работу.

Формально никто не «простаивает».

Но проект теряет два-три дня.

А если таких передач десятки — потеря превращается уже в недели.

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

Канбан здесь полезен именно как инструмент диагностики:

он не устраняет узкое место — он делает его видимым.

А дальше уже задача руководителя — найти причину, назначить ответственного, определить срок реакции и убрать блокировку.

В строительстве часто теряются не дни работы. Теряются дни ожидания между работами.

Именно это я считаю одним из важных элементов управления сроками.