Я не называю набор настроек гибкостью, если за него никто не отвечает

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

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

Настройка всегда меняет чью-то работу

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

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

Я смотрю на такую просьбу не как на экран с полем, а как на договорённость. Что именно меняется? Для кого? Кто будет держать это правило в голове через год? Если ответа нет, настройка пока не готова к жизни.

Три вопроса до новой галочки

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

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

Третий: что будет, если о правиле забудут? У хорошей настройки есть безопасное поведение по умолчанию. Заказ не исчезнет, доступ не станет шире, деньги не будут списаны дважды. Самый неприятный вариант — когда выключатель действует тихо, а проблему замечают только по последствиям.

Гибкость не равна бесконечному выбору

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

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

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

Когда просьба о настройке — хороший сигнал

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

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

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

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

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

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

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

Как узнать, что настройки уже стали долгом

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

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

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

Как не превратить внедрение в археологию

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

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

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

Смотреть не на список функций, а на рабочий день

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

Это близко к проверке готовности продукта к обычному понедельнику. Красивую демонстрацию можно провести с подготовленными данными и рядом разработчика. Рабочий день начинается там, где появляется незнакомый сотрудник, неидеальный заказ и вопрос без автора. Об этом подробнее написал в материале «Я проверяю готовность продукта к понедельнику утром».

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

Как договориться с клиентом без обещания всего

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

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

Проверка после запуска

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

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

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

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

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

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

Короткий фильтр для команды

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

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