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

Почему перерисовки идут не так\n\nБольшинство перерисовок архитектуры терпят неудачу ещё до того, как кто‑то откроет инструмент для диаграмм. Команда собирается на один воркшоп, набрасывает аккуратный поток и слишком быстро соглашается. В реальной работе всё редко бывает так опрятно.\n\nОдин и тот же рабочий процесс создаёт разную боль для разных команд. Product видит задержки и недовыполненный объём. Support видит повторяющиеся тикеты, странные пограничные случаи и запутавшихся клиентов. Sales замечает, где сделки тормозят, потому что функцию трудно объяснить или настройка выглядит рискованной. Ops видит проваленные задания, хрупкие интеграции и ручные исправления, которые никогда не попадают в планирование.\n\nЕсли посадить всех этих людей в одну комнату, тихие проблемы обычно исчезают. Support и ops часто несут дорогие детали, но не всегда выигрывают дискуссию в комнате. Громкая команда может сместить карту в сторону своих проблем, даже когда большая стоимость лежит где‑то в другом месте.\n\nСтарые диаграммы усугубляют это. Многие из них следуют органиграмме, а не самой работе. Они показывают команды, системы и блоки собственности, но пропускают реальный путь заказа, тикета, возврата или сбоя синхронизации. Результат выглядит аккуратно и всё равно ведёт к плохой перерисовке.\n\nВот где работа над архитектурой начинает сбиваться. Карта начинает отражать того, кто громче говорит, кто владеет бюджетом или кто построил первую версию лет назад. Она перестаёт отражать то, где действительно накапливается давление.\n\nЕсли вы хотите честную картину — поговорите с командами по отдельности, прежде чем что‑то перерисовывать. Индивидуальные интервью работают лучше, чем общий воркшоп, потому что каждая команда объясняет один и тот же поток с точки зрения своей ежедневной боли.\n\n## Кого опрашивать\n\nНачните с product, support, sales и ops — по одной группе за раз. Каждая из них видит свой тип давления, и это давление формирует домен сильнее любой диаграммы.\n\nГрупповые встречи размывают картину. Люди смягчают ответы, когда рядом коллеги, и становятся ещё осторожнее, если приходит менеджер. Небольшие приватные разговоры работают лучше.\n\nВыбирайте людей, которые имеют дело с живой работой каждый неделю, а не тех, кто только просматривает сводки. Руководитель поддержки, который всё ещё читает очередь, лучше директора, получающего месячный отчёт. Менеджер по продажам, который теряет сделки на одном и том же возражении, полезнее того, кто только смотрит графики воронки.\n\nГоворите с тем, кто ещё помнит прошлый вторник. Реальные случаи важны. Они показывают, где система прогибается, где люди обходят её и где текущая карта уже неверна.\n\nПервый раунд держите без инженеров. Звучит странно, но это помогает. Инженеры часто сразу переходят к исправлениям или начинают защищать текущий дизайн до того, как факты ясны. Подключайте их позже, когда соберёте истории, чтобы они могли сверить услышанное с кодом и инфраструктурой.\n\nОдин вопрос важнее остальных: кто действительно чувствует стоимость, когда система становится неудобной или падает? Если одна и та же боль проявляется в product, support, sales и ops — вы близки к реальной границе.\n\n## Что спрашивать у product\n\nProduct обычно знает, где обещание продукта перестаёт соответствовать реальности системы. Начните с доверия, а не с фич. Спросите, какое пользовательское путешествие первым теряет доверие при проблеме: регистрация, онбординг, оплата, поиск, отчёты или настройки аккаунта. Первый момент, когда пользователи перестают верить продукту, часто указывает на часть архитектуры, которой нужна более чёткая граница.\n\nПотом спросите, где обещания в roadmap натыкаются на жёсткие ограничения. Продукт‑менеджер может сказать: «Мы постоянно обещаем гибкое ценообразование, но каждое исключение требует инженеров», или «Мы продаём живые дашборды, но часть цифр обновляется лишь несколько раз в день». Это говорит больше, чем любой бэклог. Это показывает, где текущая модель, разделение ответственности или поток данных мешают продукту держать слово.\n\nСпросите о обходных решениях, которые команда принимает перед релизом. Product обычно знает, с какими шероховатостями им приходится мириться, потому что исправление задержало бы релиз. Может быть, они выпускают с ручным шагом одобрения, прячут настройку для одного сегмента клиентов или избегают фичи на мобильных, потому что там она ведёт себя иначе. Если обход живёт дольше одного‑двух релизов, это обычно указывает на несоответствие в карте доменов.\n\nСпросите, какие данные они всё ещё проверяют вручную. Этот вопрос даёт честные ответы быстро. Если продуктовые люди сверяют суммы дохода, статус подписки, права доступа, счётчики использования или историю клиента перед демо или релизом, они не доверяют системе, которая должна рассказывать одну очевидную историю.\n\nНе спрашивайте product, какой сервис переписать. Они редко называют правильный технический фикс. Им проще назвать сломанные обещания, временные костыли и числа, которым никто полностью не доверяет. Именно это давление должна отражать ваша новая карта.\n\n## Что спрашивать у support\n\nSupport видит беспорядок, который диаграммы скрывают. Product говорит о запланированном потоке. Support рассказывает, где реальные пользователи застревают, повторяют шаги или сдаются.\n\nНачните с одного прямого вопроса: «Какой тикет появляется каждую неделю, даже если ничего не менялось?» Повторяющиеся тикеты часто указывают на бизнес‑правило, которое пользователи не понимают, или на то, что граница системы протекает в интерфейс. Если клиенты каждую неделю спрашивают, почему заказ в статусе «оплачен», но выглядит как «в ожидании», возможно, ваша карта разделяет одно бизнес‑состояние на два разных смысла.\n\nПотом спросите, какое дело дольше всего объяснять. Длинные объяснения обычно означают неуклюжую модель. Агентам может понадобиться несколько сообщений, чтобы объяснить окно отмены, частичный возврат или почему кто‑то может войти в систему, но не пользоваться аккаунтом. Когда supportу нужен скрипт, чтобы объяснить нормальное поведение, архитектура часто отражает внутреннюю историю, а не то, как бизнес выглядит для клиентов.\n\nУточните, где агентам нужна помощь администратора, чтобы закрыть кейс. Эти передачи важны. Если support видит проблему, но не может исправить её без сброса аккаунта, ручной синхронизации или изменения прав, граница команды, вероятно, стоит не там, где нужно.\n\nЕщё один полезный вопрос: «Какие состояния аккаунта ломают ваш обычный плейбук?» Хорошие специалисты support отвечают быстро. Они помнят клиента, у которого trial истёк после оплаты, клиента, прикреплённого к неправильной компании, или отменённый план, который всё ещё открывал функции. Это не мелочи. Это показывает, где модель прогибается или ломается.\n\nЗаписывайте точные слова support. Их язык часто понятнее названий в коде. Это помогает не перерисовать систему вокруг версии бизнеса, которая существует только на доске.\n\n## Что спрашивать у sales\n\nSales легко недооценивать в работе над архитектурой. Product говорит о намерениях, support — о боли, а sales слышит, что клиенты думают, что покупают.\n\nНачните с обещания, которое чаще всего закрывает сделки. Попросите рассказать, что происходит после того, как это обещание дано. Требует ли доставка ручной настройки, кастомного workflow или доподлинного одобрения, чтобы обещание стало правдой? Язык sales часто звучит просто, а система платит цену позже.\n\nСпросите, какие просьбы постоянно возвращаются в контрактах, звонках и follow‑up письмах. Если одни и те же исключения повторяются снова и снова, воспринимайте их как сигналы домена, а не шум.\n\nНесколько вопросов обычно быстро проясняют ситуацию:\n\n- Какое обещание помогает вам выигрывать, но потом создаёт работу для команды?\n- Какие кастомные условия или запросы по функциям постоянно появляются в сделках?\n- Где передача в onboarding становится запутанной?\n- Какие возражения звучат как проблема границы продукта?\n\nПовторяющиеся запросы важнее броских enterprise‑фич. Отдельное выставление счетов, кастомные пути одобрения, правила на уровне аккаунта, права для отделов и особые отчёты могут выглядеть как крайние кейсы продаж, но на практике они часто выявляют границу, которую текущая карта скрывает.\n\nОбратите особое внимание на передачу в onboarding. Спросите sales, что они рассказывают на звонках, чего продукт не может объяснить сам. Если onboarding вынужден пересказывать историю иначе, архитектура, вероятно, отражает расплывчатую модель доменов.\n\nВозражения могут быть полезнее побед. Когда покупатели спрашивают: «Может ли один аккаунт клиента содержать несколько независимых команд?» или «Могут ли правила доступа отличаться по регионам?», они, возможно, описывают разделение, которого в системе ещё нет.\n\nНебольшой пример показывает это ясно. Одна SaaS‑команда считала, что продаёт один продукт‑рабочее пространство. Интервью с sales показали два совершенно разных типа сделок: маленькие команды хотели совместную работу, а крупные покупатели требовали жёсткого разделения между отделами. Эта разница изменила onboarding, права доступа и биллинг, поэтому перерисовка началась именно с этого.\n\n## Что спрашивать у ops\n\nOps обычно знает, где бизнес по‑прежнему живёт за счёт патчей и привычек. Если изучать только код, вы пропустите работу, которую люди делают вокруг кода, чтобы заказы шли, отчёты уходили и клиенты получали обновления.\n\nНачните с работы, которая живёт вне системы. Спросите, какие задачи люди всё ещё отслеживают в таблицах, общих заметках или чате потому, что продукт не поддерживает их достаточно хорошо. Эти побочные процедуры часто выявляют отсутствующие состояния, плохие передачи или шаги одобрения, которые так и не попали в карту.\n\nПотом спросите о точке в месяце, которая заставляет всех напрягаться. Конец месяца полезен, потому что слабые места перестают там скрываться. Возможно, финансы ждут один экспорт, ops сверяет итоги вручную, или кто‑то остаётся допоздна, чтобы сверить данные из двух инструментов. Если один шаткий шаг может задержать выставление счётов или отчётность, ваша архитектура должна явно показывать эту зависимость.\n\nПроблемам с данными нужно посвятить отдельные вопросы. Спросите, где данные приходят поздно, неполными или в неправильном формате, и кто это чинит. Например, заказы могут поступать в систему весь день, а файловая выгрузка со склада приходит в 16:00 с битым набором SKU — и один человек очищает файл до отправки. Это не мелкое раздражение. Это часть того, как бизнес работает сейчас.\n\nНаконец, спросите, что люди делают во время инцидентов. Останавливают ли они приём заказов, переходят на почту, ведут ручную очередь или вносят записи позже? Путь отката часто говорит больше, чем счастливый путь. Если ops использует резервный процесс каждые несколько недель, он должен быть на карте доменов.\n\nХорошее discovery не гоняется за теорией. Оно обнаруживает ручные шаги, риск тайминга и ремонтную работу, которые поддерживают бизнес в рабочем состоянии.\n\n## Простой поток интервью\n\nВыберите один реальный запрос, который произошёл недавно. Возьмите то, что прошло через product, support, sales и ops за последние недели. Люди лучше помнят грязные места, когда работа ещё свежа.\n\nПопросите каждую команду рассказать одну и ту же историю от начала до конца отдельно. Держите интервью раздельно. Как только все выйдут на один звонок, они слишком быстро разгладят шероховатости — а именно эти шероховатости вам и нужны.\n\nКогда каждый рассказывает, записывайте три вещи:\n\n- кто касался запроса\n- какое решение принимал каждый человек или команда\n- где работа переходила из рук в руки\n\nЭта простая запись обычно даёт больше, чем отшлифованная диаграмма. Вы заметите скрытые согласования, отсутствующую собственность и шаги, зависящие от tribal knowledge.\n\nОбращайте внимание на названия. Sales может называть нечто «аккаунт», support — «рабочее пространство», а ops отслеживать как tenant или deployment. Когда команды по‑разному называют одно и то же, карта доменов уже начинает дробиться.\n\nДождитесь, пока не услышите все четыре истории, прежде чем менять архитектурную схему. Положите истории рядом и сравните. Если та же путаница повторяется — вы нашли реальную закономерность. Если она всплыла один раз — возможно, это единичная проблема, а не структурная.\n\n## Ошибки, искажающие карту\n\nПлохая карта доменов редко появляется из плохого умысла. Она возникает, когда команда пытается упорядочить работу слишком рано. Одна большая сессия кажется эффективной, но она сглаживает шероховатости. Самые громкие формируют историю, а грязные детали исчезают.\n\nА эти детали имеют наибольшее значение. Support видит возвраты, повторные попытки, ручные обходы, дублированные списания, частичные отказы и кейсы, которые выскакивают за рамки счастливого пути. Если их не учесть, перерисовка всё равно провалится при столкновении с реальной работой.\n\nЕщё одна распространённая ошибка — спрашивать у каждой команды, какие фичи они хотят дальше. Это даст вам список желаний, но не карту. Спрашивайте, что тормозит их каждую неделю, что они чинят вручную, где данные приходят позже и какие шаги вызывают гнев клиентов. Ежедневная боль показывает границы системы лучше, чем идеи по фичам.\n\nИмена команд тоже могут вводить в заблуждение. Sales, support и ops — это группы отчётности, а не домены. Настоящий домен может пересекать несколько команд или находиться внутри узкого рабочего процесса, который никто полностью не владеет. Если вы ставите коробки с названиями отделов, скорее всего вы перерисовываете органиграмму, а не бизнес.\n\nПотоки возвратов — частый пример. Support может обрабатывать тикет, но биллинг двигает деньги, ops проверяет остатки, а product владеет правилами политики. Если всё поместить под support, карта скрывает истинные точки давления.\n\nСледите за предупреждающими знаками:\n\n- один менеджер отвечает за всех;\n- люди описывают согласования вместо бизнес‑событий;\n- исключения отмахиваются как «редкие»;\n- черновик зеркалит текущую органиграмму.\n\nХорошее discovery немного дискомфортно. Люди спорят. Кейсы противоречат друг другу. Кто‑то говорит: «Мы делаем это вручную, потому что система не справляется». Это обычно тот момент, когда карта начинает становиться честной.\n\n## Простой пример\n\nОдна средняя SaaS‑команда планировала перерисовку, потому что «чекаут» постоянно создавал проблемы. На старой диаграмме чекаут был одной коробкой между прайсингом и платёжной системой. Выглядело аккуратно, но скрывало несколько разных задач.\n\nProduct переживал не о картах карт кредитных карт или счётах в первую очередь. Им было важно конверсия trial, тайминг апгрейдов и что происходит, когда пользователь меняет план посреди расчётного периода. Слишком много пользователей запускались, а затем застревали при апгрейде.\n\nSupport видел другую картину. Клиенты создавали дубли аккаунтов, теряли доступ после неудачной смены плана или платили под одной учёткой, а использовали другой логин. Эти тикеты сначала выглядели как биллинговые проблемы, но многие из них начинались с идентичности аккаунта.\n\nSales давила по‑своему. Крупные клиенты хотели кастомные даты выставления счетов, условия контрактов и исключения, не вписывающиеся в дефолтный месячный поток. Команда называла это крайними кейсами. Со временем эти кейсы стали составлять серьёзную долю выручки.\n\nOps уже не терпел старую карту. Экспорты по счетам всё ещё требовали ручных правок до передачи в финансы. Кто‑то патчил битые поля, корректировал соответствие аккаунтов и перезапускал джобы каждый месяц.\n\nПосле отдельных интервью новая карта изменилась быстро. «Чекаут» перестал быть одной коробкой. Команда разделила его на биллинг, идентичность аккаунта и права доступа (entitlements).\n\nЭта перерисовка решила не только диаграмму. Биллинг взял на себя неудачные апгрейды и правила выставления счетов. Identity отвечала за дублирование пользователей и конфликты логинов. Entitlements определяли, кто и что может после каждого изменения плана. Карта наконец соответствовала давлению, которое бизнес ощущал ежедневно.\n\n## Быстрая проверка перед перерисовкой\n\nПерерисовка должна прояснить владение, а не сделать диаграмму красивее. Если по новой карте люди всё ещё спрашивают, кто принимает решения — вы просто переставили коробки.\n\nНачните с владения решениями. Каждый домен должен владеть одним чётким решением, которое не нужно каждый раз утверждать другой команде. Если два домена могут менять правила ценообразования, логику возвратов или статус клиента, границы всё ещё размазаны.\n\nПотом проследите один реальный клиентский кейс через все передачи. Выберите что‑то грязное, а не аккуратный демо‑поток. Апгрейд плана, который ломает биллинг, возврат средств, который требует участия product, или обещание sales, которое ops не может выполнить, покажут, где карта прогибается под давлением.\n\nСлушайте повторяющуюся боль у разных команд. Когда хотя бы две группы описывают одно и то же узкое место разными словами — обратите внимание. Если sales говорит, что кастомные сделки занимают слишком много времени, а support — что исключения накапливаются, они могут указывать на одну и ту же сломанную границу.\n\nХороший набросок должен объяснять и неудобные случаи. Счастливые пути легко рисовать и они почти бесполезны сами по себе. Если карта не показывает, что происходит при отсутствии данных, при смене плана в середине цикла или когда заказ нуждается в ручной проверке — она ещё не готова.\n\nОдин последний тест прост и эффективен. Дайте набросок новичку и попросите объяснить, как один клиентский инцидент проходит через бизнес. Если нужен переводчик для тима‑жаргона, скрытых правил или старых названий систем — упростите.\n\n## Что делать дальше\n\nНачните с одного workflow, а не со всей системы. Выберите что‑то, что часто болит: обработка возвратов, передача лидов или реакция на инциденты. Затем запланируйте четыре отдельных интервью на этой неделе с product, support, sales и ops. Отдельные звонки важны, потому что люди меняют свои истории, когда другие команды находятся в комнате.\n\nПопросите каждого принести реальные материалы, а не только память. Заметки полезны, но скриншоты, последние тикеты, фрагменты чата и сводка потерянной сделки дадут более чистую картину. Если кто‑то говорит: «Это всегда ломается», попросите показать последние два случая.\n\nДержите первый проход простым. Опишите workflow простыми словами, отметьте, где каждая команда входит и выходит, зафиксируйте задержки, обходные пути и отсутствующие данные, и обведите места, где две команды описывают один и тот же шаг по‑разному.\n\nСделайте это до того, как откроете инструмент для диаграмм. Коробки и стрелки выглядят аккуратно слишком рано. Простые формулировки быстрее выявляют расплывчатое мышление, и с предложением в виде предложения легче спорить, чем с отшлифованной схемой.\n\nЗатем протестируйте черновик на трёх реальных событиях: одной потерянной сделке, одном тикете поддержки и одном инциденте ops. Если карта не может объяснить все три — она ещё слишком аккуратная. Хорошая работа с архитектурой должна отражать, где на самом деле накапливаются деньги, время и риск.\n\nИногда полезен внешний взгляд. Oleg Sotnikov на oleg.is занимается такой Fractional CTO‑работой со стартапами и малыми компаниями: он смотрит на границы продукта, инфраструктуру и повседневную реальность за ними. Свежий взгляд может выявить слепые зоны, которые команда начала воспринимать как норму.