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

Почему новый раунд финансирования часто ведет к плохому найму

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

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

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

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

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

Вот почему после масштабного найма отдача часто едва двигается. Фонд оплаты растёт, но команда тратит больше времени на объяснения работы, чем на её выполнение. На какое‑то время доставка даже может ухудшиться.

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

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

Найдите узкое место прежде, чем писать вакансии

Начинайте с доказательств, а не с названий ролей. После раунда основатели часто прыгают сразу к "нам нужен senior engineer" или "нам нужен продукт". Это звучит решительно, но пропускает более трудный вопрос: где на самом деле замедляется работа?

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

Большинство задержек проявляется в нескольких предсказуемых местах:

• принятие решений по объёму работ
• код‑ревью или QA
• дизайн или техническое направление
• одобрение у одного занятого основателя

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

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

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

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

Отобразите путь работы от идеи до релиза

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

Большинство команд смотрит сначала на кодирование и на этом останавливается. Это упускает медленные части. Фичу можно собрать за три дня, и она всё равно пролежит две недели, потому что никто не утвердил объём, макеты менялись дважды или QA нашёл ту же проблему в трёх раундах.

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

Что включать

Запишите стадии в порядке, в котором идёт работа: запрос, объём, дизайн, разработка, QA и релиз. Для каждой стадии отметьте два числа: сколько времени занимает сама работа и сколько времени она ждёт, прежде чем кто‑то её возьмёт. Время ожидания часто вредит сильнее, чем рабочее время. Задаче может понадобиться четыре часа дизайнера, но если она лежит в очереди шесть дней, это и есть настоящая задержка.

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

Небольшой пример делает это очевидным. Допустим, стартап хочет выпустить новый onboarding после seed‑раунда. Продукт пишет бриф за день. Дизайн ждёт пять дней, прежде чем начать. Инженерия собирает за четыре дня. QA тестирует за день, но отправляет обратно дважды, потому что краевые случаи не были описаны. Маркетинг ждёт финальный текст для запуска. Кодинг не блокировал релиз. Блокировали разрывы между командами.

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

Выберите первую роль простым методом

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

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

Затем задайте строгий вопрос: может ли один человек убрать эту задержку или хотя бы сократить её вдвое за 90 дней? Если ответ «нет», возможно, проблема в планировании, ответственности или процессе, а не в численности.

Простой фильтр помогает:

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

Scorecard сохраняет план честным. Дайте роли несколько конкретных результатов и один бизнес‑результат. Например, старший контрактор по автоматизации QA может построить smoke‑тесты для пути релиза, сократить ручное регрессионное тестирование с двух дней до четырёх часов и помочь команде выпускаться еженедельно вместо раз в две недели. Это гораздо лучше, чем писать «улучшить качество» в вакансии.

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

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

Соотнесите роли с узким местом, а не с орг‑схемой

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

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

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

Когда качество — реальный блокер

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

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

Когда релиз зависит от одного человека

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

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

Простой пример после seed‑раунда

Стартап закрывает seed‑раунд и чувствует давление быстро нанимать. В команде уже есть пара инженеров, поэтому основатели думают: добавим ещё троих и будем быстрее. Звучит разумно, но обычно только усугубляет беспорядок.

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

Именно поэтому план найма после раунда должен начинаться с самого медленного хэнд‑оффа, а не с самой громкой просьбы.

В этом случае первый найм должен пойти в сторону доставки или продуктовой ответственности. Надёжный product owner, delivery‑лид или project manager может превратить идеи основателей в ясные тикеты, решать мелкие вопросы заранее и защитить команду от постоянного переключения контекста. Один такой найм убирает задержку почти у каждой фичи.

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

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

Тогда и имеет смысл второй найм: человек, который возьмёт на себя релизы и инфраструктуру. В зависимости от компании это может быть DevOps‑инженер, platform‑engineer или сильный generalist, который возьмёт на себя деплой, мониторинг, инцидентный ответ и базовую надёжность.

Проверить, сработало ли это, можно по нескольким простым признакам:

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

Если эти показатели не изменились через 30–45 дней, роль была неверна или команде не дали новой персоне полномочий.

Установите бюджет, сроки и доказательства, что найм сработал

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

Поставьте сроки на результат до открытия вакансии. У каждого найма должны быть результаты на 30, 60 и 90 дней, которые команда сможет проверить без долгих споров. На 30‑й день человек должен владеть понятной частью работы. На 60‑й — одно узкое место должно заметно ослабеть. На 90‑й — команда должна реже пропускать сроки или выпускать с меньшим количеством доработок.

Три метрики обычно говорят, помог ли найм:

• цикл от утверждённой задачи до релиза
• размер и возраст бэклога багов
• пропущенные сроки за последний месяц или квартал

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

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

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

Малому стартапу может не понадобиться инженер‑менеджер или staff‑engineer прямо сейчас. Ему может понадобиться кто‑то, кто задаст правила доставки, подрежет бэклог и определит успех перед следующим наймом. Это часто дешевле и даёт команде лучшее доказательство, чем найм «на авось».

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

Ошибки, которые превращают план найма в мечты

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

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

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

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

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

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

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

Проверки перед открытием следующей вакансии

Команда часто знает, что ей нужна помощь, прежде чем поймёт какого рода. Этот разрыв ведёт к слабому найму. Если вы не можете описать текущую задержку в одном предложении, остановитесь. «Релизы ждут QA три дня» — полезно. «Нам нужна дополнительная senior‑сила» — нет.

Затем честно проверьте последний найм. Убрал ли этот человек очередь или создал новую передачу? Новый менеджер или координатор может сделать всех занятыми, если никто не владеет результатом end‑to‑end. Ещё одна встреча в неделю кажется мелочью, но пять человек в ней могут съесть половину рабочего дня.

Перед открытием роли проверьте пять вещей:

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

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

Хорошие метрики обычно скучны. Time to merge, время до релиза, escaped defects и часы блокировок скажут вам больше, чем количество тикетов или активность в чате. План найма после раунда должен читаться как чек‑лист исправлений. Каждая роль должна убирать названную точку ожидания и оставлять команду с меньшей координацией, а не с большей.

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

План найма после раунда должен выглядеть как операционный план, а не список желаемых позиций. Возьмите карту узких мест, которую вы уже собрали, и превратите её в порядок найма на 6–12 месяцев. Привяжите каждую роль к одному заблокированному исходу: медленные релизы, слабое покрытие QA, архитектура, зависящая только от основателя, нагрузка саппорта или длительное время настройки новых клиентов.

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

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

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

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

Если хотите внешнюю проверку, Oleg Sotnikov на oleg.is работает как Fractional CTO и советник стартапов по планам найма, архитектуре продукта, инфраструктуре и рабочим процессам с упором на AI‑first. Ценность такого обзора проста: вы получаете порядок найма, привязанный к реальным узким местам, а не к догадкам.

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