Почему стартапу нужен архитектор, а не только разработчики

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

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

Разработчики строят. Архитектор решает, что строить и как это сложится вместе

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

Архитектор работает на уровень выше. Он отвечает за вопросы, которые ни один тикет не задаёт:

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

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

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

Четыре сценария сбоя, которые выглядят как баги, а на деле — архитектура

Если вы сталкивались с чем-то из этого, вы уже видели проблему архитектуры в костюме проблемы кода.

1. MVP работал, но теперь падает под нагрузкой

Срезы углов, которые довели вас до запуска — одна база на всё, синхронные вызовы там, где нужна очередь, отсутствие разделения чтения и записи, — это ровно те срезы, что превращаются в простои на масштабе. То, что довело до product-market fit, не проведёт вас через него. Кто-то должен спроектировать второй акт до того, как вы в нём окажетесь.

2. Вы сожгли бюджет на разработчиков, которые не видели доску целиком

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

3. Команда выпускает фичи, но за архитектуру никто не отвечает

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

4. Вам нужен ум уровня CTO, но не зарплата уровня CTO

Штатный CTO в США стоит $200K+ в год плюс доля. Большинству продуктов на ранней стадии не нужен фултайм-руководитель — им нужна senior-экспертиза в архитектуре, приложенная в правильные моменты. Путаница между этими двумя вещами — причина, по которой стартапы либо переплачивают за титул, либо, чаще, вообще пропускают экспертизу.

Что архитектор на самом деле делает — до первой строки кода

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

Требования → ограничения. Превращение «мы хотим, чтобы пользователь делал X» в реальные технические ограничения — объём данных, задержки, комплаенс, интеграции, — которые и определяют дизайн.
Дизайн системы. Сервисы, их границы, как они общаются и где живёт состояние. Карта до территории.
Модель данных, о которой не пожалеете. Самое трудноизменяемое решение, принятое осознанно, а не по умолчанию.
План последовательности. Что строить первым, чтобы ранние решения не загнали в угол поздние.

Результат — не диаграмма, которая пылится в углу. Это Architecture Blueprint — то, что позволяет команде строить быстро именно потому, что дорогие вопросы уже решены. Ровно это и производит Discovery-спринт.

Правило большого пальца

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

«Нам ещё рано для архитектора» — самый дорогой миф

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

Не нужен тяжёлый процесс или большая команда. Нужно немного senior-суждения в начале — несколько дней, которые формируют следующие несколько лет. Пропуск не убирает работу над архитектурой; он лишь переносит её на худшее время по максимальной цене. (Конкретные цифры этого размена — в статье «Настоящая цена пропущенного этапа Discovery».)

Когда подключать ответственность за архитектуру

Скорее всего, она нужна вам раньше, чем кажется, если верно хоть что-то из этого:

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

Хорошая новость: фултайм-CTO вам не нужен

Ложный выбор — «нанять дорогого штатного технического руководителя» или «надеяться, что разработчики разберутся». Есть третий вариант, который подходит большинству продуктов на ранней стадии: fractional-архитектор — ответственность уровня CTO на part-time, в те моменты, когда это важно.

Ведущий архитектор задаёт дизайн системы, осознанно принимает необратимые решения, ревьюит работу и менторит команду — без стоимости фултайм-руководителя и без слепых зон «фабрики фич». Именно по этой модели работает Reacto: за каждый проект отвечает архитектор, а делает небольшая, тщательно подобранная senior-команда. Как это ложится на конкретные форматы — на странице услуг.

Как начать, не ставя на кон компанию

Чтобы получить пользу, не нужно сразу соглашаться на полную разработку. Самый малорисковый первый шаг — Discovery-спринт с фиксированным объёмом: одна-две недели, фиксированная цена и конкретный результат — Architecture Blueprint и дорожная карта в вашей полной собственности, продолжите вы с нами или отдадите любой другой команде.

В этом весь смысл разработки под руководством архитектора: дорогие вопросы решаются, пока их ещё дёшево решать. Разработчики построят вам продукт. Архитектор следит за тем, чтобы этот продукт стоило строить — тот, что масштабируется, а не тот, что вы потом переписываете.

Частые вопросы

Разве архитектор — это не просто senior-разработчик?

Пересечение есть, но ответственность разная. Senior-разработчик отвечает за то, чтобы хорошо построить фичу. Архитектор отвечает за форму системы — границы, модель данных, компромиссы между фичами — и за решения, которые дорого разворачивать. Можно быть отличным разработчиком и никогда не делать эту работу.

Разве нельзя просто отрефакторить потом?

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

Мы нетехнические основатели. Как нам это вообще оценивать?

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