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

Привет! Меня зовут Жанна Трофимова, я директор по развитию Intensa. К нам обращаются за развитием, техподдержкой и продвижением федеральных интернет-магазинов.

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

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

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

Когда нужны две команды на проекте

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

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

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

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

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

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

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

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

2. На компанию работают два подрядчика — две независимые компании, которые вместе образуют профессиональный симбиоз знаний и опыта, чтобы дать максимальный и быстрый результат клиенту.

У нас таким образом построена работа на проекте Synergetic. В проекте Synergetic одна команда разработчиков оказывает техподдержку всего проекта, а мы занимаемся техподдержкой интеграции Synergetic-Mindbox.

Опыт работы с ребятами из Intensa исключительно хороший — мы работаем вместе уже больше двух лет. За это время прошли большой путь в разработке и интеграции с Mindbox — внедрили очень много нестандартных механик по обмену данными и управлению сущностями на synergetic.ru из Mindbox и наоборот.

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

Станислав Черикчиев,
Head of CRM-marketing SYNERGETIC

С чего начать совместную работу на проекте

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

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

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

Договариваемся на старте о правилах работы:
— об общих регламентах работы с Git,
— на каких площадках тестируем,
— через какой стенд проводим релизы,
— как синхронизируемся по релизам,
— кто проводит ревью и релизы,
— кто отвечает, если что-то случится на проекте вне релиза,
— кто оказывает техническую поддержку сервера в случае инцидентов, падений и недоступности.

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

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

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

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

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

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

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

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

Кто руководит разработкой и согласовывает технологические решения

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

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

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

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

Когда пишем на PHP, придерживаемся стандартов PSR (PHP Standart Recommendations). Это набор рекомендаций, установленных PHP-сообществом. Они помогают разработчикам улучшить читаемость кода и повысить его качество, ускорить процесс разработки и упростить совместную работу над проектом. Код получается стандартизированным и согласованным, а разные команды могут работать с ним быстро и удобно.

Иван Шишкин,
руководитель отдела разработки Intensa

Как ревьюить проекты

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

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

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

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

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

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

В мониторинге кода может помочь Sentry. Это сервис, который находит ошибку или конфликт в коде с продакшена. Он сразу присылает алерт с детальной ошибкой и ссылкой на merge request, которая стала причиной проблемы. Мы устанавливаем Sentry на проекты и узнаем об ошибках раньше покупателей интернет-магазинов.

Иван Шишкин,
руководитель отдела разработки Intensa

Как анализировать совместную работу

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

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

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

Какие задачи чаще всего решаем с другими командами

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

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

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

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

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

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

11
3 комментария

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

Ответить

Ох уж эти нейросети)

Ответить