Кто решает, что действительно попадает к пользователям

У вас есть работающий пайплайн. Тесты проходят. Сборки зелёные. Кнопка деплоя прямо перед вами, ждёт. Но никто её не нажимает.

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

За это решение отвечают две роли: продакт-менеджер и релиз-менеджер. Это не один и тот же человек, и они выполняют разные задачи. Но вместе они отвечают на вопрос, на который ваша CI/CD-система ответить не может: «Должно ли это выйти сейчас?»

Продакт-менеджер решает, что будет создано

Продакт-менеджер не пишет код и не запускает пайплайны. Его задача — понять, что действительно нужно пользователям и бизнесу, и превратить это в задачи для команды разработки. В контексте CI/CD эта роль важна ещё до того, как написана первая строка кода.

Продакт-менеджер решает, какая фича пойдёт в следующий спринт, какая будет отложена, а от какой вообще откажутся. Это решение напрямую влияет на то, насколько гладко будет проходить доставка.

Если продакт-менеджер приоритизирует слишком крупную фичу, команда разработки перегружается, и релиз срывается. Если приоритеты меняются слишком часто, разработчики выбрасывают наполовину сделанную работу. Хороший продакт-менеджер понимает, что приоритизация — это не только «что самое важное». Это ещё и «что реально можно доделать и выпустить в реалистичные сроки».

Именно здесь продакт-менеджер взаимодействует с CI/CD-системой. Быстрый пайплайн не поможет, если команда постоянно работает не над тем. Задача продакт-менеджера — обеспечить, чтобы в пайплайн поступали задачи, которые хорошо определены, правильно оценены по объёму и соответствуют потребностям пользователей.

Релиз-менеджер координирует, когда это выйдет

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

Что именно координирует релиз-менеджер?

Во-первых, расписание релизов. Команда использует фиксированное расписание, например, каждый четверг в 14:00? Или они выпускают, как только фича готова? Оба подхода работают, но релиз-менеджер следит, чтобы все знали, какой из них действует.

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

В-третьих, коммуникацию. Команда поддержки знает о грядущих изменениях? Маркетинг готов, если для новой фичи нужно объявление? Релиз, который застаёт другие команды врасплох, создаёт хаос, даже если код идеален.

Релиз-менеджер также проводит решение «go/no-go». Это момент, когда все собираются, часто в коротком чате или на быстрой встрече, и решают, выходит релиз или откладывается. Если только что обнаружен критический баг, релиз-менеджер говорит «стоп». Если всё выглядит безопасно, релиз-менеджер даёт зелёный свет.

Как эти две роли работают с командой разработки

Продакт-менеджер и релиз-менеджер не действуют в вакууме. Они постоянно взаимодействуют с командой разработки.

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

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

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

Но feature flags — не магия. Они всё равно требуют координации. Флаги, которые накапливаются без очистки, превращаются в технический долг. Продакт-менеджер и релиз-менеджер должны отслеживать, какие флаги существуют, какие активны, а какие можно удалить.

Эти роли — не шлагбаумы

Легко воспринимать продакт-менеджера и релиз-менеджера как препятствия. Разработчики хотят релизить. Пайплайн готов. Зачем ждать, пока кто-то скажет «да»?

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

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

Практический чек-лист для продакт- и релиз-менеджеров

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

• До планирования спринта: убедитесь, что фича хорошо определена и реалистично оценена по объёму. Если она слишком большая, разбейте её.
• До написания кода: обсудите с разработчиками оценку трудозатрат. Не считайте фичу маленькой только потому, что она звучит просто.
• До слияния: проверьте, что все изменения прошли ревью и тестирование. Не допускайте, чтобы «починим потом» стало нормой.
• До дня релиза: убедитесь, что команды поддержки, маркетинга и другие знают о релизе. Сюрпризы ведут к хаосу.
• До решения go/no-go: проверьте результаты тестов, статус миграций и известные проблемы. Если что-то неясно — отложите.
• После релиза: отследите, какие feature flags всё ещё активны. Очистите их до следующего цикла релиза.

Вывод

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