Первая архитектурная встреча: что должны принести основатели

Почему первая встреча буксует

Первая архитектурная встреча обычно буксует по простой причине: люди начинают обсуждать инструменты раньше, чем работу. Кто-то спрашивает: «Стоит ли нам использовать React, Python или AI-агента?» Звучит практично, но это обходной путь от более сложного вопроса. Что продукт должен сделать для реального клиента в реальный день?

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

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

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

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

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

Принесите пользовательский сценарий, а не список функций

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

Пользовательский сценарий говорит.

Он показывает путь от реальной проблемы к реальному результату.

Начните с первого момента, когда пользователь ощущает боль. Возможно, менеджер по продажам не видит, каким лидам нужно внимание. Или клиент ждет отчет два дня, хотя это должно занимать 10 минут. Этот момент важнее длинного списка желаний, потому что он объясняет, зачем вообще существует продукт.

Потом опишите шаги от регистрации до первого полезного результата простыми словами. Кто начинает? Что он вводит? Что должен увидеть дальше? Где он остановится, если чего-то не хватает?

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

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

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

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

Запишите ограничения на бумаге

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

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

Достаточно короткой заметки:

• Бюджет: $30k–$50k на первую версию
• Запуск: до сентябрьского sales event
• Команда: один основатель, один подрядчик, без найма ops пока
• Уже используемые системы: нужно работать с CRM и платежным провайдером, которые уже в ходу

Это быстро меняет разговор. Небольшая команда с коротким сроком не должна планировать такую же систему, как финансируемая компания с шестью инженерами и годом на разработку.

Раннее обозначайте и внешние ограничения. Если сделка с клиентом зависит от SSO, согласования у вендора, синхронизации с Salesforce или хранения данных в одном регионе, скажите об этом до того, как кто-то начнет спорить о вариантах дизайна. То же самое касается правил конфиденциальности, audit logs, условий договора или регулируемых данных. Даже неполная заметка уже помогает. Люди задают лучшие вопросы, когда понимают границы.

Держите фиксированные ограничения отдельно от пожеланий. «Нужно запуститься за восемь недель» — это фиксированное ограничение. «Нативные мобильные приложения в первый день было бы здорово» — это пожелание.

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

Назовите риски, связанные со сделками и запуском

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

Принесите короткий список обещаний, которые уже были даны, даже если неофициально. «В первой фазе поддержим SSO» или «ваша команда будет получать еженедельные отчеты по комплаенсу» — такие формулировки могут изменить объем, сроки и стоимость.

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

Помогает короткий чек-лист:

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

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

Также четко обозначайте, какие запросы действительно блокируют сделку. Есть большая разница между «можно сделать потом» и «покупатель не подпишет без этого». Если пилот зависит от работ по SOC 2, если закупке нужны логи или если enterprise-клиенту нужна поддержка по выходным во время запуска, команда должна услышать это заранее.

Скажите, чего вы еще не знаете

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

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

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

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

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

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

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

Подготовьтесь за 30 минут

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

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

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

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

В разделе вопросов добавьте неизвестные, на которые вы пока не можете ответить. «Мы не знаем, нужен ли пользователям mobile first» — это полезно. Делать вид, что вы знаете, обычно тратит больше времени, чем честно сказать, что не знаете.

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

Простых 30 минут обычно достаточно: 10 минут заполнить страницу, 10 минут убрать расплывчатые пункты и 10 минут расставить приоритеты.

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

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

Простой пример стартапа с продажами

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

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

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

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

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

Ошибки, которые зря тратят встречу

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

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

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

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

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

И, наконец, разговоры об инструментах. Спор о React против Next.js, monolith против microservices или о том, какую AI-модель использовать, может звучать серьезно. Но это все еще неправильный порядок. Такие решения имеют смысл только после того, как команда сначала поймет бизнес-давление.

Что делать сразу после встречи

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

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

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

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

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

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