Как выйти из операционки, если это не получилось до конца

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

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

Почему это не история успеха

Операционка предпринимателя — это не одна проблема, а связка из разных типов нагрузки: исполнение (сделать звонок, написать текст, проверить сайт), координация (кто что делает и когда) и решения (что вообще делать дальше). Большинство советов про «выход из операционки» говорят про первый тип и молчат про третий.

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

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

Партнёрские модели вместо найма

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

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

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

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

Автоматика снимает рутину, не снимает решения

Автоматика — второй слой, который реально сработал, но не так, как я ожидал вначале.

Весь текущий SEO-конвейер у меня держат агенты Claude и автоматика на launchd и cron — без единого штатного сотрудника. Это правда, и именно об этом мой самый залётный ролик на YouTube — «6 проектов, 0 сотрудников». Но правда и то, что автоматика заменила исполнение, а не мои решения.

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

Грабли: слишком много проектов одновременно

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

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

От ручной проверки к панели контроля

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

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

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

Что я отдал моделям по цене задачи

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

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

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

Что не входит в этот список

Стоит сказать прямо, чего в списке выше нет, чтобы статья не выглядела законченным рецептом.

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

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

Читайте такжеДелегирование в бизнесеВ выдаче по «делегированию в бизнесе» — советы нанять ассистента и делегировать «по матрице Эйзенхауэра». У меня в штате ноль человек: весь SEO-конвейер держат агенты Claude, автоматика и подрядчики на проценте. Расскажу, как я решаю, кому отдать задачу — модели, партнёру или человеку на аутсорсе, — и честно признаю, где без системы делегирование само превращалось в хаос параллельных проектов.