«Всё хорошо, но нужно переделать»: как работать в проектировании без горящих дедлайнов и бесконечных правок

«Клиент всегда прав», — когда-то думала я. Казалось нормой работать 24/7, чтобы успеть сдать проект в сжатые сроки, которые установил заказчик. Ведь он прав. Теперь наше конструкторское бюро работает по-своему, еще и чек за это повышает кратно. И знаете что? Клиенты в восторге и постоянно к нам возвращаются.

Привет, меня зовут Мария Болдырева, я CEO в проектном бюро WildTeam. В своем блоге я рассказываю, как устроены процессы в компании — мы проектируем здания и делаем это по Agile.

Выстраивать процессы — это еще не всё. Нужно сделать так, чтобы они работали не в вакууме, а на реальных проектах и с заказчиками, которые не всегда знают про Agile. Для этого мы придумали целую систему взаимодействия с клиентом, чтобы и ему, и нам было комфортно. Никаких больше горящих дедлайнов и криков начальника «Срочно надо всё переделать!» в пятницу вечером.

Рассказываю, в чем наш секрет: как успеваем сделать всё в срок, адекватно относимся к правкам и еще остаемся в хороших отношениях с заказчиками.

До заключения договора мы выясняем, чего хочет заказчик. Не выпытываем сразу все технические требования, скорее определяем, насколько хорошо он понимает свою задачу. И здесь есть три варианта событий.

Нам важно знать заранее, насколько клиент понимает, что ему нужно. Если он еще не определился с будущим зданием, у проекта будет сложный жизненный путь. Заказчик станет вносить миллион изменений во время работы. И это окей — мы всё-таки работаем по гибкой методологии и правок не боимся.

Неопределенность клиента мы закладываем в стоимость проекта и считаем, что это справедливо. Само по себе «незнание» — это нестрашно. Мы поможем разобраться, определить требования и сформулировать все хотелки, но потратим на это свое время и ресурсы.

Мы считаем рабочие часы по каждому проекту. Ниже две схемы — на левой проджект-менеджер уделил заказчику почти в 2 раза больше времени. Значит, клиент вносил много корректировок. В следующее здание для этого же заказчика мы заложим часы работы проджект-менеджера. Зато на правой эталонное разделение — такое стараемся делать в каждом проекте.

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

Мы всегда предупреждаем, если заказчик сильно преуменьшил время выполнения проекта, и говорим это еще до договора. Обычно определяем срок по уже готовым объектам. Например, к нам пришли за дата-центром. До этого у нас на него уходило 8 месяцев — этот срок называем заказчику.

Если его всё устраивает, движемся дальше. А если нет, объясняем, что и когда сможем реализовать, что выдадим раньше и как подстроимся под его потребности. Но общий срок всё еще будет длиннее, чем он планировал.

Выбор команды — важный этап. Нужно подобрать людей так, чтобы они сработались, были достаточно скиловыми и замотивированными. Мы действуем по-разному. Проводим опросы команды и выясняем, кому проект интересен. Иногда волевым методом назначаем инженера, который заканчивает один проект и уже готов взять другой в работу.

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

Все вопросы мы задаем не руководителю, а команде, с которой будем работать. И делаем это так: электрики идут к электрикам, конструкторы — к конструкторам и так далее.

На всё про всё обычно уходит месяц. За это время мы даже не начинаем проектировать, а только собираем технические требования к зданию.

Параллельно носим заказчику эскизные наработки. Готовим планировки, скетчи и показываем их на каждой встрече. Это еще сырой материал, цель которого — узнать, что нравится клиенту.

Так как мы работаем по Agile, взаимодействие с клиентом немного отличается от того, как принято в конструкторских бюро. У других заказчик дает ТЗ, конструкторы что-то долго и кропотливо чертят, потом показывают и получают миллион правок. А у нас устроено по-другому.

✅ Встречи раз в неделю. В Agile есть спринты — это двухнедельный период, за который нужно выполнить определенный пул задач. Мы всегда составляем его вместе с заказчиком, чтобы он знал, над чем мы работаем. Как итог спринта — встреча для обсуждения результатов и решений.

Мы приучили клиентов, что на созвоны ходим всей гурьбой: берем с собой даже младших инженеров, которые спроектировали одну лестницу. Каждый специалист объясняет свое решение и ждет мнение клиента. Если он хочет что-то поправить, разбираемся, почему и что именно переделать, или доказываем обратное. У такого подхода несколько плюсов: все инженеры в курсе изменений, и меньше правок возникает во время проекта, потому что решения обсуждаются и согласуются сразу.

✅ Работа с документами. За всё время клиент получает более полутора тысяч чертежей. Мы оформляем их по ГОСТу только после того, как согласовали и детально обсудили конкретное решение с заказчиком. Так бюрократия занимает меньше времени, чем если бы мы оформляли чертеж по ГОСТу после каждой задачи и правки.

✅ Изменения в проекте. Проекты без правок просто невозможны. С Agile можно подходить к этому гибко и спокойно. Внести изменения несложно. Проблема только в том, сколько времени и денег потребуется и как это повлияет на ход стройки.

К этапу сдачи проекта интенсивность работ возрастает кратно. Мы постоянно что-то защищаем, проводим ревью, показываем каждую деталь разным командам, объясняем чертежи строителям. И в какой-то момент... всё просто заканчивается. Это всегда очень пиковый процесс с мгновенной релаксацией без какого-либо финального аккорда. Мы понимаем, что проект сдан, только потому, что перестаем получать комментарии.

Правда, на этом работа с заказчиком не заканчивается. На всех объектах ведем авторский надзор. Это значит, что мы помогаем клиенту справляться с невзгодами строительства: что-то не получилось собрать, что-то не удалось купить или требуется замена оборудования или материала. Это фоновая нагрузка, и мы ее не сильно монетизируем, но считаем делом чести довести заказчика до «красной ленточки».

Часто проектные группы становятся больше, чем просто командами: они делятся опытом, находят общий язык и обсуждают не только рабочие задачи. Как-то ребята из команды заказчика пригласили меня на шашлыки, чтобы отметить завершение крупного этапа строительства. Это был теплый и неформальный вечер. И теперь у меня в планах есть задача — организовать подобную встречу инженеров с нашей стороны и заказчика.

Почти всегда клиенты зовут нас на открытие объектов. Однажды нас пригласили на торжественную церемонию как VIP-гостей с фуршетом и «красной ленточкой». В такие моменты осознаешь, что не зря проделал такую работу и потратил шесть лет на то, чтобы внедрить Agile. Можете почитать о том, как это было, в этой статье.

И не только мне всё так нравится: 100% наших клиентов остаются довольны и возвращаются с новыми проектами.

Если вам интересно поработать с заказчиками в системе Agile, подписывайтесь на наш телеграм-канал. Мы как раз набираем специалистов на новые проекты и будем рады ответить на все вопросы на собеседовании.

А какие обычно у вас отношения с заказчиками?