План спасения стартапа: сокращайте проекты до найма

Почему команды чувствуют перегрузку ещё до роста

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

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

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

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

И тогда найм начинает казаться вежливым вариантом. Сказать «нам нужны ещё два инженера» проще, чем объяснить основателю, руководителю продукта или отделу продаж, что часть работы придётся остановить. Штат выглядит обнадёживающе. Сокращать проекты — неудобно.

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

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

Почему найм первым делом часто ухудшает хаос

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

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

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

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

Старая схема возвращается быстро:

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

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

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

Как выглядит triage CTO простыми словами

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

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

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

Часто перегрузка возникает из работы, которая звучит полезно, но на деле не имеет формы. Обычно это видно по знакомым признакам:

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

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

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

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

Как провести triage-сессию шаг за шагом

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

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

1. Внесите в один список все активные задачи. Добавьте продуктовую работу, исправления багов, обещания партнёрам, внутреннюю уборку, задачи по соответствию требованиям и регулярные встречи. Многие команды забывают о мелких еженедельных обязанностях, а потом удивляются, почему ни на что не хватает времени.

2. Напишите по одному простому предложению о результате каждой задачи. Не о действии, а о результате. «Запустить self-serve billing, чтобы клиенты могли обновлять тариф без помощи» — понятно. «Поработать над billing» — слишком размыто и бесполезно.

3. Оцените каждую задачу по трём простым шкалам: срочность, бизнес-ценность и трудоёмкость. Не усложняйте оценку. Шкала от 1 до 3 работает лучше, чем длинный спор, потому что цель — не идеальная математика, а сортировка.

4. Посмотрите на доступную мощность команды на следующие 6–8 недель и жёстко сократите список. Если команда не может завершить задачу в этот срок, поставьте её на паузу. Не оставляйте её в статусе «в работе» только потому, что кто-то попросил о ней в прошлом месяце.

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

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

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

Как решить, что оставить, а что поставить на паузу

У большинства перегруженных команд сначала не проблема с людьми, а проблема с сортировкой. План спасения стартапа начинается, когда вы перестаёте спрашивать: «Можно ли это втиснуть?» — и начинаете спрашивать: «Что будет, если мы 30 дней вообще ничего с этим не сделаем?»

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

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

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

Простой тест для triage CTO работает хорошо:

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

Если ответы слабые, убирайте задачу из активной очереди. Не оставляйте её в туманной папке «может быть потом». Перенесите её в список на потом с датой пересмотра — обычно через две–шесть недель — и назначьте человека, который вернётся к ней. Этот маленький шаг важен: он не даёт идеям просачиваться обратно через разговоры в коридоре.

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

Пример: один стартап сократил очередь и освободил время

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

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

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

Команда оставила работу, связанную с выручкой и оттоком:

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

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

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

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

Ошибки, из-за которых команды остаются перегруженными

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

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

Ещё одна ловушка — назвать что-то «на паузе» и при этом продолжать тратить на это время. Если команда всё ещё чинит мелкие баги, ходит на статусные звонки, обновляет документы или отвечает в Slack, эта работа не на паузе. Это активная работа под более мягким названием.

Некоторые паттерны повторяются снова и снова:

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

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

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

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

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

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

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

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

• Попросите каждого руководителя самостоятельно записать три главных приоритета по порядку. Если списки не совпадают, проблема пока не в найме. Проблема в фокусе.
• Проверьте, действительно ли приостановленная работа остановлена. Посмотрите на календари, чаты, тикеты и регулярные встречи. Если о ней всё ещё говорят, отчитываются по ней или держат тикеты тёплыми, она не на паузе.
• Измерьте cycle time после того, как команда сократила активную работу. Если задачи идут быстрее и меньше пунктов застревает, сокращение высвободило мощность. Если скорость не изменилась, ищите другое узкое место до найма.
• Привяжите каждого планируемого сотрудника к конкретному ограничению. Возможно, один инженер блокирует все релизы, или один product lead утверждает каждое решение. «Нам нужны ещё руки» — слишком размыто.
• Если можете, подождите 30 дней. Потом посмотрите на объём выпущенной работы, бэклог багов, скорость ответа или ещё один простой показатель результата. Месяц данных лучше, чем поспешная публикация вакансии.

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

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

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

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

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

Заблокируйте полдня на этой неделе и соберите в одной комнате основателей и тимлидов. Используйте это время, чтобы очистить очередь, а не спорить о новых идеях.

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

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

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

К концу этих двух недель вы должны увидеть реальные сигналы. Cycle time должен сократиться. В review должно зависать меньше задач. Руководители должны тратить меньше времени на жонглирование и больше — на принятие решений. Если ничего не меняется, проблема глубже, чем просто нагрузка. Это может быть вопрос ответственности, архитектуры или привычек доставки.

Вот тогда и начинает приносить пользу внешний взгляд. Oleg Sotnikov работает как fractional CTO для стартапов и помогает основателям разбираться с delivery, scope продукта, инфраструктурой и AI-assisted development, не раздувая штат слишком рано. Если после triage команда всё ещё кажется застрявшей, попросите практический разбор и план, который можно использовать уже на следующей неделе.