Единый язык для индивидуальных сделок, которым может пользоваться команда

Где начинается путаница

Путаница обычно начинается ещё до того, как кто‑то написал код. Продавец говорит «custom tier», в контракте фигурирует «commercial exception», а в кодовой базе есть флаг special_plan. Все предполагают, что эти имена означают одно и то же. Часто это не так.

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

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

Вот где общая терминология перестаёт быть теорией и становится базовой дисциплиной. Если один и тот же термин для продаж значит «сниженная цена», а для инженеров — «требуется ручное одобрение», то передача уже провалилась.

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

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

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

Находите термины, которые меняют поведение

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

Команды часто тратят слишком много времени на ярлыки вроде «premium», «white glove» или «strategic plan», когда эти слова ничего не триггерят в продукте. Они помогают продажам, но не должны входить в рабочую терминологию, если не меняют поведение системы.

Простой фильтр работает отлично. Оставляйте термин только если он отвечает на такие вопросы:

• Меняет ли он то, что клиент платит?
• Разблокирует ли он или блокирует функцию?
• Меняет ли он время выставления счета или способ расчёта?
• Меняет ли он лимит, квоту, число мест или правило перерасхода?
• Меняет ли он поведение поддержки, продления или отмены?

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

Следите за контрактами и коммерческими предложениями. Эти документы часто скрывают фразы, которые позже появляются в коде странными развилками. В предложении может быть «annual commit with monthly billing», а в системе биллинга — поле «installment plan», а инженеры называют это «split invoice». Это одно правило в трёх именах.

Для каждого термина отметьте, где он сейчас фигурирует: текст контракта, форма заказа, поля CRM, настройки биллинга, флаги функций или админ‑инструменты. Эта быстрая карта покажет, где уже есть расхождение.

Одно короткое обещание продаж может содержать несколько поведенческих терминов. «50 included seats, then paid overage after approval» включает, как минимум, три: included seats, overage и approval. Если эти слова не попали в правила биллинга или настройки продукта, они вскроются позже под случайными именами. Обычно именно там начинаются проблемы.

Дайте каждому термину одно значение

Когда индивидуальная сделка идёт не так, контракт часто не самая большая проблема. Настоящая проблема — когда один термин для продаж значит одно, для продукта — близкое, но другое, а в коде — вообще третье.

Дрейф начинается незаметно. Менеджер говорит «pilot», финансы говорит «trial», а инженеры добавляют флаг promo_mode. Все думают, что это одно и то же. Обычно это не так.

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

Полезное определение делает три вещи: говорит, что означает термин, какие значения допустимы и что именно он меняет.

Например:

• «Billing start» — это дата, с которой начинаются начисления.
• «Seat cap» — это максимальное число активных пользователей, включённых в сделку.
• «Support tier» — это целевой срок реакции, обещанный клиенту.
• «Overage rule» — это то, как обрабатывается дополнительное использование.

Самое важное — эффект. Если «billing start» меняет выставление счетов, укажите это. Если это не меняет доступа к продукту — тоже укажите. Если «support tier» меняет цели ответа, но не открывает функции — зафиксируйте это. Чёткие границы не позволят термину незаметно накапливать дополнительный смысл.

Похожие термины нужно убирать, а не дипломатично обсуждать. Если «pilot», «trial» и «evaluation period» все означают «клиент может пользоваться продуктом до обычного начала биллинга», выберите один термин и удалите остальные из шаблонов, тикетов и кода. Старые ярлыки создают запасные двери для путаницы.

Команды теряют дни на баги именования, которые выглядят как баги продукта. Одно поле называется «grace period», другое — «delayed billing», а третий флаг вообще отключает счета. В контракте обещалось лишь отложенное начало. Код изменил гораздо больше, потому что никто не зафиксировал значение.

Если привлекаете внешнее техническое руководство, это одна из первых работ по очистке, которые стоит сделать. Oleg Sotnikov на oleg.is, например, выполняет Fractional CTO‑задачи: прослеживает, где бизнес‑термины меняют поведение, и упрощает модель до того, как код успевает вырасти вокруг плохих имен.

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

Используйте одни и те же слова везде

Термин сделки проваливается, когда каждая команда даёт ему своё имя. Продажи говорят «launch discount», юристы пишут «introductory pricing», CRM сохраняет «promo», а код проверяет trial_rate. Люди думают, что они согласны, но продукт живёт по имени в коде, а не по намерению контракта.

Выберите один термин и используйте его везде, где правило встречается: в предложении, в контракте, в поле CRM, в админ‑панели, в логах, в алертах и в комментариях к коду. Если у клиента «seat cap», никто не должен называть то же правило «user limit», если только эти слова действительно не обозначают разные вещи.

Это особенно важно при передаче от продаж к инженерам. Единая формулировка экономит время: никто не переводит одно и то же правило четыре раза. Это также упрощает ревью. Когда поддержка видит в логе ошибку «minimum commitment not met», она должна соотнести её с контрактом без просьбы инженера расшифровать.

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

