Риск зависимости от одного основателя: план перехода для акселераторов

Где появляется узкое место

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

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

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

Обычно признаки довольно очевидны:

• Большинство merges приходит от одного человека.
• Инженеры постоянно просят доступы или помощь с деплоем.
• Pull request ждут, пока накапливается новая работа.
• Один и тот же человек отвечает за ревью, доступ к инфраструктуре и утверждение релиза.
• В обсуждениях поставки всё время звучит: «нужно, чтобы это проверил основатель».

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

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

Что проверить в первую неделю

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

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

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

Доступы обычно устроены беспорядочнее, чем команды готовы признать. Проверьте production access, CI/CD, billing accounts, DNS, cloud consoles и secrets. Если только у основателя есть права на деплой или только он может оплатить cloud-счёт, отметьте это сразу.

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

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

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

Разделите ответственность на понятные зоны

Когда один основатель всё ещё касается каждого репозитория, передача срывается, потому что никто не понимает, где начинается и заканчивается его зона ответственности. Большая реорганизация не нужна. Разделите продукт на небольшие области, которые можно назвать в одном предложении: signup, billing, mobile app, внутренний admin, импорт данных.

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

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

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

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

Карта ответственности должна отвечать на четыре вопроса:

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

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

Простой пример помогает. Основатель оставляет за собой billing и subscriptions. Другой инженер берёт user onboarding. Этот инженер пишет изменения, открывает pull request, деплоит в обычные рабочие часы и отвечает на первое обращение в поддержку, если onboarding ломается. Первые пару недель основатель проверяет только более рискованные изменения. Потом он отходит в сторону.

Для акселератора проверка здесь простая: попросите назвать зоны и пару владельцев для каждой. Если компания не может показать такой список за день, ответственность всё ещё остаётся неформальной.

Настройте линии ревью по уровню риска

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

Это особенно важно, когда один основатель почти всё ещё проверяет сам. Маленькие правки скапливаются рядом с логикой billing, изменениями серверов и кодом login. Такая смесь создаёт стресс и торопливые решения.

Обычно достаточно простой модели из трёх линий:

• Быстрая линия: правки текста, изменения контента, небольшие исправления верстки и низкорисковые интерфейсные изменения.
• Обычная линия: стандартная продуктовая работа, простые исправления багов и обновления функций внутри уже знакомых частей приложения.
• Строгая линия: billing, login, permissions, customer data, миграции базы данных, а также изменения серверов и деплоя.

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

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

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

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

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

Выпускайте релизы маленькими и спокойными шагами

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

Маленькие релизы снижают риск зависимости от основателя, потому что другие люди действительно могут отследить, что изменилось. Помогает фиксированный ритм релизов. Два запланированных окна в неделю на старте обычно достаточно. Команда успевает протестировать всё до окна, задать вопросы заранее и избежать неожиданных Friday night deploys.

Перед каждым релизом запишите четыре короткие заметки:

• что изменилось
• кто это проверил
• как откатить
• какой сигнал покажет проблему в первый час

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

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

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

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

План передачи на 30 дней

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

Начните с работы, которая чаще всего затрагивает production. Глубокие рефакторинги и побочные проекты пока оставьте в покое.

• Неделя 1: Определите, кто отвечает за каждую часть продукта, кто имеет доступ к коду, cloud accounts, базам данных и support tools, и как релиз проходит путь от commit до production. Запишите каждый ручной шаг. Команды часто быстро находят одну скрытую проблему: только основатель может утверждать, сливать или деплоить.
• Неделя 2: Поставьте рядом с основателем одного запасного владельца для живых изменений. Он должен участвовать в исправлении багов, небольших фичах и подготовке релиза. Основатель по-прежнему ведёт процесс, но запасной человек записывает заметки, повторяет шаги и спрашивает, где принимаются решения на основе опыта.
• Неделя 3: Позвольте запасному человеку проверять и деплоить низкорисковую работу. Выбирайте изменения с небольшим радиусом поражения, например обновления текста, правки админки или небольшие backend-правила. Основатель остаётся на связи, но вмешивается только если запасной человек застрял.
• Неделя 4: Полностью уберите один обычный релиз с плеч основателя. Запасной человек выполняет чеклист, при необходимости просит ревью, деплоит в спокойное окно и наблюдает за результатом. Если у команды есть внешний советник или fractional CTO, это хорошая неделя, чтобы этот человек посмотрел на релиз и заметил слабые места.
• Конец месяца: Составьте короткий список пробелов. Пишите просто. Отметьте недостающие доступы, слабую документацию, рискованные сервисы и зоны, где никто другой не может достаточно быстро дебажить. Затем назначьте следующие передачи поимённо.

