В жизни любого успешного IT-продукта наступает момент, когда взрывной рост фич затихает. Наступает режим поддержки (Maintenance Mode). Это точка, где рутина — исправление багов, закрытие уязвимостей и обновление библиотек — начинает сжигать больше ресурсов, чем создание новых фич.
Большинство компаний застревают в этой фазе, используя устаревшие подходы, которые выжигают разработчиков и сливают бюджеты. Стив Смит, глобальный руководитель по модернизации в Equal Experts, предлагает альтернативу: мультисервисные команды.
Почему классические подходы — это тупик
Обычно бизнес пытается решить проблему поддержки двумя путями. Оба ведут к провалу.
- Вариант 1: Скинуть всё на классический Ops / Support
- Что происходит: Отдельная команда эксплуатации получает на баланс сотни «старых» сервисов от разных продуктовых команд.
- Итог: Колоссальная когнитивная нагрузка на инженеров. Они не могут глубоко знать сотни чужих систем. Надежность падает, а поддержка превращается в «IT-кладбище».
- Вариант 2: Заставить продуктовые команды тянуть старое параллельно с новым
- Что происходит: Разработчики пытаются пилить новые фичи, но постоянно отвлекаются на тушение пожаров в старых сервисах.
- Итог: Фокус уничтожен, сроки по новым продуктам сорваны, сильные инженеры демотивированы и уходят из компании.
Радикальное решение: мультисервисные команды
Вместо того чтобы отправлять сервис на «абстрактный склад утиля», его передают в мультисервисную команду, закрепленную строго за конкретной продуктовой вертикалью.
[ Продуктовая вертикаль: Клиентский сервис ] ├── Команда А (Фичи: Заказы) ────────> Развивают новое ├── Команда Б (Фичи: Оплата) ────────> Развивают новое └── [ МУЛЬТИСЕРВИСНАЯ КОМАНДА ] ───> Держат купол над всеми «тихими» сервисами вертикали
В чем суперсила этого подхода?
- Разгрузка бюджетов: Основные продуктовые команды освобождаются от балласта. Их можно безболезненно сократить или перебросить на новые бизнес-цели.
- Понятный контекст: Команда работает внутри одного бизнес-домена. Им не нужно знать устройство всей корпорации — они эксперты в своей вертикали.
- Легкий реверс: Если бизнес снова найдет деньги на развитие старого сервиса, его возврат к активным разработчикам пройдет гладко. У них общая культура и единый контекст.
- Карьерный лифт для джунов:
Лайфхак: Сеньоры ненавидят копаться в поддержке из-за амбиций и профессиональной идентичности. Смит рекомендует отдавать эти места джуниор-инженерам. Для них это лучший способ получить реальную ответственность, прочувствовать «живой» трафик и понять бизнес компании изнутри.
3 железных правила (Guardrails), чтобы система не сломалась
Без четких границ мультисервисная команда быстро превратится в свалку плохого кода. Чтобы этого не произошло, нужны три правила:
1. Четкий маркер «низкого спроса» (Low Demand)
Нельзя отдавать сервис на поддержку просто потому, что от него устали. Базовый критерий:
- Сервис не генерирует уникальную ценность прямо сейчас.
- Он живет в продакшене под реальным трафиком больше 3 месяцев.
- Частота деплоев и объем новых фич в них плавно стремятся к нулю.
2. Имя команды = её миссия
Команда должна отвечать за бизнес-результат, а не за «закрытие тикетов в Jira». Называйте команду в честь её вертикали.
Если вертикаль называется «Клиентский сервис», то и команда поддержки должна называться «Команда клиентского сервиса». Это подчеркивает, что они отвечают за качество опыта клиентов, а не просто чинят код.
3. Единый стандарт передачи кода (Service Transfer Criteria)
Правила игры должны быть одинаковыми для всех. Процесс передачи сервиса должен выглядеть идентично в обе стороны: как при уходе на поддержку, так и при возврате в активную разработку. Это требование закрывается сильной платформенной инженерией (Platform Engineering), которая стандартизирует инфраструктуру и CI/CD в компании.
Главный вывод: Режим поддержки — это не признак умирания продукта. Это признак его зрелости и стабильности. Перестаньте бороться с неизбежным и начните готовить под него правильные процессы.
На основе A Radical Approach to Long Term Software