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

Я не добавляю настройку в SaaS только потому, что два клиента попросили разное. Сначала пытаюсь понять, есть ли за просьбой настоящее правило, которое продукт может объяснить всем, или это частный способ обойти неясный процесс.

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

Почему настройка кажется безопасным ответом

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

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

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

Начинаю не с экрана, а с решения

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

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

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

Четыре вопроса перед новой настройкой

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

1. Какое повторяющееся решение меняется? Если ответ звучит как «так удобнее одному человеку», это ещё не причина менять продукт.
2. Кому ещё понадобится тот же выбор? Не нужно угадывать рынок. Достаточно честно отличить общий сценарий от разовой договорённости.
3. Что увидит новый пользователь? Он должен понимать настройку без звонка разработчику и без историй о том, почему она появилась.
4. Что будет, если оставить значение по умолчанию? Хорошая настройка имеет безопасный и понятный базовый путь. Если такого пути нет, продуктовое правило ещё не сформулировано.

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

Не каждая разница требует настройки

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

Первый тип — разные данные внутри одного правила. Например, собственные этапы, список подразделений, сроки реакции. Это обычно настраивается спокойно: логика остаётся общей, меняется контекст.

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

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

Цена настройки живёт после релиза

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

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

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

Что делать вместо «давайте добавим галочку»

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

Затем я бы проверил сценарий на первом рабочем дне пользователя. В материале о первых десяти минутах пользователя в SaaS эта мысль особенно важна: человек не обязан помнить внутреннюю историю продукта. Ему нужно быстро понять, что сделать сейчас и почему система просит именно это.

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

Как выглядит проверка на живом сценарии

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

После такого разбора запрос часто меняется. Клиенту может быть нужна не «гибкая скидка», а исключение из утверждённой матрицы с видимой причиной и подтверждением руководителя. Это уже не набор настроек, а отдельный рабочий сценарий. У него есть граница, владелец и история. Его легче объяснить новому сотруднику и безопаснее анализировать.

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

Когда стоит сказать клиенту «пока нет»

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

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

Мой простой ориентир

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

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