Team API

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

Наш эксперт, Игорь Курочкин, принял участие в обсуждении платформенных команд, которая прошла в онлайн формате 20 сентября 2022 года. В дискуссии также участвовали:
  • Артем Науменко — руководитель инфраструктуры в Skyeng;
  • Карапет Манасян — руководитель платформы производства MOEX Group.

Участники обсуждения ответили на следующие вопросы:
  1. Чем отличается платформенная команда от инфраструктурной или DevOps команды?
  2. Кто такой платформенный инженер?
  3. Входят ли разработчики и тестировщики в платформенную команду?
  4. Как происходит взаимодействие продуктовых и платформенных команд?
  5. Как отличить псевдо-платформу от настоящей платформы?
  6. Какие компетенции следует развивать в платформенной команде?
  7. Как платформенной команде развивать экспертизу и следить за индустрией?
  8. Какая роль HR в формировании платформенной команды?
  9. Почему отсутствуют вакансии платформенных инженеров?

Основные выводы из обсуждения:
  • Платформа — это продукт, а внутренняя платформа — внутренний продукт. Платформа позволяет разработчикам получить нужный результат, в режиме self-service, без взаимодействия с другой команды и ожидания;
  • Платформенная команда — один из вариантов продуктовой команды. Команда понимает, кто ее клиент, регулярно общается с пользователями платформы, проводит CustDev, собирает обратную связь и на этой основе формирует роадмап и бэклог. Продуктовые компетенции обязательно должны быть у руководителя платформенной команды. Если их не хватает, можно временно позвать в команду продуктового руководителя. Всей команде необходим опыт разработки, чтобы проектировать API, обрабатывать ошибки, писать тесты и заранее решать проблемы, которые могут возникнуть у разработчиков. Желательно, чтобы в команде был полноценный разработчик с контекстом и пониманием реальных проблем разработки. С точки зрения ролей платформенная команда по составу близка к кроссфункциональной продуктовой команде и может включать Product Owner, Developer, Ops и QA. В Skyeng платформенные инженеры разрабатывают платформу на тех же инструментах, которые они предоставляют разработчикам. Это позволяет лучше понимать ограничения инструментов и направления их развития;
  • Определение Platform Engineering — это когда вы просите продакта создать внутренний продукт (платформу), по аналогии с определением SRE: "SRE is what happens when you ask a software engineer to design an operations team";
  • Сообщество вокруг Platform Engineering сформировалось в 2019 году, а первая конференция PlatformCon прошла в 2022 году, тогда же запустился сайт Platformengineering.org и почтовая рассылка Platform Weekly;
  • В 2022 году еще не существует устоявшегося определения и стандартов Platform Engineering, а специализированных книг по теме пока не опубликовано. В качестве отправной точки участники обсуждения рекомендуют подход и книгу Team Topologies.
  • Продажа платформы топ-менеджменту должна начинаться с кастдева бизнеса и разработчиков. Необходимо понять планы бизнеса, на какие метрики он ориентируется, и сформулировать, как платформа может повлиять на улучшение этих метрик. В процессе обсуждения может подтвердиться необходимость платформы, а может выясниться, что компании требуется другое решение. По мнению Артема Науменко, топ-менеджмент в первую очередь смотрит на бизнес-метрики, такие как Time to Market и финансовый результат. Из этого выводится стоимость одного часа Time to Market. Если разработчик, например, 4 часа ждет доступы к базе данных, компания теряет 4 часа Time to Market в денежном выражении. Платформа должна показывать, как конкретные сервисы, например автоматизированная выдача доступов, напрямую увеличивают бизнес-результат. В качестве примера был приведен кейс компании, которая разрабатывала коробочный SaaS для корпоративных клиентов и одновременно зарабатывала на почасовой разработке фич под заказ. В такой модели бизнес не заинтересован в ускорении разработки, так как замедление напрямую увеличивает выручку. В подобных условиях развитие внутренней платформы не имеет бизнес смысла;
  • Трансформация инфраструктурной команды в платформенную стоит начинать с поиска апологета платформенного подхода внутри команды и предоставления ему ресурсов и полномочий. В команде обязательно должен быть человек с целостным представлением о том, какой должна быть платформенная команда и платформа в итоге. Если такого человека нет, его необходимо привлекать извне. Трансформация является длительным процессом, поэтому для этой роли важен человек, которому комфортно много взаимодействовать с разработчиками других команд и доводить инициативы до конца. Альтернативный путь — расформировать инфраструктурную команду и встроить инженеров в продуктовые команды разработки. В этом случае инженеры начинают глубже понимать боли и потребности разработчиков, но существует риск, что такой формат подойдет не всем и часть специалистов может уйти;
  • Для развития платформенного подхода на рынке не хватает специализированных конференций и профессиональных сообществ, книг по Platform Engineering, а также ярких публичных экспертов, которые бы системно развивали и популяризировали эту тему.

Подробнее в конспекте обсуждения платформенных команд.

Свяжитесь с нами, если вам интересно развитие подхода Platform Engineering, внутренних платформ и платформенных команд в вашей компании.