Проверка здоровья портфеля стартапов, которую можно завершить за 5 дней

Почему проблемы в портфеле остаются незаметными

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

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

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

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

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

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

Что собрать до начала

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

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

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

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

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

Проведите аудит за пять дней

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

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

1. Соберите факты. Попросите один свежий план, историю релизов, текущую структуру команды, счета за облако и софт, главные проблемы поддержки и все инструменты ИИ, которые уже используются.
2. Проверьте сигналы выпуска. Посмотрите, что вышло, что сдвинулось и что постоянно застревает. Один заблокированный шаг согласования или один отсутствующий ответственный могут замедлить команду сильнее, чем беспорядочная доска спринта.
3. Разберите статьи затрат. Вам не нужен полный финансовый разбор. Ищите дублирующиеся инструменты, простаивающие среды, слишком большие серверы и лицензии, к которым никто не прикасался неделями.
4. Параллельно смотрите на проблемы поддержки и процессы с ИИ. Недавние жалобы клиентов показывают, где продукт ломается. ИИ имеет значение только тогда, когда он экономит реальное время в программировании, тестировании, поддержке или внутренних процессах.
5. Оцените каждую компанию на одном листе и запишите следующий шаг. Формулируйте прямо: что выглядит здоровым, что требует внимания прямо сейчас и кто отвечает за исправление.

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

Хороший итоговый лист короткий. Дайте каждой компании простую оценку по выпуску, затратам, поддержке и использованию ИИ, а затем добавьте одну заметку с самым выгодным действием на ближайшие 30 дней.

Проверьте выпуск, не разбирая каждую задачу

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

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

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

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

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

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

Простой пример делает это очевидным. Команда A планировала 10 задач, выпустила 8 и получила один баг, который снова открылся. Команда B планировала 14, выпустила 6, остановила два релиза и требовала одобрения основателя для каждого деплоя. Команде B не нужно больше тикетов. Ей нужно более четкое планирование и более простой путь выпуска.

Завершите этот раздел одной фразой в листе: может ли эта команда превращать запланированную работу в выпущенную без постоянных переделок и ожидания?

Проверьте затраты на инфраструктуру без полного финансового аудита

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

Для начала разбейте расходы на три группы: хостинг, инструменты и подрядчики. Хостинг включает облачные серверы, базы данных, хранилище, CDN и резервные копии. Инструменты включают аналитику продукта, мониторинг, софт для поддержки, CI, дизайн и чат. Подрядчики — это фрилансеры, агентства и специалисты на частичной занятости.

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

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

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

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

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

Проверьте боль поддержки по недавним обращениям клиентов

Начните с последних 30–50 обращений в поддержку. Такой выборки обычно достаточно, чтобы увидеть, на что клиенты натыкаются снова и снова, не погружаясь в старый шум.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оцените каждый стартап на одном простом листе

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

Сделайте шкалу простой. 1 означает «нужно действовать прямо сейчас», 3 — «работает, но не всегда надежно», а 5 — «здорово и повторяемо». Сохраняйте этот смысл от компании к компании.

Оценивайте каждый раз одни и те же четыре области:

• выпуск
• затраты на инфраструктуру
• проблемы поддержки
• использование ИИ

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

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

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

Реальный пример из двух компаний портфеля

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

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

Проблема скрыта в инфраструктуре. Команда платит за пересекающиеся инструменты, держит крупные тестовые серверы весь месяц и все еще оплачивает старые подписки от прежних экспериментов. Ее лист может выглядеть так: выпуск 4/5, затраты на инфраструктуру 1/5, проблемы поддержки 3/5, использование ИИ 2/5.

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

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

Клиентам — нет. Обращения в поддержку накапливаются, одни и те же проблемы возвращаются снова, а инженеры время от времени теряют полдня на ответы на срочные вопросы. Такой лист может выглядеть так: выпуск 2/5, затраты на инфраструктуру 4/5, проблемы поддержки 1/5, использование ИИ 2/5.

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

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

Ошибки, которые съедают пользу быстрого аудита

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

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

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

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

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

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

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

Простые слова важнее отполированности. Не пишите «проблемы с выпуском», если реальная проблема в том, что «релизы сдвигаются на 2–3 недели, и никто не может объяснить почему». Не пишите «нагрузка на поддержку повышена», если в прошлом месяце пять клиентов столкнулись с одним и тем же багом. Основатели быстро считывают риск, поэтому называйте проблему так, как они сказали бы это вслух.

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

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

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

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

Что делать после первой недели

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

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

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

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

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

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