Вопросы о технических рисках для основателей, пока квартал не сорвался

Почему проблемы проявляются слишком поздно

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

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

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

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

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

Как задать эти вопросы за 15 минут

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

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

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

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

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

Фиксируйте изменение, а не всю историю. «Расходы в облаке выросли на 18% с прошлого месяца» достаточно для заметок. За несколько обновлений эти маленькие изменения складываются в картину. Именно тогда отчётность для совета по инженерии становится полезной, а не церемониальной.

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

Делаем ли мы то, что обещали?

Команды часто показывают движение вместо доставки. «Начали», «в работе» и «почти готово» могут заполнить слайды, пока продукт едва меняется. Задайте один откровенный вопрос: что было выпущено за последние 30 дней и чем это реально могут воспользоваться пользователи или клиенты?

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

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

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

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

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

Куда команда потратила своё время?

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

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

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

Затем спросите, что изменило микс. Одна тяжёлая неделя багфикса нормальна. Три недели подряд переработки, сломанных релизов или срочных исправлений — нет. Это обычно означает, что команда слишком быстро доставляла, часто меняла объём или строила на слабой базе.

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

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

Один вопрос прорезает туман: «Над чем команда работала, что вы не сможете объяснить одним предложением?» Если ответ расплывчат, приоритеты тоже.

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

Что ломается постоянно и как быстро мы это исправляем?

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

Для каждого инцидента ежегодно спрашивайте одинаковые факты:

• сколько времени команда заметила проблему?
• сколько времени заняло её исправление?
• случалась ли эта же проблема раньше?
• что изменилось после фикса?

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

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

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

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

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

Какие расходы выросли быстрее, чем отдача?

Рост расходов не всегда плохо. Плохой знак — когда расходы растут, а отдача остаётся прежней.

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

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

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

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

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

Спросите, где команда бы упростила в первую очередь, если бы нужно было сократить расходы на 15% в следующем месяце. Ответ многое скажет. Чёткие ответы означают, что команда понимает свою статую расходов. Расплывчатые — обычно признак того, что расходы росли быстрее, чем дисциплина.

Мы нанимаем из-за реальных пробелов или из-за шума?

План найма может скрывать неупорядоченную операционную проблему. Когда кто-то просит новую роль, спросите, какую боль этот человек снимет в ближайшие 90 дней. «Нужны дополнительные инженеры» — слишком расплывчатая формулировка. «Нужен мобильный инженер, потому что релизы приложения тормозятся на 10 дней в каждом цикле» даёт конкретную проверку.

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

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

Задайте несколько прямых вопросов:

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

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

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

Ошибки, которые скрывают риск вместо того, чтобы его выявлять

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

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

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

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

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

Небольшой набор данных — достаточно:

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

Это делает отчётность перед советом честной. И позволяет заметить риск доставки в месяц два, а не в месяц четыре.

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

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

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

• Попросите продуктового или инженерного лидера назвать, что было выпущено в этом месяце понятным языком для клиентов. «Закрыли 42 тикета» — слабое. «Клиенты теперь могут экспортировать отчёты без ручной помощи» — ясно.
• Попросите финансы соотнести расходы с продуктовой отдачей. Если облако, подрядчики или софт подорожали, кто-то должен объяснить, что получили пользователи или выручка взамен.
• Попросите саппорт или customer success назвать повторяющиеся проблемы, о которых жалуются клиенты. Один громкий отзыв — это шум. Та же жалоба каждую неделю — паттерн.
• Попросите инженерию показать все открытые роли и причину их существования. Хороший ответ: «нужен бекенд-разработчик, потому что релизы зависят от одного человека», а не «хотим более сильных инженеров».
• И финальный вопрос: какой единичный риск может навредить следующему кварталу? Добивайтесь одного конкретного ответа, например задержки релиза, рост infra-расходов или слабая передача между саппортом и инженерами.

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

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

Пример: стартап заметил проблемы во втором месяце

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

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

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

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

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

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

Что делать дальше с ответами

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

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

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

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

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

Простое правило помогает: не открывайте новую роль, пока кто-то не сможет назвать заблокированную работу, объяснить, почему текущая команда не может её поглотить, и сказать, какой результат должен измениться в течение 60–90 дней после прихода нового сотрудника. Это правило сокращает риск найма.

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