Привет! Меня зовут Мария Болдырева, и я уже пять лет возглавляю проектное бюро WildTeam. До этого я работала главным конструктором в различных строительных компаниях. Ежедневно я сталкивалась с проблемами менеджмента в проектных компаниях и мечтала его изменить. В итоге взялась за дело и смогла, так что коллеги из отрасли смотрят на нас с завистью.

Здесь рассказываю о своем опыте, команде, принципах, результатах и факапах.

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


Абстрактно про Agile

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

  • Люди и коммуникация важнее процессов и инструментов;

  • Продукт, который работает, важнее документации, покрывающей все и вся;

  • Сотрудничество и коммуникация с заказчиком важнее контрактных условий;

  • Готовность к изменениям и гибкость в работе важнее, чем слепо следовать первоначальному плану.

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

Функциональные и продуктовые команды в Agile: в чем разница и как они работают

В Agile обычно работают продуктовые команды, однако в сфере проектирования чаще/всегда встречаются функциональные. Нам пришлось адаптировать метод под нашу деятельность, сохранив обе структуры с определенными задачами. То есть у нас работают и функциональные и продуктовые команды одновременно.

  • Функциональные команды 

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

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

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

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

  • Продуктовые команды

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

Продуктовая команда строит свою работу следующим образом:

  • Изучает проект и составляет список вопросов для заказчика;

  • Проводит встречу с клиентом, чтобы выяснить все важные моменты;

  • Разрабатывает план проекта, расставляет приоритеты и определяет, сколько специалистов нужно для каждой задачи;

  • Определяет задачи для первого спринта и распределяет их между сотрудниками.

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

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

Инструменты планирования и как они помогают

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

  • Продуктовая команда составляет список задач на две недели и рассказывает о своих шагах заказчику;

  • Вносим изменения, если у заказчика есть срочные замечания;

  • Две недели команда работает, получает результат и его согласовывает;

  • Цикл повторяется с новыми задачами.

В основе работы — планирование, которому мы уделяем много времени и используем разные инструменты.

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

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

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

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

В следующей колонке расскажу, как мы работаем с клиентами и упрощаем бюрократию и почему сотрудники любят работать в WildTeam.

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

Комментарии (3)


  1. Aleh-Kash
    16.10.2024 12:21

    Если я правильно понял, вы используете инкрементный способ работы на проектом.

    Вопросы:

    1. Как вам (команде) удаётся так формализовать результат, чтобы потом без проблем его сдать Заказчику? Обычно строительное проектирование - сложный и длительный процесс (явно больше двух недель :) ). Возможно ли выделить "полуфабрикаты" для спринтов и потом доказать Заказчику, что они сделаны правильно?

    2. Вовлечён ли Заказчик в планирование спринта?

    3. Ревью - это в том числе и "ретро"?


    1. kalinin_krd
      16.10.2024 12:21

      Мне больше интересно то, как в таком случае идёт управление временем и как это обсуждается с заказчиком. В 99% случаев заказчикам нужен комплект документации к определённому числу.

      Правильно ли я понимаю, что продуктовый подход применен к эскизной части проекта, а все остальное - классический процесс проектирования по ватерфоллу?


  1. Ioldyz
    16.10.2024 12:21

    Как вы уживаетесь с заказчиком?)

    В таком виде деятельности заказчик просит подробный план, к примеру, на год (водопад). Далее вы дробите это дело до двухнедельных спринтов?

    Или у вас проектные работы максимум, к примеру, 3–4 месяца?