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

Почему одни и те же споры возвращаются

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

То же самое происходит с мелкими выборами. Где должна жить валидация? Останутся ли эти данные в Postgres? Можно ли деплоить в пятницу? Если никто не записал дефолт, каждое новое тикет может заново открыть старый спор.

Цена обычно проявляется во времени сеньоров. Фаундер, CTO или старший инженер тратит 20 минут в Slack, затем ещё 30 в созвоне, потом ревьюит пулл‑реквест, сформированный полузабытой решением с прошлого месяца. Этот час не появляется в дорожной карте, но всё равно замедляет доставку.

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

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

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

Типичный паттерн выглядит так:

• Команда делает платежи внутри основного приложения.
• Через месяц кто‑то предлагает отдельный billing‑сервис.
• Позже ещё одна фича снова идёт в основное приложение.
• Команда заново спорит о границах сервисов.

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

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

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

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

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

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

Предостерегающие признаки обычно очевидны:

• Похожие сервисы строятся по‑разному.
• Новые сотрудники постоянно задают одни и те же вопросы о настройке.
• Дни релизов отличаются для разных проектов.
• Старшие инженеры каждую неделю решают одни и те же споры.

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

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

Что включить в короткую страницу принципов

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

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

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

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

Держите правило конкретным

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

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

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

Как написать первую версию

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

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

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

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

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

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

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

Перед публикацией просмотрите страницу с теми, кто строит и шипит. Задайте один прямой вопрос: «Закрыло бы это правило последний спор быстрее?» Если нет — перепишите правило, пока бы не закрыло.

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

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

Слой данных запускает тот же цикл. В приложении уже хранится users, billing и состояние продукта в PostgreSQL. Потом приходит фича, и кто‑то просит MongoDB, потому что полезная нагрузка кажется менее структурированной. Никто не может объяснить, какую проблему SQL не решает, но спор продолжается. Если добавить вторую базу, появятся дополнительные бэкапы, мониторинг и точки отказа.

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

В такой ситуации главная проблема не в таланте. Команде не хватает небольшого набора дефолтов.

Короткая страница правил могла бы сказать:

• Держите один код и одно деплой‑приложение, пока нагрузка, безопасность или владение командой не дадут явную причину разделиться.
• Используйте PostgreSQL по умолчанию для продуктовых данных. Добавляйте другую БД только после того, как команда задокументирует пределы, которые SQL не покрывает.
• Шипьте каждый релиз через один общий пайплайн. Если шаг важен, автоматизируйте его.
• Выбирайте инструменты, которые любой инженер в команде сможет запустить, отладить и откатить.

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

Как применять правила в повседневной работе

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

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

Используйте страницу в нескольких фиксированных моментах:

• при груминге бэклога, пока ещё можно поменять объём;
• на дизайн‑ревью, до утверждения работы;
• на старте тикета, до начала кода;
• после релиза, если исключение должно стать новым дефолтом.

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

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

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

Ошибки, которые делают принципы бесполезными

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

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

Расплывчатые формулировки тоже вредны. «Используйте лучший инструмент» звучит умно, но ничего не решает. Один прочитает это как «выбери самое быстрое», другой — «выбери самый новый стек», третий — «используй то, с чем он работал на прошлой работе».

Хорошее правило обычно содержит три части:

• дефолтный выбор;
• причина этого выбора;
• кто утверждает исключение.

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

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

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

Быстрая проверка перед публикацией

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

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

Перед публикацией проверьте пять вещей:

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

Проще всего протестировать страницу, проиграв несколько недавних решений. Может быть, команда спорила о добавлении Redis, заранее разделила сервис на три части или внесла стейдж‑шаг, который замедлил каждый релиз. Спросите прямо: решила бы эта страница тот спор за пять минут? Если нет — ужесточите правило или уберите его.

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

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

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

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

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

Простой первый план:

• Выберите повторяющиеся споры, которые появляются в планировании, ревью и после инцидентов.
• Напишите 5–10 правил простым языком.
• Под каждым правилом добавьте одну строку, когда имеет смысл исключение.
• Тестируйте страницу месяц в реальных решениях.
• Быстро переписывайте строки, которые люди читают по‑разному.

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

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

Некоторым командам полезен внешний взгляд, чтобы сделать это правильно. Oleg Sotnikov на oleg.is работает со стартапами как фракционный CTO и советник, помогая превращать расплывчатые предпочтения в практические правила по архитектуре, доставке и разработке с участием AI. Такая помощь особенно полезна, когда правила остаются короткими, протестированными и привязанными к тем компромиссам, с которыми ваш стартап сталкивается прямо сейчас.