Когда нанимать на надежность, пока фичи не начали замедляться

Почему работа над фичами начинает замедляться

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

Ауты работают не только по часам. Они дробят неделю на куски. Инженеры теряют нить работы. Продукт‑менеджеры перекраивают приоритеты. Основатели просят ставить меньшие ставки, потому что большие кажутся рискованными. Все заняты, но меньше продукта уходит в прод.

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

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

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

Три признака, что команде нужна работа по надежности

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

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

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

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

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

Проверьте нагрузку инцидентов за последние два месяца

Один неприятный аут может напугать любого основателя, но нанимать на основании одного плохого дня — ошибка. Посмотрите на последние 6–8 недель. Это окно покажет, редки ли проблемы по надёжности или они постоянно отрывают команду от продуктовой работы.

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

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

Проверьте, кого прерывают каждый раз. Если один и тот же бэкенд‑лид, staff engineer или операционный человек постоянно бросает фич‑работу, чтобы тушить пожары, ваша дорожная карта уже платит цену. Ревью висят дольше. Решения откладываются. Мелкие баги остаются открытыми, потому что те, от кого все зависят, убирают следующий бардак.

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

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

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

Ищите страх релизов в ежедневной работе

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

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

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

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

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

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

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

Посчитайте нагрузку поддержки на продуктовую команду

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

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

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

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

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

Смотрите на людей, а не только на суммарные часы. Один инженер, теряющий по 60 минут на срочные пинги, сделает меньше, чем тот, кто тратит три запланированных часа на поддержку. Прерывания рушат «maker time». Стоимость — не только в самих часах, а в перезапуске после каждого переключения контекста.

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

Рабочее правило: если поддержка занимает больше 15–20% инженерного времени большую часть недель, или если два‑три человека не могут защитить длинные блоки для фокусной работы, команда уже платит налог за ненадёжность. Еще один найм на фичи может поднять отдачу на месяц‑два, но не решит прерывания, которые тянут всех назад.

Как решить, нужно ли нанимать сейчас

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

Положите это число рядом с одним нормальным спринтом фич‑работы. Если команда планировала 80 часов на продуктовые изменения, но потеряла 25 на пожары и поддержку, это не фоновый шум. Надёжность уже определяет, что будет построено.

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

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

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

Избегайте расплывчатой вакансии «платформа» или «DevOps», которая пытается починить всё сразу. Маленьким командам лучше узкая первая роль, привязанная к одной очевидной проблеме. Если вы не готовы к найму на полную ставку, внешний специалист может определить первого владельца надежности, объём работы и порядок задач, прежде чем вы потратите месяцы на поиск неправильного кандидата.

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

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

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

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

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

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

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

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

Ошибки, которые усложняют переход

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

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

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

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

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

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

Короткий чек‑лист перед открытием роли

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

Задайте эти пять вопросов и ответьте на них примерами за последние 6–8 недель:

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

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

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

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

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

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

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

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

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

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

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

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

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