Kanban в строительстве: как увидеть, где на самом деле
Kanban в строительстве: как увидеть, где на самом деле остановился проект
Под предыдущим постом мне написали интересную практическую мысль:
дорожную карту можно вести в Kanban-доске, добавив исполнителей и статусы задач.
И я решил подробнее разобрать этот инструмент.
В строительстве часто бывает ситуация:
проектировщик работает, подрядчик работает, заказчик работает, ресурсники работают.
А проект при этом не движется.
Почему?
Потому что одна задача ждёт другую.
Например:
проектировщик ждёт исходные данные;
подрядчик ждёт проектное решение;
ресурсоснабжающая организация ждёт документы;
заказчик ждёт согласование.
Каждый занят своей работой.
Но одна незакрытая задача блокирует следующую.
Именно такие зависимости Kanban помогает увидеть.
В самом простом варианте доска может выглядеть так:
ПЛАН → В РАБОТЕ → НА ПРОВЕРКЕ → ЗАБЛОКИРОВАНО → ВЫПОЛНЕНО
На карточке — конкретная задача, ответственный и срок.
Например:
— получить ТУ; — выпустить проектные решения; — согласовать проект; — выполнить СМР; — получить заключение; — подключить объект к сетям.
По мере выполнения задачи перемещаются по доске.
И здесь появляется ещё один важный принцип — не держать слишком много задач одновременно в работе.
Если команда получила десять задач и все десять находятся в статусе «В работе», это ещё не означает высокую производительность.
Возможно, команда просто перегружена.
Часть задач зависает, появляются очереди, сроки начинают сдвигаться.
Поэтому Kanban помогает руководителю видеть не только что сделано, но и:
— где образовалась очередь; — где появился блокер; — кто от кого зависит; — какая задача тормозит следующий этап; — где команда перегружена.
Для меня в этом и заключается основная ценность инструмента.
Не заставлять людей работать быстрее, а увидеть, почему работа перестала двигаться.
При этом Kanban не заменяет дорожную карту.
Дорожная карта показывает путь проекта. Kanban показывает текущее состояние задач на этом пути.
А дальше возникает следующий вопрос:
Какие из этих задач действительно определяют конечный срок проекта?
Это уже следующий инструмент — критический путь.
Моя главная мысль:
Визуальная доска не решает проблемы проекта. Она показывает, где они находятся.
А задача руководителя — эти проблемы снять.
· 05.09
На доске очень упрщенное понимание строительного процесса и проектирования либо это для объектов уровня ларек. ТУ не получено, а сметы на проверке и т.п. разделами на экспертизу не ходят. Вы планируете что то сами для себя, а нормативное требование говорит другое. И ключевой момент - ни один руководитель, эти проблемы не снимет в процессе. Только на уровне планирования инвестпроекта, в реализации уже поздно
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 06.09
Согласен, реальный процесс проектирования и строительства значительно сложнее приведённой в посте схемы. В примере я действительно упростил последовательность, чтобы показать сам принцип Kanban визуализацию текущих задач, зависимостей и блокировок.
При этом я бы разделял уровни управления. На этапе планирования ключевые ограничения действительно нужно выявлять и снимать заранее. Но в реализации новые ограничения всё равно возникают, и их также необходимо оперативно видеть и устранять.
Поэтому Kanban для меня не заменяет календарное планирование, проектирование или нормативные процедуры. Это инструмент оперативного управления текущим потоком работ.
А доска сама проблему не решает она помогает руководителю увидеть, где возникло ограничение и что сейчас мешает проекту двигаться дальше.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 06.09
Если развернуть под 30 градусов и сделать плоскость службы заказчика, плоскость генпроектировщика, плоскость поставщика освновного оборудования, генподрядчика, пусконадочных работ и т.д. И на ней сходу отметить краеугольные камни/этапы которые стопорятся процесс, например весь комплект ТУ, общественные слушания, экологическая экспертиза, строй экспертиза, закупка основного оборудования, поставка конструкторской документации и т.п. - т.е. этапов которые выполняются кем то, а влияют на многих. То дашборд будет поживее, и руководство будет видеть эти моменты. Но эту панели в проекции не будут двигаться, только если виксировать прохождение. Это как мысль
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 07.09
Интересная мысль. Особенно в части выделения узловых этапов, которые выполняются одним участником, но влияют сразу на нескольких.
В управлении объектами я стараюсь смотреть не только на отдельные задачи, а на такие зависимости и их влияние на общий результат. Если это правильно визуализировать, руководитель действительно сразу видит, где находится ограничение и что оно за собой тянет.
Спасибо, хороший вариант развития этой идеи.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён