Зависимость от основателя в технической проверке: что спрашивать

Почему об этом спрашивают

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

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

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

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

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

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

Именно поэтому в дилижентности задают резкие и простые вопросы. Кто сегодня может задеплоить без спроса у основателя? Кто руководит инцидентом в два ночи? Кто объяснит, почему корпоративный клиент A ведёт себя иначе, чем клиент B? На эти ответы видно, сколько в компании переносимого набора знаний, а сколько — личного опыта.

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

Кто может деплоить без основателя

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

Покупатель или инвестор обычно спрашивает не должности, а имена. «Наш инженер может деплоить» — слабый ответ. «Анна и Виктор могут выпустить приложение, Мария может одобрить хотфикс, и любой из троих может откатить» — гораздо сильнее. Такой ответ показывает разделённую ответственность и понятные границы.

Важны четыре вопроса:

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

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

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

Обычно решение скучное, и в этом плюс. Перенесите доступы в аккаунты компании. Напишите короткий деплой‑руководство (runbook). Определите, кто что одобряет. Проследите, чтобы хотя бы двое человек недавно делали живой деплой.

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

Кто владеет инцидентами, когда что‑то ломается

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

Начните с простого вопроса: если сайт упадёт сегодня ночью, кто отвечает? Дилижентность проясняется, когда компания называет конкретного человека, а не даёт неопределённый ответ «команда». Этот человек не обязан чинить каждую проблему в одиночку, но он должен владеть реакцией до восстановления сервиса.

Затем распишите первые 15 минут. Кто получает оповещение первым? Кто подключается следующим? Если ответ всё ещё «основателя оповещают и он решает, что делать», риск реальный. Здоровая схема проще: инженер на дежурстве проверяет сигнал, при необходимости подключается другой инженер, а основатель вмешивается только для крупных бизнес‑решений.

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

На дилижентности нужно получить прямые ответы на четыре пункта:

• Кто ведёт инцидент от первого оповещения до восстановления?
• Кто получает оповещения первым, и кто подключается следующим?
• Кто публикует обновления, пока инженеры работают?
• Где описан путь диагностики, эскалации, отката и восстановления?

Этот путь может быть коротким, но он должен существовать. Хорошие команды держат простой runbook с правилами алертов, владельцами сервисов, шагами отката, контактными лицами и правилом, когда эскалировать.

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

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

Кто знает продуктовую логику

Здесь начинаются более сложные вопросы. Хочется понять, работает ли компания на общей базе знаний или на памяти основателя.

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

Если никто не может ответить без копания в старых чатах, риск реален.

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

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

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

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

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

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

Большинство команд не решают это большим процессом. Они решают это, сделав видимой ответственность и проверив её в реальной работе.

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

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

1. Проведите один обычный деплой без участия основателя. Основатель может наблюдать, но команда должна подготовить, выполнить, проверить и при необходимости откатить.
2. Запишите десять продуктовых решений, по которым люди чаще всего обращаются к основателю. Включите правила ценообразования, логику прав, шаги одобрения и распространённые крайние случаи.
3. Перенесите доступы из личных аккаунтов в аккаунты команды. Это касается контроля версий, облака, мониторинга, CI/CD, доменов и менеджера паролей.
4. Назначьте именные владельцы для алертов и инцидентов. Один человек отвечает первым, один его поддерживает, и один решает, когда эскалировать.
5. Просматривайте слабые места каждую неделю в течение месяца. Малые команды быстро улучшаются, когда фокусируются на одном пропавшем владельце за раз.

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

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

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

Если компания маленькая, внешняя помощь может ускорить процесс. Oleg Sotnikov из oleg.is часто работает как fractional CTO и помогает стартапам наладить передачи, например доступы для деплоя, ответственность за инциденты и разделение продуктовых знаний перед дилижентностью. Такая поддержка полезна, когда команды нужно быстро получить рабочий процесс, а не гору документов.

Простой пример стартапа

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

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

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

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

Готов небольшой релиз, но никто не решается нажать deploy. Клиент жалуется на отсутствие счётов. Саппорт эскалирует. Инженеры могут найти баг только наполовину, потому что первоначальную логику биллинга писал основатель. Инцидент растягивается с 20 минут до шести часов не потому, что команда слабая, а потому что ответственность размытa.

Вот что замечают инвесторы. Они не видят плохую команду. Они видят команду с одним узким местом.

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

Ни одно из этого не требует гигантского процесса. Команде просто нужно сделать ежедневную работу менее персональной и более общей.

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

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

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

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

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

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

Быстрые проверки перед звонком по дилижентности

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

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

Короткий чеклист:

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

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

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

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

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

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

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

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

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

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

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

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