Agile по-конструкторски: как работает, зачем нужны встречи каждый день и кто отвечает за факапы

Мы попробовали «натянуть» Agile на свои строительные реалии: огромное количество чертежей, бюрократию, бесконечные согласования с клиентом, проекты по 1,5 года. И — о чудо! — у нас получилось. Сейчас эффективность выросла в два раза, а сотрудники работают с удовольствием.

Привет, меня зовут Мария Болдырева, я CEO в проектном бюро WildTeam. Шесть лет назад я решила изменить структуру работы в бюро. Раньше с заказчиком общались руководители, а младшие сотрудники получали данные обрывками. Из-за этого чертежи часто переделывали, мы срывали сроки и работали в «горящих» дедлайнах.

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

Agile — метод организации работы над проектами, где весь процесс делится на этапы, или спринты. За один спринт команда делает часть задач, согласовывает их с заказчиком и, если всё супер, работает дальше. Так подход получается более гибким: можно вносить изменения в проект на любой стадии, а ошибки исправлять сразу и не накапливать до срока сдачи.

Еще Agile — это философия и ценности. Система подсказывает, как выстроить общение «компания — сотрудник — заказчик», чтобы всем было комфортно работать.

Звучит здорово, но довольно абстрактно. На примере нашего бюро рассказываю, как всё устроено на практике.

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

🟢 Функциональные команды разбиты по профессиям: конструкторы, архитекторы, инженеры, электрики. У них есть тимлид — наставник. Он помогает специалистам разбираться с проблемами и контролировать нагрузку.

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

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

Приставки «главный» и «ведущий» никак не влияют на иерархию в команде — все равны. Это скорее пережитки прошлого, которые нам нужны по двум причинам:

🟢 Продуктовые команды состоят из специалистов разных профессий. Раньше между ними часто были конфликты: каждый выполнял свою задачу, но не думал, как она повлияет на других. Например, архитекторы придумали красивый фасад с колоннами, а конструкторы идею отвергали, потому что реализовать такое сложно и не по бюджету. Сейчас разные специалисты работают над одним продуктом вместе — в команде.

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

Руководитель проекта контролирует бюджет и работает с клиентом, главный инженер проекта отвечает за техническое соответствие и планирование хода работ. Всё остальное продуктовая команда делает самостоятельно.

Раз в две недели продуктовая команда проводит ревью: каждый объясняет свои решения коллегам. Это нужно, чтобы проверить чертежи на ошибки. Можно было бы дать все 300 схем на проверку главному инженеру, но нам его жалко. Да и это неэффективно: недочеты во время ревью заметить проще. Например, если архитектор заложит в проект под электрические шкафы небольшое помещение, электрик ему скажет, что под три шкафа комнатка должна быть шире.

Продуктовые команды несут ответственность за работу. Но мы не лишаем никого зарплаты, если сроки по проекту сорвались, и даже не ругаем. Вместо этого ищем причину и работаем над ошибками.

Обычно в айтишных командах спринт состоит из пяти этапов:

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

Продуктовая команда составляет список задач на две недели и рассказывает о своих шагах заказчику. Если у него есть что-то срочное, задания меняем. Две недели команда работает, получает результат и согласует его. Потом цикл повторяется, но задачи уже новые.

Мы много времени и внимания уделяем планированию. Для этого у нас есть разные инструменты, которые упрощают процесс.

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

2. Общее ресурсное планирование. Помогает распределять время сотрудников так, чтобы они всё успевали и не умирали от нагрузки. Тимлид с командой решают, сколько человек нужно на проект и кто под какие задачи лучше подходит.

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

3. Доска Asana. Это наша основная доска проекта, где мы фиксируем все задачи (тикеты) и цели на спринты. В Asana есть шесть основных столбцов:

Сотрудники сами перемещают тикеты в нужный столбец. Доска проекта всегда отражает актуальную информацию для менеджера и команды о том, как идет работа. Это помогает прозрачно вести диалог с заказчиком.

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

После внедрения Agile у нас значительно изменилась работа с клиентами. Расскажу, как работаем сейчас.

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

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

✅ Внесение изменений. В строительной сфере быть гибким сложнее: даже из-за изменений ширины стены на десять сантиметров придется переделывать абсолютно все чертежи. Именно поэтому мы сразу объясняем заказчику, чего будут стоить правки. Например, он хотел на следующий спринт получить проект фасада, но затем решил изменить планировку. Тогда фасад откладываем на две или больше недель и занимаемся изменениями.

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

📌 Ежедневные созвоны. Еще с ковидных времен у нас появилась традиция — каждое утро мы собираемся всем коллективом на 20–30 минут, чтобы поболтать. Мы обсуждаем всё подряд: рабочие процессы, будущее компании, последние новости, футбол, котят и даже успехи в цветоводстве. За такими беседами мы узнаем друг друга лучше и общаемся как одна команда — без должностей и иерархии.

📌 Прозрачные процессы. Мы стараемся объяснять сотрудникам, как устроена работа компании. Раз в квартал я рассказываю о делах бюро, сколько на счетах денег, какие перспективы и риски. У нас нет запретных тем.

📌 Рост в любую сторону. Есть вертикальный рост по грейдовой системе. А если кто-то не хочет брать больше ответственности за проект, можно научиться чему-то полезному и получать за это бонус к зарплате. Например, младшему архитектору необязательно становиться «главным», чтобы увеличить зарплату. Он может научиться делать визуализацию и получать за нее премии.

📌 Выезды, корпоративы, обучения. Большая часть сотрудников работает удаленно, но мы стараемся хотя бы раз в год собирать всех в одном городе. Самое приятное в таких выездах — видеть, как ребята при встрече обнимаются, хотя ни разу до этого не виделись вживую. В такие моменты мы понимаем, что всё делаем правильно.

🩷 Когда архитектор и конструктор не ругаются, а подсказывают друг другу, как будет лучше.

🩷 Когда команда сама назначает сроки, распределяет задачи и встречается с заказчиком.

🩷 Когда в компании миллион инструментов планирования, но зато сроки проектов и загрузка сотрудников прогнозируемы.

🩷 Когда на встрече с заказчиком сидит 30 человек и все внимательно друг друга слушают.

🩷 Когда каждое утро болтаешь с коллегами, и руководство это поощряет.

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

Какие процессы в нашей компании вам показались необычными? А что бы вы сделали по-другому?