Исправьте проблемный стек прежде чем нанимать новых людей

Как выглядит проблемный стек в повседневной работе

Проблемный стек редко начинается с драматичного сбоя. Он проявляется в обычной работе.

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

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

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

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

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

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

Где команда теряет время в первую очередь

Время обычно теряется между людьми, а не внутри кода.

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

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

Незаконченная работа имеет скрытую стоимость. Людям приходится заново входить в контекст каждый раз, когда они возвращаются к задаче. Этот сброс может съедать 15–30 минут каждый раз, и происходит он весь день.

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

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

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

Проведите короткий сброс прежде чем добавлять людей

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

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

Поместите все активные задачи в одно место. Одна доска или одна таблица достаточна. Формат важнее правила: если работа реальна — она на списке.

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

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

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

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

Защитите то, что удерживает бизнес

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

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

Сократите объём до того, что команда успеет довести до конца

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

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

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

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

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

Малые релизы снижают риск, дают быстрый фидбек и не позволяют полузавершённой работе накапливаться.

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

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

Назначьте каждому сервису явного владельца

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

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

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

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

Небольшой команде не нужна сложная карта. Один инженер может владеть биллингом, другой — клиентским приложением, третий — CI/CD и процессом релизов. Если владелец отсутствует, назначьте резервного, прежде чем что-то сломается в пятницу вечером.

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

Сделайте релизы спокойными и предсказуемыми

Если релизы ощущаются как игра в кости, команда замедляется.

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

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

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

Последний пункт важнее, чем многие признают. Не спрашивайте «смогём ли мы откатить?» после провала релиза. Решите это заранее. Если изменение требует feature flag, резервной копии или простого плана revert — настройте это до того, как кто-то нажмёт deploy.

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

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

Более безопасные релизы выигрывают время. Время позволяет команде чистить код, сокращать объём и позже нанимать под реальные пробелы, а не в панике.

Простой пример от небольшой продуктовой команды

Пятеро в SaaS-команде постоянно пропускали еженедельный релиз. На бумаге проблема выглядела как недостаток персонала. На деле у них был вопрос объёма, ответственность и релизы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте четыре быстрых проверки:

• Попросите трёх человек назвать три главные приоритеты на сегодня. Если получите три разных списка — команда расколота.
• Для каждой сервисной области спросите, кто решает, что там происходит. Если звучат два имени — на самом деле никто не владеет.
• Попробуйте выпустить одну крошечную правку: текст, маленькое правило или багфикc. Если это превращается в долгую встречу или страх отката — релизы слишком хрупки.
• Посмотрите на текущую работу и вырежьте всё, что не даёт близкой отдачи. Старые эксперименты, побочные проекты и nice-to-have фичи крадут время у реальных проблем.

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

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

Что делать дальше, если команда всё ещё застопорилась

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

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

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

Именно тут поддержка внештатного CTO часто имеет смысл для небольших команд. Вы получаете структуру и внешний взгляд без масштабного найма. Если нужна такая помощь, Oleg Sotnikov на oleg.is работает со стартапами и малыми компаниями по вопросам архитектуры, потока доставки, инфраструктуры и AI‑ориентированных операций. Его опыт охватывает разработку ПО, стартапы, CEO и CTO‑роли, поэтому рекомендации, как правило, остаются прагматичными.

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