Я задаю срок жизни экспериментальной функции до того, как она попадёт в продукт
Я задаю срок жизни экспериментальной функции до того, как она попадёт в продукт. Иначе временное решение почти незаметно становится частью системы: его боятся менять, о нём забывают написать в документации, а поддержка годами объясняет, почему рядом с основным путём есть странная кнопка.
Экспериментальная функция — не ошибка и не признак слабого продукта. Иногда нужно проверить новый способ расчёта, открыть небольшой группе клиентов другой сценарий или дать команде быстрый обход до большого релиза. Риск появляется в другом месте: когда никто не договорился, что именно проверяем, сколько это продлится и какое решение примем по итогам.
Временное решение должно иметь честное имя
Если функция появилась «пока попробуем», это ещё не план. Для команды это означает разное: разработчик считает, что потом перепишет код, менеджер уже обещает возможность клиентам, поддержка включает её в инструкцию, а пользователь воспринимает как постоянное правило.
Я бы назвал эксперимент прямо: для кого он включён, какой рабочий вопрос должен прояснить, до какой даты живёт и кто примет решение о следующем шаге. Не обязательно показывать внутренний ярлык клиенту. Но внутри компании временность должна быть видна всем, кто продаёт, поддерживает и меняет продукт.
Это похоже на строительные леса. Они нужны, пока ремонтируют фасад, и никого не смущают. Проблема начинается, если через год по ним уже ходят жильцы, потому что никто не решил, снимать их или перестраивать вход.
Не путайте эксперимент и индивидуальное исключение
Клиентская просьба часто звучит убедительно: «Нам нужно всего одно поле», «Давайте добавить отдельный маршрут», «Пусть этот пользователь видит другой расчёт». Но просьба одного клиента ещё не доказывает, что продукту нужна новая постоянная возможность.
Сначала полезно понять, повторяется ли ситуация и решает ли функция настоящую рабочую задачу. Иногда лучше помочь настройкой, инструкцией или отдельным процессом. Иногда — провести короткий эксперимент на понятной группе. А иногда честнее отказать, чем спрятать индивидуальную доработку в общий продукт.
Такой разбор защищает не только код. Он защищает доверие клиента: продукт не обещает универсальность там, где на самом деле держится на ручном исключении. Похожий принцип работает и с обращениями в поддержку: повторяющийся сигнал нужно разбирать, а не автоматически превращать в новую функцию. Об этом — в статье о поддержке как сигнале, а не готовом ТЗ.
У эксперимента должен быть вопрос, а не надежда
Фраза «посмотрим, будут ли пользоваться» звучит как проверка, но ничего не объясняет. Пользование бывает разным: человек нажал кнопку один раз, потому что не нашёл старый путь; менеджер показал функцию на встрече; клиент получил реальный результат и вернулся без напоминания.
Перед запуском я бы сформулировал один наблюдаемый вопрос. Например: может ли новый ответственный сотрудник самостоятельно подготовить заявку по новому сценарию? Укладывается ли операция в рабочий день без обращения в поддержку? Уменьшилась ли ручная сверка, ради которой функцию и придумали?
Сразу становится понятно, какие события нужно наблюдать и с кем поговорить. Важна не красивая метрика на дашборде, а связь между функцией и реальным решением человека. Проверка продуктовой гипотезы через изменение привычного рабочего шага даёт здесь гораздо больше, чем вежливое «интересно» на встрече. Этот подход подробно разобран в материале о проверке гипотезы.
Дата завершения — это точка разговора, а не автоматическое удаление
Срок жизни не означает, что в полночь нужно выключить функцию у всех. Он нужен, чтобы команда вернулась к решению. В назначенную дату стоит выбрать один из четырёх понятных путей:
- закрыть эксперимент и убрать функцию, если ценность не подтвердилась;
- продлить проверку, но сформулировать, каких данных не хватает;
- сделать функцию постоянной и привести в порядок права, тексты, поддержку и документацию;
- оставить возможность только как договорное исключение, не выдавая её за общий продукт.
Самый опасный вариант — ничего не решить. Тогда временная функция неявно становится постоянной, а её ограничения никто не обслуживает: нет владельца, нет тестов, нет понятной истории изменений.
Перед постоянным запуском проверьте не только спрос
Даже если эксперимент полезен, его нельзя просто объявить частью продукта. Нужно пройти обычную взрослую проверку:
- понятны ли права и роли, особенно для новых сотрудников клиента;
- видно ли в истории, что произошло с данными;
- есть ли безопасный путь назад, если новый сценарий даёт ошибку;
- объясняется ли функция без устного сопровождения менеджера;
- не создаёт ли она отдельный режим, который ломает основной процесс.
Здесь полезно помнить историю функций, которые «все просили», но почти не использовали. Просьба может быть честной, а решение — всё равно лишним. Причины и выводы я разбирал в статье о функции, которая не стала частью реальной работы.
Короткая карточка эксперимента
Чтобы не потерять смысл, достаточно одной карточки рядом с задачей:
- какую проблему проверяем;
- для какой группы пользователей;
- какой результат будет достаточным;
- какие ограничения действуют сейчас;
- когда и кто принимает решение о судьбе функции.
Так эксперимент остаётся инструментом обучения, а не источником тихого технического долга. Хороший SaaS развивается не количеством навсегда оставленных возможностей. Он развивается способностью команды вовремя решить: это стало полезным правилом продукта или останется честным временным опытом.
Эксперимент не должен менять базовые обещания незаметно
Есть зоны, где осторожность важнее скорости. Нельзя без ясного решения экспериментировать с доступом к данным, расчётом денег, юридически значимыми документами или удалением информации. Даже маленькая «временная» функция в этих местах может поменять ожидания клиента сильнее, чем большой новый экран.
Поэтому до запуска стоит назвать границы. Какие данные эксперимент видит и меняет? Может ли он запустить операцию повторно? Как пользователь поймёт, что попал в новый сценарий? Что произойдёт, если функция недоступна? Ответы не тормозят проверку. Они делают её безопасной для реальной работы.
Если ответов пока нет, иногда лучший эксперимент — не включить кнопку в продукт, а проверить сценарий вручную с небольшой группой. Это позволяет понять потребность раньше, чем появится новый долг в интерфейсе и архитектуре.
Ограничение группы — часть честного теста
Чем шире запуск, тем сложнее понять, что именно произошло. Новую функцию полезно открывать не «всем желающим», а группе с понятным общим контекстом: одному типу компаний, одной роли, одному процессу. Тогда обратная связь не смешивает разные задачи.
Для группы нужно заранее определить путь включения и выключения. Человек не должен случайно потерять возможность продолжить работу из-за того, что эксперимент закончился. Хорошая практика — сохранить основной путь и сделать новый вариант явно дополнительным, пока команда не уверена в решении.
Это также защищает поддержку. Когда запрос приходит от участника эксперимента, специалист видит его контекст, ограничения и сроки. Он не пытается воспроизвести случай по обрывочному описанию и не обещает постоянную возможность до решения владельца продукта.
Смотрите на отказ так же внимательно, как на использование
Команды часто считают нажатия, но не замечают, где люди возвращаются к старому пути. А именно возврат может объяснить больше всего: новая функция не решает задачу, не вызывает доверия, требует недостающих данных или появляется в неправильный момент.
Полезно после первых попыток спросить не «понравилось ли», а «на каком шаге вы решили сделать по-старому и почему». Такой вопрос даёт предметный ответ. Возможно, проблему решит другое название. Возможно, нужна дополнительная проверка. Возможно, исходная идея была неверной и её лучше закрыть сейчас, пока цена маленькая.
Как не потерять эксперимент между командами
У продукта обычно несколько голосов: продажи слышат просьбу клиента, поддержка видит затруднение, разработка знает ограничение, руководитель отвечает за приоритет. Без короткой общей карточки каждый видит только свою часть истории.
Достаточно раз в неделю на несколько минут просмотреть активные эксперименты: что проверяем, есть ли новые риски, какие факты появились, приближается ли дата решения. Это не отдельное совещание ради статуса. Это способ вовремя закрыть то, что перестало быть полезным, и не тянуть неопределённость в следующий квартал.
Превращение в постоянную функцию — отдельная работа
Когда эксперимент подтвердился, хочется просто снять флажок и открыть его всем. Но постоянная функция требует другого качества. Ей нужны понятные тексты, поддерживаемая модель данных, роль и доступы, покрытие критичного сценария проверками, понятная реакция на сбой и место в документации продукта.
Полезно ещё раз спросить: не нарушает ли функция старый путь для тех, кто в эксперименте не участвовал? Не создаёт ли новый режим, который менеджер должен объяснять устно? Не прячет ли она условие тарифа или техническое ограничение? Если ответ вызывает сомнение, лучше оставить функцию в ограниченной группе ещё на один прозрачный цикл.
Срок жизни эксперимента дисциплинирует не пользователя, а команду. Он напоминает, что у каждой новой возможности должна быть судьба. Тогда продукт растёт через осмысленные решения, а не через коллекцию временных кнопок, которые никто уже не решается убрать.
Что сказать клиенту, когда функция ещё проверяется
Честность не требует перегружать человека внутренними деталями. Достаточно объяснить границы: возможность доступна ограниченной группе, команда собирает обратную связь, основной путь остаётся рабочим, а важные данные не пропадут. Не стоит обещать дату общего запуска, если решения ещё нет.
Так клиент понимает, что его участие действительно влияет на продукт, но не строит критичный процесс вокруг хрупкой возможности. Это особенно важно в B2B: у клиента может быть свой регламент, смены сотрудников и ответственность перед покупателями. Эксперимент не должен становиться неожиданным риском для его рабочего дня.
Небольшой пример решения
Представим, что команда хочет добавить быстрый расчёт предложения. Сначала она выбирает несколько менеджеров, которые часто собирают похожие документы. Новая функция создаёт черновик, но не отправляет его клиенту автоматически. В карточке эксперимента есть вопрос: сокращает ли сценарий время подготовки без ошибок в условиях и цене.
Через две недели команда смотрит не только на число созданных черновиков. Она проверяет, сколько из них менеджеры довели до отправки, где вернулись к старому шаблону, какие исключения появились и нужна ли проверка руководителя. Если ускорение держится только на ручной правке каждого документа, это не готовая функция. Если путь стал понятнее и устойчивее, можно планировать постоянную версию.
Такой подход сохраняет скорость эксперимента, но не выдаёт ранний результат за подтверждённое правило продукта.
Обсудим?