Признаки настоящей доменной модели, которые слышны на внедренческих созвонах

Проблема проявляется на созвонах по настройке

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

Именно там и проявляется доменная модель. Люди перестают говорить маркетинговыми словами и начинают говорить так: «мы утверждаем эти заказы в два этапа, если покупатель — реселлер» или «этому аккаунту нужна материнская компания, потому что биллинг отдельно от использования». Эти детали — не украшение. Это и есть продукт.

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

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

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

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

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

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

Фразы, которые указывают на слабую модель

Слабая модель прячется в обычных словах из проектной переписки. На внедренческих созвонах никто не говорит: «у нас сбита структура продукта». Говорят: «это особый случай» или «мы делаем так только для одного клиента». Один-два раза это нормально. Но если одна и та же фраза всплывает снова и снова, значит, продукт гнется вокруг того, что плохо смоделировано.

Еще один признак — язык обходных решений, который повторяется у разных аккаунтов. Команда говорит: «мы сделали временный шаг для клиента A», а потом почти тот же шаг появляется для клиента B и клиента C. Если обходное решение возвращается снова, это уже не разовая история. Это часть бизнеса, просто без нормального названия в продукте.

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

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

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

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

Как звучит настоящая модель

Настоящая доменная модель звучит скучно — и это хорошо. Люди снова и снова используют одни и те же слова, потому что они означают одно и то же для всех.

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

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

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

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

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

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

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

Как разбирать созвоны шаг за шагом

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

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

Потом объединяйте похожие исключения, если они указывают на одно и то же бизнес-правило. Это важнее, чем думает большинство команд. Люди часто описывают одно и то же правило разными словами. Один клиент говорит «согласование менеджером». Другой — «подпись тимлида». Третий — «проверка операционной командой перед запуском». Если шаг делает одну и ту же работу, считайте его одним правилом, пока не появятся доказательства обратного.

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

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

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

Решайте, что перед вами — кастомный запрос или общий случай

Когда клиент просит новый экран, остановитесь, прежде чем что-то строить. Запрос может указывать на настоящее бизнес-правило, а может описывать привычку одной команды, стиль отчетности или тарифный уровень.

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

Начните с простого вопроса: это меняет правило или только предпочтение? Правило влияет на то, как работает бизнес. Предпочтение влияет только на то, как одному клиенту удобнее видеть или вводить те же данные.

Больница, которой нужно хранить второе согласование перед выпиской, имеет дело с правилом. Клиент, который хочет видеть поле согласования слева на экране, — с предпочтением. И то и другое важно, но в продукте они живут по-разному.

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

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

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

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

Здесь помогает и внешняя проверка. Во время архитектурной работы Oleg Sotnikov часто подталкивает команды сначала назвать концепт, а уже потом решать, как он будет выглядеть на экране. Эта привычка не дает клиентским рабочим процессам протекать во все части интерфейса.

Простой пример на запуске SaaS-продукта

SaaS для закупок, запущенный у двух клиентов, может скрывать паттерн прямо на виду. У клиента A простое правило: тимлид утверждает любой запрос выше 2000 долларов, а финансы — все, что выше 10000 долларов.

Клиент B на первом созвоне звучит почти так же. У них тимлид и финансы делают ту же работу, но при закупке регулируемых материалов появляется один дополнительный шаг. Менеджер по compliance хочет проверить такие запросы до финального согласования финансами.

Многие команды реагируют одинаково. Они добавляют в админку переключатель под названием «дополнительная проверка только для этого клиента» и идут дальше.

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

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

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

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

Теперь клиент A и клиент B используют одну и ту же структуру. У одного два этапа. У другого три, потому что правило добавляет compliance-проверку.

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

Ошибки, которые команды совершают, когда слышат исключения

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

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

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

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

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

Небольшая SaaS-команда может начать с аккаунтов, пользователей и согласований. Потом одному enterprise-клиенту нужны «региональные проверяющие» с отдельным путем обхода. Вместо вопроса, не является ли это просто еще одной ролью согласования с условием, команда добавляет новую страницу под названием Regional Review. Через шесть месяцев появляются Global Review, Partner Review и Emergency Review. Названия меняются, но по сути это один и тот же тип правила.

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

Короткие проверки перед тем, как добавлять новые экраны

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

Остановитесь, прежде чем строить. Послушайте два недавних созвона по настройке и спросите, есть ли у продукта уже устойчивые существительные и устойчивые правила.

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

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

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

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

Потом посмотрите на последние три обходных решения вместе. Если одна более чистая модель может поглотить все три, перестаньте латать края.

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

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

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

Следующие шаги для вашей команды

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

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

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

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

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

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

Если картина все еще остается мутной, перед тем как добавлять новый UI, привлеките внешнее ревью. Oleg Sotnikov на oleg.is — разумный выбор для такой проверки, потому что его работа охватывает архитектуру продукта, системы для стартапов, поддержку в роли Fractional CTO и команды, которые делают продукты с AI-first подходом. Один жесткий разбор сейчас может сэкономить месяцы лишних экранов, разовых правил и боли в поддержке позже.