Как организовать совместную разработку двух команд на одном проекте

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

Руководитель отдела управления проектами Intensa Анна Соколова рассказывает о том, как мы в компании работаем с другими командами.

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

Разведение задач. Чтобы разделить направления на проекте. Например, одна команда оказывает техподдержку, вторая — поддерживает какую-то сложную, но очень важную интеграцию.

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

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

Совместную разработку на проекте можно организовать двумя путями.

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

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

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

Договариваемся на старте о правилах работы:

Если мы приходим на проект, где есть инхаус-команда, где уже все настроено, мы работаем на стендах клиента. Так у нас построена работа с международным брендом женской одежды.

Иногда даже в работе с инхаус-командой происходит переназначение и переезд в репозиторий агентства. Но это скорее исключение, чем правило.

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

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

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

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

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

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

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

Например, в проекте Synergetic команда, которая занимается основной техподдержкой, обновляла PHP. Это повлекло обновление не только самого проекта, но и всех модулей, интеграций и т. д. Мы, когда готовили свою сторону — обновление интеграции Mindbox, синхронизировались в чате по регламенту: сначала сделали обновление, потом перенесли на тестовый стенд, протестировали на тестовых заказах, почистили за собой все заказы в Mindbox, зарелизили и сделали отладку на проде.

Что касается технической части, и мы, и другие команды, с которыми работаем, придерживаемся определенных стандартов программирования.

Порядок может быть разный.

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

На проекте Synergetic — оба агентства имеют доступы и на релиз на продакшн. Основное — отвечает в том числе и за сервер. А мы — за интеграцию Mindbox.

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

Зарелизили. Увидели ошибку — мы или коллеги. Пишем в чат. Кто делал релиз, исправляет.

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

Разработали модуль Sentry для интеграции на проектах 1С-Битрикс.

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

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

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

В наше агентство чаще всего обращаются:

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

За интеграциями. Это Mindbox, MAXMA и другие системы.

За SEO. Клиенту удобно отдать SEO в одни руки, чтобы все задачи по этому направлению мы сделали под ключ. Пишем ТЗ, анализируем позиции, даем рекомендации и сразу же их выполняем. Это дает быстрый результат.

За решением сложной или глобальной задачи с внешней экспертизой. Например, разработать CJM или сделать редизайн.

За техническим или UI/UX аудитом интернет-магазина. Помогает увеличить конверсию и скорость.

Мы закрываем любые потребности e-commerce проектов.