Проблемы архитектуры стартапа или реальная нехватка людей?

Как выглядит эта проблема в реальных командах

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

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

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

Ещё один сигнал — разъезд терминов. Продукт говорит «account», инженерная команда — «workspace», sales — «customer», а support — «company». Все думают, что имеют в виду одно и то же. Это не так. Как только расходятся слова, расходятся и решения. Спор звучит технически, но на самом деле он о смысле.

Это хорошо слышно на релизных встречах в растущих стартапах. Кто-то спрашивает, относится ли изменение к onboarding, payments или admin settings. Отвечают сразу три человека. И ни один не звучит полностью неправильно. Вот так и выглядят размытые границы доменов, пока их ещё никто не назвал.

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

Почему ещё один senior hire может не помочь

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

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

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

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

Расходы на зарплату растут с первого дня. А скорость поставки — обычно нет.

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

Частый сценарий выглядит так: Team A меняет общий сервис, не предупредив Team B, тестирование начинается поздно, даты релиза сдвигаются, баги перелетают между командами, и новый senior engineer становится автоматическим владельцем всех сложных проблем. В какой-то момент этот человек действительно помогает. А потом сам превращается в узкое место.

Именно поэтому короткая проверка архитектуры и ответственности может сэкономить деньги ещё до открытия вакансии. Если у команды уже достаточно навыков, но слабые границы, новый senior hire просто делает оргструктуру красивее. А поставку — нет.

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

Как отделить проблемы людей от проблем системы

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

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

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

Проблемы системы ведут себя иначе. Они проявляются на каждой передаче работы. Продукт передаёт задачу в инженерную команду с пробелами. Backend ждёт frontend, потому что правила API сформулированы расплывчато. QA на каждом релизе находит один и тот же класс багов. Никто не может сказать, кто отвечает за billing flow от начала до конца. Это указывает на ответственность, процесс релиза или дизайн домена.

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

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

Найм всё ещё важен, но он должен идти после этой проверки, а не до неё. Новый senior engineer поможет, если команде не хватает опыта или руководства. Он не исправит размытые домены, неясную ответственность или релизный процесс, который тормозит всех. В таких случаях первая проблема — это дизайн.

Сначала разметьте ответственность, потом меняйте штат

Беспорядок в оргструктуре часто прячется внутри продукта. Прежде чем нанимать ещё одного senior engineer, нарисуйте простую карту того, что команда уже контролирует.

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

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

После этого отметьте места, где работа пересекает границы команд. Общие сервисы, этапы согласования, security review, изменения в базе данных и контрольные точки релиза — всё это должно быть на карте. Трение на релизах обычно живёт именно там, а не в редакторе кода.

Несколько вопросов быстро показывают, где беспорядок. Какие области требуют согласования от кого-то вне команды? Какие тикеты висят в ревью по несколько дней? Где одна и та же задача прыгает между двумя людьми? У какого сервиса два владельца с разными приоритетами?

Обычно вы найдёте пересечения. Одна команда считает, что владеет API, другая — что владеет business logic, а support думает, что engineering отвечает за весь инцидент целиком. Когда ломается checkout, все подключаются к звонку, но никто не принимает решение о фиксе.

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

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

Сократите трение на релизах по шагам

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

Начните с одной реальной фичи, а не с теории. Возьмите что-то небольшое, например изменение в trial signup или новое правило биллинга. Проследите путь этой задачи от первого запроса в чате или тикете через дизайн, код, ревью, тестирование, деплой и поддержку.

Запишите путь простым языком и посчитайте моменты, где работа останавливается. Ищите согласования от founder, product или security, переходы между ветками и очереди на merge, ручные QA-проверки, которые повторяются на каждом релизе, и шаги деплоя, которые умеет запускать только один человек.

Это упражнение скучное — и именно поэтому оно работает. Вы перестаёте спорить о том, нужен ли ещё один senior engineer, и смотрите, куда реально уходит время.

