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

Когда стартапу нужен аудит спасения

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

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

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

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

Выбор инструментов может создать более тихую проблему. Стартап выбирает хостинг‑бэкенд, no‑code стэк или поставщика ИИ, чтобы быстрее стартовать. Позже появляются изменения в ценах, лимиты на экспорт, недостающие функции или строгие правила API, которые начинают определять, что продукт может делать. В этот момент компания уже не принимает продуктовые решения свободно.

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

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

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

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

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

Простой пятидневный ритм работает хорошо:

1. День 1: зафиксировать объём, владельца и десять вопросов.
2. День 2: поговорить с основателем и продуктовой командой.
3. День 3: поговорить с инженерами и теми, кто отвечает за продакшен.
4. День 4: собрать доказательства из документов, метрик, тикетов, контрактов и заметок по инцидентам.
5. День 5: ранжировать проблемы и решить, что делать в первую очередь.

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

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

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

Если команда маленькая, вся неделя может уместиться в несколько концентрированных сессий. Главное — дисциплина, а не формальности.

Вопросы 1 и 2: реальность роадмапа

Вынесите последние 90 дней на одну страницу. Если команда говорит, что много выпустила, вы должны увидеть датированные релизы, заметные изменения для клиентов, багфиксы, которые остались исправленными, и работу, которая повлияла на бизнес‑метрику. Длинная доска проектов — не доказательство. Активная ветка в чате — тоже не доказательство.

Вопрос 1: Что реально было выпущено за последние 90 дней?

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

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

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

Вопрос 2: Почему отложились пункты роадмапа и почему следующая дата правдоподобна?

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

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

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

Вопросы 3 и 4: что может сломаться в продакшене?

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

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

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

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

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

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

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

Вопросы 5 и 6: где вендорская привязка бьёт по нам?

Вопрос 5

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

Тест прост: если один счёт удвоится в следующем месяце, какое изменение заставит вас пересчитать цены, приостановить рост или урезать функции? У этого вендора есть рычаг над вашим роадмапом.

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

Вопрос 6

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

Обратите внимание на правила ценообразования в биллинговом инструменте вместо приложения, шаги рабочих процессов, скрытые в no‑code сервисе, правила аутентификации и прав в дашборде вендора, логику отчётности в BI‑инструменте или поведение продукта, сформированное под конкретный API вендора.

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

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

Вопросы 7 и 8: где команда застревает?

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

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

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

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

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

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

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

Вопросы 9 и 10: что сжигает время и деньги?

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

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

Вопрос 9: Какая работа тратит деньги, но ничего значимого не меняет?

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

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

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

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

Вопрос 10: Какое одно изменение освободит больше всего времени в следующем месяце?

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

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

Простой пример из застрявшего продукта

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

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

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

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

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

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

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

Ошибки, которые скрывают реальную проблему

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

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

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

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

Быстрые проверки перед действиями

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

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

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

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

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

• "Релизы ждут одного инженера."
• "Мы пообещали фичи, которые команда не успеет сделать."
• "Счёт вендора растёт быстрее, чем использование."

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

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

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

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

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

Простой 30‑дневный план спасения часто выглядит так:

1. Неделя 1: убрать или отложить пункты роадмапа без явного владельца, оценки или бизнес‑повода прямо сейчас.
2. Неделя 2: исправить самые большие риски продакшена, например слабый мониторинг, отсутствие резервных копий или слишком большую концентрацию знаний у одного человека.
3. Неделя 3: убрать один‑два узких места в команде, например медленные утверждения или неясные передачи обязанностей.
4. Неделя 4: пересмотреть, что изменилось, что сдвинулось и что всё ещё блокирует доставку.

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

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