Я добавляю настройку в продукт только там, где она делает правило понятнее

В продуктовой работе есть удобная ловушка: любую спорную ситуацию попытаться решить новой настройкой. Клиенту нужен особый порядок согласования — добавим переключатель. Для одной роли нужен другой срок — добавим поле. В одном регионе требуется исключение — сделаем ещё один режим.

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

Поэтому перед добавлением параметра я сначала ищу границу. Что продукт обязан делать одинаково для всех? Где компания вправе выбрать вариант? И что вообще лучше решить разговором и рабочей инструкцией, а не кодом?

Настройка — это не поле, а обещание

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

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

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

Три вопроса, которые я задаю до разработки

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

Второй: кто владелец правила? Не разработчик, который добавил параметр, а роль в бизнесе, которая вправе сказать: «для нас это работает так». Например, финансовый директор определяет лимит согласования, а руководитель продаж — правило передачи лида. Без владельца настройка будет меняться по случайным просьбам.

Третий: что увидит человек, который не участвовал в запуске? Ему должно быть ясно, какое правило сработало, где его изменить и что будет дальше. Если для этого нужно писать в поддержку, объяснять настройку ещё рано.

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

Что оставлять неизменным

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

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

Полезный тест простой: можно ли описать правило одной фразой? «Когда происходит X, система делает Y, потому что за решение отвечает Z». Если в этой фразе нет причины или владельца, перед нами пока не настройка, а просьба отложить выбор.

Сначала живой сценарий, потом интерфейс

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

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

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

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

Признаки, что продукт уже перегружен исключениями

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

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

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

Как дать клиенту честный ответ

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

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

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

Как проверить настройку после запуска

Через несколько недель я бы вернулся к новой опции с теми же вопросами. Ею пользуются в заявленной ситуации или она стала запасным обходом? Стало ли меньше ручных уточнений? Понимает ли новый сотрудник её эффект без помощи автора? Может ли владелец изменить правило в своей зоне ответственности?

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

Это дисциплинирует и продуктовую команду. Вместо коллекции выполненных запросов появляется набор осознанных правил, каждое из которых можно объяснить, проверить и при необходимости пересмотреть. Для зрелого SaaS это важнее максимального числа галочек.

Граница помогает планировать развитие

Когда в продукте понятны постоянные правила и допустимые варианты, проще обсуждать roadmap. Команда не обещает «сделать гибче вообще», а видит конкретные типы сценариев. Одни идеи становятся универсальными возможностями. Другие остаются в контуре внедрения. Третьи требуют отдельного архитектурного решения, потому что затрагивают данные, права или интеграции.

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

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

Гибкость должна уменьшать ручную работу

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

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

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

Короткая проверка перед новой настройкой

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

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