Артем Рудиченко, CEO Slot City о том, как Feature Flags помогают бизнесу быстрее принимать решения

Самые смелые продуктовые решения обычно принимаются там, где любой шаг можно быстро отменить. На этом принципе придерживается подход Feature Flags, который позволяет включать и выключать новые функции без повторного выпуска сайта или приложения. Почему возможность быстро отказаться от неудачной идеи ускоряет работу всей компании, – рассказал Артем Рудиченко, CEO Slot City.

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

Насколько ощутимо такие зависимости тормозят работу, показывает исследование State of Developer Experience 2025 от Atlassian, в котором приняли участие 3,5 тысяч разработчиков и менеджеров. Половина разработчиков еженедельно теряет более 10 часов на задание вне написания кода. Причем сотрудничество с другими командами среди причин таких потерь поднялось выше, чем годом ранее. Каждое согласование, которое удается убрать из процесса запуска, возвращает команде время для работы над продуктом.

Решения, к которым можно вернуться

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

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

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

Как меняется работа команд

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

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

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

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

Что требует внимания

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

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

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

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