Не каждое решение навсегда: классифицируем продуктовые решения по обратимости

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

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

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

Односторонние и двусторонние двери

Самый известный фреймворк об обратимости пришёл из Amazon: односторонние и двусторонние двери. Если вы прошли через двустороннюю дверь и вам не понравилось, можно вернуться. Если решение одностороннее — нужно быть осторожным.

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

Я использую три операционных вопроса:

1. Какие данные или состояние придётся откатывать?
2. Какие пользователи сразу заметят изменение, особенно как нарушенное обещание?
3. Сколько времени команде нужно, чтобы вернуться к текущему состоянию?

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

Три уровня обратимости

На практике повседневные продуктовые решения делятся на три уровня.

Первый уровень: прямой откат. Мелкие изменения интерфейса, формулировки, тайминга push-уведомлений. Пользователи могут заметить, но долгого впечатления не остаётся. Стоимость отката — одна ветка и один регрессионный тест. Этот уровень не требует множества совещаний. Риск быстрого решения очень низкий.

Второй уровень: плановый откат. Изменения структуры данных, полей API, ритма операционной кампании. Нужен миграционный скрипт и план по старым данным. Пользователи могут почувствовать разницу, но она не становится сильным воспоминанием. Откат занимает от полдня до нескольких дней. Требует планирования, но не тревоги.

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

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

Как сделать необратимое обратимым

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

Рефакторинг архитектуры — классический пример. Если делать его как разовую операцию: остановить старый путь и переключить всё сразу, — проблемы будут всплывать каждый день, а вернуться назад очень сложно. Лучший вариант — держать старый и новый пути параллельно, а поведение переключать в рантайме. Тогда рефакторинг превращается в последовательность маленьких обратимых шагов.

В AI-продуктах тот же паттерн. Смена модели выглядит как изменение одного адреса API, но на деле новая модель меняет целое распределение видимого пользователю поведения. Безопаснее использовать теневой режим: новая модель обрабатывает реальные запросы в фоне, вы сравниваете выходы и только потом решаете. Старую модель сохраняете как запасной вход. Если теневой режим слишком дорог, можно включить новую модель для небольшой доли новых пользователей, понаблюдать несколько дней и затем расширять. Решение «какую модель использовать» из необратимого становится обратимым.

Ценообразование заслуживает особой осторожности. Реальная стоимость изменения цены — не доработка биллинга, а доверие, которое тратится каждый раз. Если количество изменений ограничено, сначала проверьте приемлемость цены и отток на маленькой группе. Объявить новую цену публично и затем отменить её — один из самых болезненных откатов.

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

Когда обратимость обманывает

Есть несколько случаев, когда мышление об обратимости уводит в сторону.

Первое: обратимость не означает небрежность. Если каждый релиз устроен по принципу «сначала выпустим, потом починим», команда может привыкнуть к быстрой итерации, но пользователи не привыкнут к вечному полуфабрикату. Каждый быстрый эксперимент должен отвечать на ясный вопрос. Иначе вы тратите не своё время, а терпение пользователей.

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

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

Фреймворк, который делает решения легче

Моё текущее правило для новых запросов простое: тратить на суждение не больше тридцати минут, а затем возвращаться к исполнению. В короткой заметке по требованию — три строки.

Строка первая: делаем или нет. Одна строка, без длинного анализа. Это для вас через месяц. Решение без записи невозможно пересмотреть; оно просто всплывёт потом как спор без контекста.

Строка вторая: уровень обратимости. Определяется тремя вопросами выше. Занимает около трёх минут.

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

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

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

PaxLee