«Всё хорошо, но нужно переделать»: как работать в проектировании без горящих дедлайнов и бесконечных правок
«Клиент всегда прав», — когда-то думала я. Казалось нормой работать 24/7, чтобы успеть сдать проект в сжатые сроки, которые установил заказчик. Ведь он прав. Теперь наше конструкторское бюро работает по-своему, еще и чек за это повышает кратно. И знаете что? Клиенты в восторге и постоянно к нам возвращаются.
Привет, меня зовут Мария Болдырева, я CEO в проектном бюро WildTeam. В своем блоге я рассказываю, как устроены процессы в компании — мы проектируем здания и делаем это по Agile.
Выстраивать процессы — это еще не всё. Нужно сделать так, чтобы они работали не в вакууме, а на реальных проектах и с заказчиками, которые не всегда знают про Agile. Для этого мы придумали целую систему взаимодействия с клиентом, чтобы и ему, и нам было комфортно. Никаких больше горящих дедлайнов и криков начальника «Срочно надо всё переделать!» в пятницу вечером.
Рассказываю, в чем наш секрет: как успеваем сделать всё в срок, адекватно относимся к правкам и еще остаемся в хороших отношениях с заказчиками.
Определяемся, готовы ли браться за проект
До заключения договора мы выясняем, чего хочет заказчик. Не выпытываем сразу все технические требования, скорее определяем, насколько хорошо он понимает свою задачу. И здесь есть три варианта событий.
Нам важно знать заранее, насколько клиент понимает, что ему нужно. Если он еще не определился с будущим зданием, у проекта будет сложный жизненный путь. Заказчик станет вносить миллион изменений во время работы. И это окей — мы всё-таки работаем по гибкой методологии и правок не боимся.
Неопределенность клиента мы закладываем в стоимость проекта и считаем, что это справедливо. Само по себе «незнание» — это нестрашно. Мы поможем разобраться, определить требования и сформулировать все хотелки, но потратим на это свое время и ресурсы.
Мы считаем рабочие часы по каждому проекту. Ниже две схемы — на левой проджект-менеджер уделил заказчику почти в 2 раза больше времени. Значит, клиент вносил много корректировок. В следующее здание для этого же заказчика мы заложим часы работы проджект-менеджера. Зато на правой эталонное разделение — такое стараемся делать в каждом проекте.
У нашей компании есть список «красных флагов». Если заказчик делает так, мы с ним работать не будем:
🚩 Необоснованно режет цену.
🚩 Жалуется на всех проектировщиков, рассказывает, как подал на них в суд, и говорит: «Надеюсь, вы нормальные».
🚩 Не очень чистоплотно относится к документам и уже на первых встречах заявляет, что мы будем вместе где-то нарушать нормы или законодательство.
🚩 Выступает как звено из субподрядов и субконтрактов.
🚩 Грубо общается со своими сотрудниками.
Следующий шаг — определить сроки выполнения проекта. Раньше мы на эту вещь не сильно акцентировали внимание, и любые сроки заказчика для нас были приемлемыми.
Мы всегда предупреждаем, если заказчик сильно преуменьшил время выполнения проекта, и говорим это еще до договора. Обычно определяем срок по уже готовым объектам. Например, к нам пришли за дата-центром. До этого у нас на него уходило 8 месяцев — этот срок называем заказчику.
Если его всё устраивает, движемся дальше. А если нет, объясняем, что и когда сможем реализовать, что выдадим раньше и как подстроимся под его потребности. Но общий срок всё еще будет длиннее, чем он планировал.
Формируем команду и месяц выясняем все требования заказчика
Выбор команды — важный этап. Нужно подобрать людей так, чтобы они сработались, были достаточно скиловыми и замотивированными. Мы действуем по-разному. Проводим опросы команды и выясняем, кому проект интересен. Иногда волевым методом назначаем инженера, который заканчивает один проект и уже готов взять другой в работу.
Первые несколько встреч с заказчиком и его командой обсуждаем, а что они вообще хотят. Причем нас интересуют не цифры или формулировки из техзадания, а простые предложения вроде «хочу газон от шлагбаума до двери и сад на крыше».
Если заказчик продвинутый, он сам назначает такие встречи — кик-оффы, где команда подробно рассказывает обо всем. Мы всегда помогаем клиенту и задаем миллион вопросов:
🗨 Зачем мы что-то проектируем?
🗨 Когда хотят построить здание?
🗨 Какие у него будут функции?
🗨 Какие есть боли у заказчика или неудачный опыт прошлых проектов?
🗨 Что в предыдущих проектах было хорошо или плохо?
🗨 Что им в целом хочется от процесса проектирования?
🗨 Что они хотят конкретно от нас и взаимодействия с нами?
🗨 Какие есть технические особенности в их стиле проектирования и стройки?
Все вопросы мы задаем не руководителю, а команде, с которой будем работать. И делаем это так: электрики идут к электрикам, конструкторы — к конструкторам и так далее.
На всё про всё обычно уходит месяц. За это время мы даже не начинаем проектировать, а только собираем технические требования к зданию.
Параллельно носим заказчику эскизные наработки. Готовим планировки, скетчи и показываем их на каждой встрече. Это еще сырой материал, цель которого — узнать, что нравится клиенту.
Выяснение требований и эскизирование продолжаются почти весь жизненный цикл проекта. Чем детальнее мы разрабатываем проект, тем больше вариантов одного решения возникает.
На глубоких стадиях проработки еще включаются генподрядчики, строители, с которыми мы тоже обязательно советуемся. Например, спрашиваем, какая у них есть техника и как они планируют вести строительство.
Встречаемся с командой заказчика каждую неделю, пока работаем над проектом
Так как мы работаем по Agile, взаимодействие с клиентом немного отличается от того, как принято в конструкторских бюро. У других заказчик дает ТЗ, конструкторы что-то долго и кропотливо чертят, потом показывают и получают миллион правок. А у нас устроено по-другому.
✅ Встречи раз в неделю. В Agile есть спринты — это двухнедельный период, за который нужно выполнить определенный пул задач. Мы всегда составляем его вместе с заказчиком, чтобы он знал, над чем мы работаем. Как итог спринта — встреча для обсуждения результатов и решений.
Мы приучили клиентов, что на созвоны ходим всей гурьбой: берем с собой даже младших инженеров, которые спроектировали одну лестницу. Каждый специалист объясняет свое решение и ждет мнение клиента. Если он хочет что-то поправить, разбираемся, почему и что именно переделать, или доказываем обратное. У такого подхода несколько плюсов: все инженеры в курсе изменений, и меньше правок возникает во время проекта, потому что решения обсуждаются и согласуются сразу.
✅ Работа с документами. За всё время клиент получает более полутора тысяч чертежей. Мы оформляем их по ГОСТу только после того, как согласовали и детально обсудили конкретное решение с заказчиком. Так бюрократия занимает меньше времени, чем если бы мы оформляли чертеж по ГОСТу после каждой задачи и правки.
✅ Изменения в проекте. Проекты без правок просто невозможны. С Agile можно подходить к этому гибко и спокойно. Внести изменения несложно. Проблема только в том, сколько времени и денег потребуется и как это повлияет на ход стройки.
Гибкое отношение к изменениям по Agile — это когда вы «ртом» с заказчиком проговариваете, что менять, зачем и к чему это приведет. Мы всегда подробно объясняем, как правки повлияют на сроки, закупки, стройку и что угодно. А затем вместе решаем, насколько нужны новые требования.
К этапу сдачи проекта интенсивность работ возрастает кратно. Мы постоянно что-то защищаем, проводим ревью, показываем каждую деталь разным командам, объясняем чертежи строителям. И в какой-то момент... всё просто заканчивается. Это всегда очень пиковый процесс с мгновенной релаксацией без какого-либо финального аккорда. Мы понимаем, что проект сдан, только потому, что перестаем получать комментарии.
Правда, на этом работа с заказчиком не заканчивается. На всех объектах ведем авторский надзор. Это значит, что мы помогаем клиенту справляться с невзгодами строительства: что-то не получилось собрать, что-то не удалось купить или требуется замена оборудования или материала. Это фоновая нагрузка, и мы ее не сильно монетизируем, но считаем делом чести довести заказчика до «красной ленточки».
Что в итоге: остаемся в хороших отношениях с заказчиками и работаем над другими проектами
Часто проектные группы становятся больше, чем просто командами: они делятся опытом, находят общий язык и обсуждают не только рабочие задачи. Как-то ребята из команды заказчика пригласили меня на шашлыки, чтобы отметить завершение крупного этапа строительства. Это был теплый и неформальный вечер. И теперь у меня в планах есть задача — организовать подобную встречу инженеров с нашей стороны и заказчика.
Почти всегда клиенты зовут нас на открытие объектов. Однажды нас пригласили на торжественную церемонию как VIP-гостей с фуршетом и «красной ленточкой». В такие моменты осознаешь, что не зря проделал такую работу и потратил шесть лет на то, чтобы внедрить Agile. Можете почитать о том, как это было, в этой статье.
И не только мне всё так нравится: 100% наших клиентов остаются довольны и возвращаются с новыми проектами.
Если вам интересно поработать с заказчиками в системе Agile, подписывайтесь на наш телеграм-канал. Мы как раз набираем специалистов на новые проекты и будем рады ответить на все вопросы на собеседовании.
А какие обычно у вас отношения с заказчиками?