Сократить инженерную команду, не сломав продукт

Почему сначала сокращать людей — плохая идея

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

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

Первые признаки обычно небольшие. Замедляется triage багов. Очереди на review становятся длиннее. Тикеты в support висят днями вместо часов. Клиенты это замечают. Они могут не знать, что команда стала меньше, но они видят, когда простые проблемы тянутся по два спринта.

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

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

Если убрать людей до того, как убрать работу, один и тот же сценарий повторяется снова и снова:

• Зоны ответственности становятся размытыми.
• Исправления багов замедляются.
• Время ответа support растягивается.
• Продукт начинает казаться менее надежным.

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

Сначала сократите объем работ, а не роли

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

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

Помогает простой фильтр. Для каждого проекта или пункта backlog спросите:

• Приносит ли это выручку или защищает продления?
• Помогает ли это продукту оставаться надежным, безопасным и соответствующим требованиям?
• Использует ли это достаточно активных клиентов, чтобы оправдать затраты?
• Замечают ли люди быстро, если мы перестанем это делать?

Если ответ «нет», поставьте на паузу.

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

Запишите список остановки. Не оставляйте его в виде расплывчатой договоренности после одной встречи. Product, support, sales и руководство должны видеть один и тот же простой план. Например: в этом квартале никаких новых integrations, никакого редизайна админки, никакой поддержки старых крайних сценариев, никаких экспериментов, которые не влияют на выручку или uptime.

Этот письменный список важен, потому что люди по привычке снова наполняют roadmap. Sales просит одно исключение. Support продолжает старое обещание. Менеджер подсовывает любимую фичу. И вот уже меньшая команда делает тот же объем работы меньшими силами.

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

Составьте карту работы, которая держит продукт живым

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

Начните с владельцев. Releases, incidents, billing и support должны быть привязаны к конкретному человеку. Если ответственность «делится» между двумя людьми, спросите, кто принимает решение, когда релиз падает в 9 вечера или когда начинают накапливаться ошибки платежей.

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

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

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

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

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

Консолидируйте инструменты и упростите передачи

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

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

Уберите дублирование

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

Оставьте одно место для задач, одно место для просмотра алертов, одно место для документов и runbook, один путь сборки и деплоя и одно место для разбора инцидентов. То же правило относится и к сервисам. Если два продукта оба закрывают мониторинг, error tracking, feature flags или CI, выберите один, если у вас нет реальной причины оставить оба.

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

Уберите ожидание между командами

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

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

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

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

Сначала поднимите уровень автоматизации, потом сокращайте роли

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

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

Небольшая SaaS-команда обычно получает быстрый эффект от нескольких базовых вещей:

• скрипты настройки локальной и staging-среды
• backups и проверки восстановления одной командой
• скрипты rollback для неудачных релизов
• простые release gates для сборок, миграций и health checks

Тесты должны защищать пользовательские сценарии, которые сильнее всего болят, если ломаются. Сфокусируйтесь на signup, login, checkout, изменениях billing, сбросе пароля и первом действии нового пользователя после onboarding. Полное покрытие не обязательно. Пять надежных тестов вокруг денег, доступа и данных полезнее, чем пятьдесят нестабильных.

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

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

Команды, которые переходят к AI-assisted operations, обычно начинают именно отсюда. Они автоматизируют code review, генерацию тестов и рутинные проверки до того, как снижают численность. Такой порядок работает, потому что автоматизация сначала убирает рутину. Потом меньшая команда может тратить время на работу, где все еще нужен человеческий judgment.

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

Используйте более безопасную последовательность

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

Сначала объем работ и инструменты

В первую неделю заморозьте новые задачи, если они не защищают выручку, безопасность или uptime. Затем отсортируйте текущую работу простым вопросом: помогает ли это продукту продаваться, работать или соответствовать требованиям? Если нет, поставьте на паузу.

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

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

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

Сначала автоматизируйте, потом перераспределяйте ответственность

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

Четвертая неделя — про ответственность. Передавайте ее намеренно, а не случайно. Решите, кто отвечает за releases, проблемы в продакшене, инфраструктуру, баги клиентов и runbook, которые объясняют, как с этим работать.

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

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

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