Быстрый аудит помогает. Сравните термин в предложении, формулировке контракта, имени поля CRM, метке в админке и сообщении в логе. Если где‑то используется другое слово для того же правила, исправьте это до релиза.

Надписи, видимые пользователю, тоже требуют внимания. Допустим, бэкенд‑правило называется «included seats», а в дашборде написано «team size». Клиент может подумать, что может добавлять кого угодно, пока команда остаётся небольшой, в то время как реальное правило учитывает только оплачиваемые места. Этот разрыв превращает проблему формулировки в спор по выставлению счёта.

Логи и админ‑экраны легко игнорировать, но они формируют ежедневные решения. Если в глоссарии написано «custom pricing rule», используйте именно эту фразу и там. Чёткие имена сокращают обращения в поддержку, неверные предположения и тайные обходные пути, которые люди придумывают, когда система звучит непоследовательно.

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

Стройте язык на реальных сделках

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

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

Когда найдёте такой пункт, перепишите его простым языком. «Customer can go 10 seats over for 30 days» легче обрабатывать, чем вставка текста контракта в тикет.

Затем сгруппируйте похожие пункты под одним именем. Команды часто носят одну идею под тремя ярлыками, потому что продажи, продукт и инженеры выбрали свои слова. «Seat buffer», «temporary overage» и «grace seats» могут значить одно и то же. Выберите одно имя и уберите остальные.

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

Для каждого термина ответьте на четыре вопроса:

• Что его триггерит?
• Что меняется в продукте?
• Где мы его фиксируем?
• Кто может его одобрить?

Если команда не может одинаково ответить на эти четыре вопроса, термин всё ещё размытый.

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

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

Простой пример индивидуальной сделки

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

Продажи пишут «flex plan» в CRM, потому что так удобнее объяснить. Инженеры сохраняют custom_billing, потому что это поле уже есть. Финансы читают контракт и помечают как prepaid. Поддержка видит ежемесячные счета и исходит из правил постоплаты. У одной сделки теперь четыре имени.

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

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

Когда кто‑то откроет аккаунт через полгода, ему не придётся расшифровывать кличку. Он увидит одно и то же имя в сводке контракта, в карточке клиента и в логах. Так правило переживает смены персонала, срочные релизы и неаккуратные передачи.

Звучит мелочь, но это убирает много догадок. Финансы больше не должны решать, означает ли «flex plan» предоплату или постоплату. Поддержке не нужно интерпретировать кличку. Инженерам не приходится сводить три ярлыка в одно положение контракта каждый раз, когда они трогают логику биллинга.

Ошибки, которые приводят к дрейфу

Дрейф начинается, когда слова в сделке перестают совпадать со словами в продукте.

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

Другая проблема — когда одноразовые сделки обходят глоссарий. Первая исключительная сделка кажется безвредной. Вторая добавляет слегка другое имя, третья — ещё одно. Вскоре появляются «pilot discount», «launch credit» и «intro offer», которые делают почти одно и то же под тремя именами.

Использовать один термин для двух разных правил ещё хуже. «Minimum commit» может означать для финансов платёжный минимум, в то время как разработчик использует тот же термин для уровня использования, который открывает функции. Команда думает, что согласна, потому что метка совпадает. На деле — нет.

Старые синонимы поддерживают путаницу долго после того, как команда заметила проблему. Дашборд говорит «user limit», API — «seat cap», внутренняя документация — «licensed users». Люди тратят время, пытаясь угадать, разные ли это правила. Иногда поддержка отвечает неправильно и даёт клиенту неверную информацию.

Feature‑флаги — ещё одно укрытие для бизнес‑правил. Флаг должен управлять временем релиза. Он не должен быть единственным местом, где живёт кастомное правило ценообразования. Когда это происходит, никто не знает, меняет ли переключение флага биллинг, доступ или то и другое.

Несколько предупредительных сигналов проявляются рано:

• Продажи постоянно просят инженеров объяснить один и тот же термин.
• Поддержка не может сопоставить строку счёта с поведением продукта.
• Разработчики добавляют «new» или «v2» вместо исправления плохого имени.
• Документы, дашборды и код используют разные слова для одного и того же правила.

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

Проверки перед релизом

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

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

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

Сравните формулировку контракта с метками в продукте. Если в контракте «minimum commit», а в приложении «reserved seats», убедитесь, что они действительно означают одно и то же.

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

Затем прогоните одну тестовую сделку через логи, счёта и админ‑экраны. Один и тот же термин должен появляться одинаково везде.

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

Короткая репетиция ловит это быстро. Создайте пример сделки, прогоните её через регистрацию, биллинг, админку и ответ поддержки, затем сравните термины рядом. Если где‑то написано «credit», где‑то «discount», а в счёте «manual adjustment», остановитесь и почистите.

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

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

Что делать дальше

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

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

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

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

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

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

Если ваша команда уже в такой ситуации, внешняя помощь может сэкономить много времени. Oleg Sotnikov на oleg.is работает с стартапами и малыми командами над этой очисткой, особенно там, где структура сделок, архитектура продукта и логика биллинга перепутаны.

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