# Вопросы перед перерисовкой архитектуры, чтобы получить более точную карту

> Используйте эти вопросы перед перерисовкой архитектуры, чтобы product, support, sales и ops сформировали карту доменов, отражающую реальные ежедневные нагрузки.

## Почему перерисовки идут не так

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

Один и тот же рабочий процесс создаёт разную боль для разных команд. Product видит задержки и недовыполненный объём. Support видит повторяющиеся тикеты, странные пограничные случаи и запутавшихся клиентов. Sales замечает, где сделки тормозят, потому что функцию трудно объяснить или настройка выглядит рискованной. Ops видит проваленные задания, хрупкие интеграции и ручные исправления, которые никогда не попадают в планирование.

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

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

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

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

## Кого опрашивать

Начните с product, support, sales и ops — по одной группе за раз. Каждая из них видит свой тип давления, и это давление формирует домен сильнее любой диаграммы.

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

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

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

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

Один вопрос важнее остальных: кто действительно чувствует стоимость, когда система становится неудобной или падает? Если одна и та же боль проявляется в product, support, sales и ops — вы близки к реальной границе.

## Что спрашивать у product

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

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

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

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

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

## Что спрашивать у support

Support видит беспорядок, который диаграммы скрывают. Product говорит о запланированном потоке. Support рассказывает, где реальные пользователи застревают, повторяют шаги или сдаются.

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

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

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

Ещё один полезный вопрос: «Какие состояния аккаунта ломают ваш обычный плейбук?» Хорошие специалисты support отвечают быстро. Они помнят клиента, у которого trial истёк после оплаты, клиента, прикреплённого к неправильной компании, или отменённый план, который всё ещё открывал функции. Это не мелочи. Это показывает, где модель прогибается или ломается.

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

## Что спрашивать у sales

Sales легко недооценивать в работе над архитектурой. Product говорит о намерениях, support — о боли, а sales слышит, что клиенты думают, что покупают.

Начните с обещания, которое чаще всего закрывает сделки. Попросите рассказать, что происходит после того, как это обещание дано. Требует ли доставка ручной настройки, кастомного workflow или доподлинного одобрения, чтобы обещание стало правдой? Язык sales часто звучит просто, а система платит цену позже.

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

Несколько вопросов обычно быстро проясняют ситуацию:

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

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

Обратите особое внимание на передачу в onboarding. Спросите sales, что они рассказывают на звонках, чего продукт не может объяснить сам. Если onboarding вынужден пересказывать историю иначе, архитектура, вероятно, отражает расплывчатую модель доменов.

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

Небольшой пример показывает это ясно. Одна SaaS‑команда считала, что продаёт один продукт‑рабочее пространство. Интервью с sales показали два совершенно разных типа сделок: маленькие команды хотели совместную работу, а крупные покупатели требовали жёсткого разделения между отделами. Эта разница изменила onboarding, права доступа и биллинг, поэтому перерисовка началась именно с этого.

## Что спрашивать у ops

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

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

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

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

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

Хорошее discovery не гоняется за теорией. Оно обнаруживает ручные шаги, риск тайминга и ремонтную работу, которые поддерживают бизнес в рабочем состоянии.

## Простой поток интервью

Выберите один реальный запрос, который произошёл недавно. Возьмите то, что прошло через product, support, sales и ops за последние недели. Люди лучше помнят грязные места, когда работа ещё свежа.

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

Когда каждый рассказывает, записывайте три вещи:

- кто касался запроса
- какое решение принимал каждый человек или команда
- где работа переходила из рук в руки

Эта простая запись обычно даёт больше, чем отшлифованная диаграмма. Вы заметите скрытые согласования, отсутствующую собственность и шаги, зависящие от tribal knowledge.

Обращайте внимание на названия. Sales может называть нечто «аккаунт», support — «рабочее пространство», а ops отслеживать как tenant или deployment. Когда команды по‑разному называют одно и то же, карта доменов уже начинает дробиться.

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

## Ошибки, искажающие карту

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

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

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

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

Потоки возвратов — частый пример. Support может обрабатывать тикет, но биллинг двигает деньги, ops проверяет остатки, а product владеет правилами политики. Если всё поместить под support, карта скрывает истинные точки давления.

Следите за предупреждающими знаками:

- один менеджер отвечает за всех;
- люди описывают согласования вместо бизнес‑событий;
- исключения отмахиваются как «редкие»;
- черновик зеркалит текущую органиграмму.

Хорошее discovery немного дискомфортно. Люди спорят. Кейсы противоречат друг другу. Кто‑то говорит: «Мы делаем это вручную, потому что система не справляется». Это обычно тот момент, когда карта начинает становиться честной.

## Простой пример

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

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

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

Sales давила по‑своему. Крупные клиенты хотели кастомные даты выставления счетов, условия контрактов и исключения, не вписывающиеся в дефолтный месячный поток. Команда называла это крайними кейсами. Со временем эти кейсы стали составлять серьёзную долю выручки.

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

После отдельных интервью новая карта изменилась быстро. «Чекаут» перестал быть одной коробкой. Команда разделила его на биллинг, идентичность аккаунта и права доступа (entitlements).

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

## Быстрая проверка перед перерисовкой

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

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

Потом проследите один реальный клиентский кейс через все передачи. Выберите что‑то грязное, а не аккуратный демо‑поток. Апгрейд плана, который ломает биллинг, возврат средств, который требует участия product, или обещание sales, которое ops не может выполнить, покажут, где карта прогибается под давлением.

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

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

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

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

Начните с одного workflow, а не со всей системы. Выберите что‑то, что часто болит: обработка возвратов, передача лидов или реакция на инциденты. Затем запланируйте четыре отдельных интервью на этой неделе с product, support, sales и ops. Отдельные звонки важны, потому что люди меняют свои истории, когда другие команды находятся в комнате.

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

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

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

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

Иногда полезен внешний взгляд. Oleg Sotnikov на oleg.is занимается такой Fractional CTO‑работой со стартапами и малыми компаниями: он смотрит на границы продукта, инфраструктуру и повседневную реальность за ними. Свежий взгляд может выявить слепые зоны, которые команда начала воспринимать как норму.