Привет, Хабр! Меня зовут Антон Батищев, я бэкенд-разработчик в продуктовой команде Циан. В этой статье поделюсь опытом: как устроена наша работа, какие плюсы мы видим в таком подходе и с какими проблемами сталкиваемся на практике.

Продуктовая команда — это небольшая кросс-функциональная группа специалистов, которая работает над продуктом, обладая высокой степенью автономии.

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

Ключевое отличие от работы в функциональной структуре — отсутствие жёсткого плана действий, спущенного сверху. Вместо списка фич команда получает задачу по улучшению метрик. Например, вместо требования «сделать красную кнопку», команда получает цель «увеличить конверсию в покупку на X%»». Это даёт свободу в выборе инструментов и гипотез для достижения цели: они сами решают, как именно растить аудиторию.

В классической функциональной модели похожая задача решалась бы иначе. Сначала заказчик ставит задачу аналитикам, затем макеты рисует дизайн-отдел, и только потом ТЗ уходит в разработку. Коммуникация между отделами в такой схеме часто затруднена: чтобы изменить концепцию, нужно пройти длинный цикл согласований через руководителей каждого департамента. Это долго и неэффективно, особенно если отделы загружены другими приоритетами. Главное преимущество компактной продуктовой команды — минимальное время на согласование и ускорение доставки ценности пользователю.

Состав продуктовой команды в Циан

Поскольку продуктовая команда — это кросс-функциональная единица, в её составе должны быть все специалисты, необходимые для самостоятельного достижения поставленных целей.

Продукт-менеджер (PM)
В первую очередь нужен человек, отвечающий за продукт перед бизнесом — продукт-менеджер. Он строит стратегию развития продукта, приносит в команду бизнес-требования, которые команда преобразует в технические задачи

Исследователь
Для достижения результата команде важен исследователь. Это специалист, который напрямую общается с пользователями, проверяет их реакцию на изменения и выявляет неудовлетворённые потребности. По сути, он является проводником между бизнесом и пользователями, обеспечивая команду данными для принятия решений.

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

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

Команда разработки
Включает всех необходимых технических специалистов: фронтенд, бэкенд, мобильную разработку (iOS/Android). За качество кода и релизов отвечает QA-инженер.

От идеи до реализации

Циан — это сервис, который работает на Android, iOS, а также в десктопе и в мобильном вебе. Поэтому в команду входят: фронтенд-разработчики, разработчики под Android, разработчики под iOS, бэкенд-разработчики. За качество всех релизов отвечает QA-инженер, который интегрирован в команду и участвует в процессе на всех этапах. Все эти специалисты работают в одном ритме (спринте) и имеют общую цель. Ниже наглядная схема проработки фичи, от идеи до выкатки на пользователей:

Адекватная работа невозможна без выстроенной коммуникации между участниками, тут нам на помощь приходит планирование (груминг). Возьмем пример из схемы выше – реализация фичи. Как происходит груминг? 

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

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

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

Режимы разработки новых фичей

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

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

Процесс разработки новых функций в команде может идти в двух режимах:

А) Параллельная разработка

Бэкенд, фронтенд и мобильные разработчики начинают работу одновременно. Процесс выглядит так:

1. Обсуждаем новую фичу.

2. Согласовываем API-контракты.

3. Параллельно реализуем функциональность.

4. Если что-то не учли — оперативно вносим изменения в контракты.

5. Передаем фичу QA.

6. Выкатываем обновление на пользователей

Б) Бэкенд первым (Backend-First)

Бэкенд-разработчики реализуют новую функциональность заранее. Остальные участники команды получают уже готовый стабильный контракт и могут вести разработку на реальных данных (или на стабильном dev-сервере). Процесс построен немного иначе:

1. Обсуждаем новую фичу всеми разработчиками.

2. Обсуждаем контракты на уровне необходимых полей (часто без согласования точной структуры на старте).

3. Бэкенд реализует API и разворачивает его на сервере (например, в среде интеграции).

4. Клиентские разработчики получают готовые Swagger-спецификации: могут вызывать API и видеть ответы в разных сценариях.

5. Разработчики клиентов включаются в работу.

6. После завершения разработки фича целиком приходит к QA.

7. Выкатываем обновление на пользователей.

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

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

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

• Если все разработчики более-менее свободны, мы ведём работу параллельно.

• Если клиентские разработчики (фронтенд и мобайл) отстают от бэкенда, мы сначала реализуем бэкенд, фиксируем контракт и передаём его в работу.

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

Недостатки продуктовых команд

1. Дублирование функциональности
Из-за высокой самостоятельности команд иногда возникает ситуация, когда разные группы реализуют один и тот же функционал независимо друг от друга. Например, в нашей практике был случай, когда две разные команды практически одновременно начали делать обращение в Росреестр за одними и теми же данными. В итоге на карточке объекта появились две функции, связанные с Росреестром, но никак не интегрированные между собой. Это создало риски для данных: если в одном из сервисов возникала проблема, пользователь мог видеть статус «Проверено в Росреестре», но сами данные не отображались. Это подрывало доверие к продукту.

Решение: Чтобы избежать дублирования, мы внедрили архитектурный комитет и процесс ADR (Architecture Decision Record). Это позволяет фиксировать ключевые технические решения и делать их видимыми для всех команд. Тема обширная, поэтому про детали внедрения ADR расскажем как-нибудь в отдельной статье.

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

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

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

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

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

3. Дефицит узких специалистов
Если команда укомплектована не полностью, отсутствие ключевого специалиста становится критической проблемой. Так, например, у нас долгое время не было iOS-разработчика, хотя функциональность на устройствах Apple была необходима для роста метрик.

Решение: Здесь работают WIN-WIN решения. Мы договариваемся о взаимовыгодном обмене ресурсами. Например, когда у нас долгое время не было iOS-разработчика, мы договорились с соседней командой: они выделили нам своего специалиста на время проекта, а мы взамен предоставили дополнительный ресурс бэкенд-разработки для их задач. Таким образом, цели обеих команд были достигнуты.

Также есть возможность запросить ресурс через Гильдию разработки. Иногда между проектами у разработчиков появляется «окно», и они выходят в гильдию, чтобы помочь всему сообществу. Что такое гильдии разработки, зачем они нужны и как они устроены в Циан — можно почитать в отдельной статье.

Продуктовая команда — это мощный инструмент, но не «серебряная пуля»

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

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

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

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

Коллеги, а какой опыт работы в продуктовых командах у вас? Сталкивались ли вы с проблемой дублирования функционала или нехватки ресурсов внутри команды? Делитесь историями в комментариях — будет интересно обсудить!