Стартап, завязанный на основателе: спланируйте передачу до выгорания

Когда на основателе слишком много

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

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

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

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

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

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

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

Что нужно обозначить владельцем в первую очередь

Начните с обычной инвентаризации. Большинство команд под руководством основателя знают главное приложение, но забывают тихие части, которые держат его на плаву: cron-задачу на старом сервере, репозиторий с webhook'ом биллинга, скрипт, который чинит сломанные импорты, staging-базу, аккаунт DNS, дашборд ошибок.

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

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

Короткая таблица обычно быстро показывает проблему:

• Что это за актив?
• Кто сейчас ревьюит изменения?
• Кто сейчас отвечает на продуктовые вопросы?
• Кто может деплоить или откатывать?
• Кто может читать данные продакшена?

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

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

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

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

Разделяйте права на решения осознанно

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

Разделите решения на понятные категории. Продуктовые решения отвечают на вопрос: «Стоит ли делать это сейчас?» Архитектурные решения отвечают: «Какой подход подходит системе?» Решения по релизу отвечают: «Безопасно ли выпускать это сегодня?» Один человек может какое-то время закрывать несколько категорий, но команда должна понимать, какую именно роль он сейчас выполняет.

Практичное разделение выглядит так:

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

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

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

Запишите, где проходит граница между «спросить» и «действовать». Формулируйте просто. Спрашивать нужно перед изменениями схемы, изменениями аутентификации, обязательствами перед вендорами и всем, что может вызвать простой у клиентов. Действовать без согласования можно при правках текста, покрытии тестами, очистке логов и низкорисковых багфикcах.

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

Ужесточите доступ к продакшену, не замедляя работу

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

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

Маленькой команде не нужен тяжёлый регламент на много страниц. Ей нужна понятная карта того, кто может деплоить, кто может смотреть, и кто может менять живые данные.

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

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

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

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

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

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

План передачи на четыре недели

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

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

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

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

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

В конце каждой недели ведите короткий список пробелов:

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

Если это работает, основатель перестаёт быть системой. В этом и есть смысл.

Небольшой пример SaaS-команды

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

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

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

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

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

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

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

Где AI помогает, а где — нет

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

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

Обычно полезные сценарии AI узкие и легко проверяемые:

• подготовка unit- и integration-тестов на основе существующего кода
• написание инструкции по настройке, runbook'ов и типовых исправлений
• превращение истории коммитов в заметки по миграции
• поиск рискованных изменений во время code review
• предложение шагов отката перед деплоем

Это экономит усилия. Но это не решает проблему владения.

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

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

Плохое использование AI быстро создаёт путаницу. Не мержите код только потому, что AI-review выглядел хорошо. Не заменяйте реальные runbook'и документами, сгенерированными AI. Не просите AI решать, кто должен утверждать изменения. И не считайте вывод AI доказательством того, что рискованный деплой безопасен.

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

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

Ошибки, которые ломают передачу

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

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

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

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

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

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

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

Быстрая проверка перед тем, как отступить

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

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

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

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

Полезна короткая карточка оценки:

• У каждого сервиса есть один владелец и один запасной.
• Кто-то кроме основателя может выпустить обычную правку.
• Команда может простыми словами объяснить влияние на клиентов.
• Один человек может безопасно откатить релиз менее чем за 10 минут.
• Срочные пинги основателю снижаются от недели к неделе.

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

Если вам нужен нейтральный человек, чтобы всё это разобрать, Олег Сотников на oleg.is делает такой Fractional CTO-формат работы с небольшими командами, которым нужно более чёткое владение, более строгий доступ к продакшену и практичные привычки разработки с поддержкой AI. Иногда взгляд со стороны помогает команде за несколько сессий исправить то, что она откладывала месяцами.

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

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

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

Первый чеклист держите коротким:

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

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

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

Если один и тот же человек по-прежнему отвечает на каждый срочный тред, пока не отходите в сторону. Сначала завершите передачу.