Платформенные команды — что это такое и зачем они нужны

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

  • runtime инфраструктуры и CI/CD пайплайнов
  • инженерных подходов к разработке
  • ключевых фреймворков и библиотек

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

Жизненный цикл платформенных команд

Я знаю 2 варианта появления таких команд:

  • подход Bottom-Up
  • подход Top-Down

Дальше мы рассмотрим оба варианта

Bottom-Up

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

Рис.1 “Bottom-Up platform team”

Более подробно эта схема появления платформенных команд разобрана в моих статьях:

Плюсы такого подхода в органичности, а минусы в том, что “выращенные” таким образом общие компоненты могут иметь специфику команды и не подходить остальным командам на уровне всей компании.

Top-Down

Подход Top-Down характерен для организаций, в которых к введению платформенных команд пришли пост-фактум, зачастую имея ряд отдельных бизнесов, которые имеют собственные подходы к работе IT. И все всех устраивало до одного из следующих моментов:

  • потребности в интеграции разных бизнесов, имеющих разные IT capabilities, для создания новой ценности для клиентов — value oriented
  • расчета стоимости владения совокупного зоопарка IT систем — cost oriented

В итоге, сверху от бизнеса появляется задача гармонизации и унификации подходов к IT. Один из вариантов — это создание некоторого подразделения, отвечающего за базовые практики и подходы. В рамках этого подразделения зачастую создаются платформенные команды, которые включают в себя ответственность:

  • за процессы разработки и developer experience — выбор общей VCS, Task Tracker, Wiki, etc
  • за рантайм инфраструктуру — dev/test/prod контуры и шаги CI/CD пайплайнов
  • за общие практики и подходы в соответствующих стеках (фронтенд, бекенд, базы данных и так далее)
Рис.2 “Top-Down platform team”

Подход Top-Down в целом является более сложным, но зачастую неизбежным для крупных компаний хотя бы в силу Mergers and Acquisitions сделок, когда сливаются как бизнесы компаний, так и их IT системы.

Теперь, когда мы разобрались с тем, как появляются платформенные команды, мы можем поговорить об их составе.

Состав команды

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

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

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

Одним из ключевых факторов успеха становится наличие в команде technical product manager, который зачастую умеет сразу в 2 вещи:

  • составление роадмапов и контроль приоритетов
  • понимание архитектуры и технических тенденций

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

Теперь перейдем к рассмотрению работы платформенных команд.

Работа платформенной команды

Работа платформенной команды происходит не в вакууме, поэтому должно быть налажено

Взаимодействие с другими командами

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

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

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

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

В этом плане взаимодействие платформенных и продуктовых команд отчасти напоминает концепцию Inner Sourcing. Подробнее о ней можно посмотреть в выступлении Александра Бындю на ArchDays 2019

В любом случае при наличии платформенной команды в определенный момент становится вопросом анализа ее эффективности.

Анализ эффективности

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

  • Зачастую работа платформенной команды приводит к сокращению time-to-market продуктовых команд, так как они часть функциональности могут собрать из готовых блоков или воспользоваться коробочным процессом CI/CD
  • Стоимость владения решениями, построенными на общих компонентах зачастую ниже в расчете на одну команду, так как стоимость изменений общих компонент размазывается на все продуктовые команды

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

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

Рис.3 “Платформенный лидер продает свою платформу тимлидам продуктовых команд”

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store