Один простой принцип помогает: не пытайтесь распределить ответственность сразу по всему продукту. Сначала выберите один сервис, одну фронтенд-зону или один путь релиза. Маленькие победы успокаивают команду и сильно упрощают следующую передачу.

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

Простой пример из портфеля

Одна B2B SaaS-компания в акселераторе со стороны выглядела стабильной. Клиенты платили, входили в систему и получали обновления. Внутри же один основатель всё ещё занимался изменениями billing, исправлениями login и каждым production deploy.

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

Акселератор не стал пытаться передать всё сразу. Он попросил команду сначала разделить две зоны: billing и deploys. Billing затрагивал выручку, а deploys — весь продукт, поэтому обе области быстро начинали болеть, если один человек владел ими в одиночку.

Второй инженер начал брать на себя ревью billing для обычных изменений: текста в инвойсах, обновления тарифов и базовых edge cases платежей. Первые две недели основатель оставался рядом, отвечал на вопросы и утверждал необычные случаи, но перестал быть единственным человеком, который может проверять эту зону.

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

Через месяц картина стала здоровее:

• Основатель всё ещё вёл сложные изменения, например обновления login flow и более глубокую логику цен.
• Другой инженер занимался обычным billing review и рутинными исправлениями.
• Команда выпускала изменения по расписанию, а не тогда, когда у основателя появлялось время.
• Маленькие релизы вызывали меньше стресса, потому что шаги отката уже были записаны.

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

Ошибки, которые только усугубляют проблему

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

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

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

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

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

Представьте небольшую SaaS-компанию, где основатель до поздней ночи сам выкатывает исправления платежей. Акселератор отвечает просьбой сделать rewrite и добавить два новых еженедельных собрания. Спокойнее не становится. Лучшее решение — назначить одного владельца для payments, добавить запасного человека, оставить основателя в ревью этой зоны и перестать выпускать изменения в тот же день, если только речь не идёт о выручке.

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

Быстрые проверки для звонков акселератора

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

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

Каждый раз используйте одни и те же пять проверок:

• Могут ли два человека выпустить обычный релиз на этой неделе, если основатель будет офлайн два дня?
• Может ли кто-то кроме основателя откатить неудачный релиз без скрытых шагов, приватного доступа или срочной помощи?
• Знает ли команда, кто проверяет billing, login и server changes в каждой зоне?
• Прошёл ли последний релиз все записанные шаги от начала до конца?
• Сократилось ли время ожидания ревью в этом месяце, или изменения всё ещё ждут одного человека?

Ответы должны быть конкретными. Имена важны. Дата тоже помогает. Ответ вроде «думаем, команда бы справилась» слишком слабый. Ответ вроде «Марта проверила billing, Бен выкатил релиз, а Ли откатил его в staging в прошлый четверг» говорит намного больше.

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

Можно также оценивать каждый ответ как green, yellow или red. Green означает, что команда уже это делала. Yellow — что есть назначенный владелец, но нет свежего подтверждения. Red — что основатель всё ещё тащит это один. Такая простая шкала помогает сравнивать риск перехода между компаниями в портфеле.

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

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

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

Эта компания покажет вам реальную форму риска. А ещё она даст план, который можно будет повторить и в остальных компаниях портфеля.

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

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

Хорошая первая контрольная точка выглядит так:

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

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

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

Если внешняя помощь уместна, Oleg Sotnikov на oleg.is работает со стартапами как fractional CTO и advisor по product architecture, infrastructure и AI-first engineering operations. Такой формат поддержки лучше всего подходит, когда компании быстро нужна практическая структура, а не долгий аудит.

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