Потом уберите шаги, которые создают задержку, но почти не добавляют контроля. Если две проверки идут на каждое маленькое изменение, попробуйте оставить одного ревьюера для низкорисковых обновлений. Если QA каждую неделю вручную прогоняет один и тот же smoke test, сначала автоматизируйте именно эту узкую проверку. Если релизы ждут founder, который только мельком на них смотрит, уберите это согласование и вместо него опишите план отката.

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

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

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

Простой пример из растущего стартапа

У основателя SaaS было три поздних запуска подряд, и он принял обычное решение: нанять senior backend lead. На бумаге это выглядело разумно. Команда выпускала медленно, баги просачивались в продакшен, и никто не хотел трогать billing перед релизом.

Новый lead первую неделю разбирался, как изменение цены проходит через компанию. Именно там и всплыла настоящая проблема. Три команды меняли одни и те же billing rules.

Product менял логику тарифов в приложении. Backend-команда обновляла расчёты инвойсов. Operations редактировали исключения для enterprise-клиентов. У каждой группы была своя причина, но ни одна команда не владела billing domain от начала до конца.

Из-за этого трение на релизах выросло очень быстро. Небольшое изменение цены требовало нескольких согласований, дополнительного QA, ручных проверок и срочных исправлений, потому что одна команда не знала, что поменяла другая. Основатель думал, что стеку нужен более сильный senior talent. Lead увидел проблему ответственности.

На месяц они поставили найм на паузу и сначала поправили границы. Одна команда получила полную ответственность за billing. Правила ценообразования перенесли в один источник истины. Шагов релиза стало меньше: длинный чеклист заменили коротким повторяемым потоком. Краевые случаи перестали жить в сообщениях Slack и их стали записывать.

Ничего магического за ночь не произошло. Первые два релиза всё ещё проходили напряжённо. К третьему команда перестала каждый спринт заново открывать те же споры о billing. Одни и те же логики трогало меньше людей, ревью стали короче, а QA знал, куда смотреть.

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

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

Частые ошибки основателей

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

Ещё одна ошибка — ловушка титула. Основатель нанимает Head of Engineering или Staff Engineer и считает, что титул сам создаёт власть. Это не так. Если product по-прежнему звонят сразу несколько founders, изменения в infra всё ещё нужно утверждать у кого-то другого, а финальное слово по границам сервисов никому не принадлежит, новый человек неделями не исправляет систему, а договаривается.

Общие модули создают более тихий беспорядок. Команды складывают billing, auth или design components в общий bucket, потом все к ним прикасаются, и никто их не защищает. Одна команда меняет общий сервис, чтобы выпустить быстрее, другая обходит его побочные эффекты, и риск релиза распространяется по всему продукту. Когда модуль влияет на многие части бизнеса, за него должен отвечать один человек или одна маленькая команда, даже если остальные тоже участвуют.

Одни и те же ошибки всплывают снова и снова:

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

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

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

Что проверить перед тем, как открывать ещё одну роль

Новый senior engineer может помочь, когда команде правда не хватает навыков или времени. Но многие проблемы стартапа начинаются с путаницы, а не с нехватки людей. Если никто не может объяснить одной чёткой фразой, кто отвечает за billing, onboarding, analytics или другую продуктовую область, команде пока не нужен более крупный org chart.

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

Короткая проверка скажет очень многое:

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

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

Сторонний взгляд может сэкономить месяцы. Fractional CTO может посмотреть на карту продукта, путь поставки и историю инцидентов и сказать, у вас нехватка людей или проблема в дизайне. Такой ответ обычно быстрее и честнее, чем публиковать расплывчатую senior-роль и надеяться, что следующий человек распутает всё сам.

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

Большинству этих проблем не нужен новый оргчарт или ещё один senior hire прямо сейчас. Им нужна одна неделя ясных решений.

Выберите домен, который сейчас создаёт больше всего боли. Это может быть billing, onboarding, reporting или deployment. Назначьте одного человека ответственным за эту область и заставьте команду проговорить это вслух.

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

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

Практическая перезагрузка проста:

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

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

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