У небольшой SaaS-компании было 10 человек на продуктовой стороне: 5 инженеров, 1 дизайнер, 1 product manager, 2 сотрудника support и 1 engineering lead. Выручка не росла, поэтому founders хотели быстро сократить расходы. Их первая идея была простой и рискованной: убрать двух инженеров и надеяться, что остальные справятся.

Они выбрали более безопасный порядок.

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

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

После этого они исправили процесс релизов. До этого изменения каждый deploy зависел от senior engineer, который вручную проверял login flow, billing page и account setup. Команда добавила небольшой набор smoke tests перед каждым релизом. Он не покрывал вообще все, но ловил очевидные поломки, из-за которых чаще всего приходилось делать ночные rollback.

Потом они занялись платформой. Один инженер незаметно стал человеком, который знал deployments, backups, alerts и странные серверные исправления. Это ловушка. Команда записала рутинные задачи, перевела доступы на общие аккаунты и дала другому инженеру неделю на парную передачу знаний. Короткий runbook оказался лучше, чем tribal knowledge.

К моменту, когда они вернулись к численности команды, работа уже изменилась:

• одна поверхность продукта исчезла
• у support стала одна очередь вместо двух
• релизы требовали меньше ручной проверки
• platform work больше не жила в голове одного человека

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

Ошибки, которые ведут к сбоям и оттоку клиентов

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

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

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

Если в тот же период добавлять новые инструменты, становится только хуже. Новая ticket system, новая настройка CI или новый AI coding tool могут звучать полезно, но каждое изменение добавляет настройку и новые точки отказа. Во время смены штата держите стек максимально скучным.

Еще одно слабое место — on-call coverage. Чем меньше людей, тем больше систем, алертов и стресса ложится на каждого. Если никто не практиковал rollback, небольшая проблема с релизом может превратиться в долгий outage. У каждого релиза должен быть понятный путь отката, и минимум два человека должны уметь им пользоваться.

Support volume тоже слишком часто игнорируют после запуска. Это ошибка. Релиз, который создает 200 дополнительных тикетов, может завалить маленькую команду на недели. Следите за количеством тикетов, временем первого ответа и тем, какие проблемы клиенты повторяют чаще всего. Если нагрузка на support начинает расти, замедляйте релизы до того, как начнется отток.

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

Проверки, которые нужно сделать перед сокращением роли

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

Ищите доказательства, а не уверенность. «Нам кажется, что мы справимся» — этого мало.

• Кто-то кроме человека, который уходит, может провести реальный релиз, разобрать небольшую проблему и при необходимости сделать rollback.
• У каждой клиентской системы есть один понятный владелец. Это включает app, billing, auth, email, monitoring и любой сервис, который может разбудить клиентов при сбое.
• Алерты, логи и backups все еще работают, и люди их проверяют. Молчаливый канал алертов хуже, чем отсутствие алертов вообще.
• Support может отвечать на типовые проблемы без того, чтобы каждый тикет тащил инженера.
• Команда уже несла новую нагрузку две-четыре недели в обычный период с реальным трафиком.

Следите и за медленным ухудшением. Сначала растет lead time. Потом дольше висят баги. Потом support начинает говорить: «Engineering вам ответит», потому что никто не владеет ответом.

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

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

Не меняйте оргструктуру первой. Запустите продукт так, будто меньшая команда уже существует, но оставьте всех на местах на 30 дней. Этот тест покажет, где план держится, а где ломается.

Начните с того, что заморозите уже решенную к сокращению работу. Уберите из спринтов проекты с низкой ценностью, поставьте на паузу дополнительные запросы и при необходимости сузьте обещания по support. В течение этих 30 дней каждую неделю следите за коротким набором метрик: количеством и серьезностью багов, временем ответа support и инцидентов, скоростью релизов и частотой rollback, а также признаками перегрузки, например стрессом на on-call или заблокированной работой.

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

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

Внешний review может помочь, потому что внутренние команды часто привыкают к рискованным обходным решениям. Именно такой практический review Oleg Sotnikov делает через oleg.is: объем работ, инструменты, автоматизация, инфраструктура и дизайн команды до того, как компания меняет роли. Сторонний взгляд часто полезнее, чем еще один раунд догадок внутри команды.

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