Круглый стол: платформенные команды — польза или хайп?

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

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

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

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

Александр видел органическое выделение платформенной команды уже при пятнадцати-двадцати разработчиках: несколько сильных инженеров взяли общие компоненты, которые должны были заменить прежнюю часть стека. Она перестала устраивать по производительности, стоимости поддержки и скорости выпуска функций. Другой случай — группа компаний с несколькими бизнес-направлениями и собственными ИТ-подразделениями. Там отдельное управление базовых технологий получило задачу унифицировать инженерные подходы и инфраструктуру.

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

Метрики зависят от того, что предоставляет платформа. Для аналитического SDK Филиппа важны потери событий, охват внутренних продуктов и отзывы разработчиков. В его примере добавление нового события раньше занимало до нескольких дней, а стало занимать меньше часа. Александр предлагает смотреть на исходную цель: разделение монолитного фронтенда и оболочка микрофронтендов дали командам возможность самостоятельно выпускать изменения и проводить эксперименты. Стоимость самого перехода считали отдельно; работу инфраструктурной команды оценивали, в частности, по числу выпусков в день.

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

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

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

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

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