Это был мой первый опыт применения Agile в сфере строительства. Но как набор принципов и методик Agile себя полностью оправдал. Как оказалось, ключевые проблемы в проектировании зданий — такие же как в проектировании программного обеспечения. Не поговорили вовремя с заказчиком. Неправильно расставили приоритеты. Изменения Технического Задания на каждом шагу.
Последнее было неожиданно. В сфере IT люди свято уверены, что уж в строительстве-то ТЗ незыблемо. Как бы не так. На стадии проектирования — постоянно изменения. Проектируешь дом на 40 квартир, а заказчик потом просит сделать их площадью меньше, но 50, и ещё добавить детскую площадку, а там уже трансформаторная будка стоит. И заменить пару двухкомнатных на однокомнатные, потому что их легче продать.
Оказалось, и в строительстве надо быть гибким. Так что все те вещи, с которыми отлично работает Agile, тут есть.
Проблему изменения ТЗ и коммуникаций с заказчиком решили внедрением еженедельного демо, чтобы заказчик видел куда идёт продукт.
Тут было очень интересно определять, а что же показать заказчику каждую неделю.
Помните картинку:
Постепенно переучили конструкторв и проектировщиков с верхнего варианта на нижний, хотя и пришлось по ходу дела сломать несколько стереотипов. Впрочем, должен признать, среди проектировщиков были очень умные и современные ребята, которые весьма помогли и предложили варианты — как всё-таки каждую неделю показывать заказчику завершённый этап.
По мере внедрения Agile подцепили заодно и техническую основу в виде BIM. Они с Agile очень хорошо дружат. Это так — моим последователям на заметку.
Однако, самой сложной частью оказалась работа с менеджерами проектов и руководством. Нет, не подумайте — руководство в компании замечательное. А от middle-менеджмента я в восторге. Уровень подготовки менеджеров проектов в строительстве (по опыту общения с 4-мя командами) кажется, значительно выше, чем в аналогичной IT-компании.
Но, как оказалось, проблемы в приоритезации работ внутри каждого проекта лежат гораздо выше — на уровне приоритезации портфеля проектов. То есть компания берёт очень много проектов и старается их всех выполнять «параллельно». Якобы «для ускорения». В итоге получатся жонглирование 10-ю проектами одновременно. Ребята стараются, но физически это невозможно. Да и в итоге каждый проект таким образом задерживается. Простая иллюстрация на тему:
Здесь видно, что когда одна команда пытается делать «параллельно» проекты A, B и C, постоянно переключаясь между ними, каждый проект в итоге заканчивается позже, чем если бы она делала их, не переключаясь межу ними.
Разумеется, тут сразу много возражений, и во главе: «а если команде пока нечего делать и она ждёт заказчика?». Почему бы тогда не заняться другим проектом?
Ответу «почему это плохой вариант» я и посвятил несколько сессий при работе как с руководством, так и с менеджерами. Поняли, что надо устранять ожидания, а не занимать команду другими проектами. Но не только поняли — а придумали КАК именно устранять их даже в на первый взгляд «невозможных случаях». Чем заняться команде если проект ушёл на 30 дней на экспертизу? Оказалось, есть прекрасный ответ и на этот вопрос.
После подобных сессий с руководством и менеджерами пришли к новой системе учёта времени сотрудников и расстановки приоритетов. Потребовалось даже выступление руководства перед сотрудниками, чтобы убедить сотрудников в том, что компания поменяла систему учёта времени, и целью работы теперь является не «экономия человеко-часов по каждому проекту», а «выполнение задач в срок или раньше».
В итоге начинали с одного пилотного проекта, но потом заказали внедрение Agile и во втором проекте. Сейчас Agile стал официальной идеологией разработки этой компании.
А на моём сайте появился отзыв от заказчика — Gravion Group :)
