Platform as a Product

Почему платформы проваливаются

В 2023 году Gartner включил platform engineering в свой список ключевых технологических трендов и спрогнозировал, что к 2026 году 80% крупных софтверных организаций создадут платформенные команды. Компании услышали — и начали создавать. Беда в том, что многие платформенные команды воспроизводят модель, которая давно доказала свою несостоятельность: централизованная ops-команда, которая получает тикеты от разработчиков и выполняет их в порядке приоритета.

Разработчики в такой модели ждут. Платформенная команда перегружена. Бэклог растёт. Разработчики начинают обходить платформу — поднимают инфраструктуру в AWS-консоли, пишут свои скрипты, копируют Terraform-конфиги из чужих репозиториев. Через полгода CTO смотрит на дашборд adoption и видит, что платформой пользуются 15% команд. Проект признают неудачным.

Ошибка не техническая. Команда могла выбрать правильные инструменты, написать хороший код, развернуть Backstage с красивым UI. Ошибка в том, что платформу строили как инфраструктурный проект — а строить надо как продукт.

Определение Эвана Ботчера

Эван Ботчер в 2018 году написал статью на MartinFowler.com, которая стала отправной точкой для всего движения platform-as-a-product. Его определение: «Цифровая платформа — это основа из self-service API, инструментов, сервисов, знаний и поддержки, организованная как привлекательный внутренний продукт».

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

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

Thinnest Viable Platform

Мэтью Скелтон и Мануэль Пейс в Team Topologies ввели концепцию Thinnest Viable Platform (TVP) — тонкая жизнеспособная платформа, аналог MVP для внутренних платформ. TVP — это минимальный набор API, документации и инструментов, необходимый для ускорения разработки в организации.

Скелтон приводит пример: TVP может быть wiki-страницей. «Мы используем этого облачного провайдера. Используем только эти сервисы. Вот как мы их используем». Если этого достаточно, чтобы новая команда начала работать без двухнедельного онбординга — это рабочая платформа.

TVP — противоядие от overengineering-а. Вместо того чтобы год строить идеальную платформу с оркестратором, каталогом, порталом и AI-ассистентом, команда определяет самую острую проблему разработчиков, решает её минимальными средствами, собирает обратную связь и итерирует. Начали с вики и Terraform-модулей — добавили шаблоны — поставили Backstage — интегрировали мониторинг. Каждый шаг приносит ценность и валидируется пользователями. Шаблоны на этом пути становятся golden paths — рекомендуемыми маршрутами, по которым разработчики могут пройти без помощи платформенной команды.

Продуктовые практики для платформ

Платформа — продукт, и команда применяет продуктовые практики. Вот четыре, без которых не обойтись.

Исследование пользователей

Пользователи платформы — разработчики компании. С ними нужно разговаривать. Регулярные интервью (раз в две недели с разными командами), опросы удовлетворённости (раз в квартал), анализ тикетов поддержки — источники данных о реальных потребностях. Фичи «которые наверное нужны» строить не стоит. Стоит строить то, что разработчики просят и что данные подтверждают как проблему.

CNCF TAG App Delivery описывает ключевые персоны платформы: разработчик приложений (основной пользователь), SRE/ops-инженер (продвинутый пользователь), тимлид (заинтересованное лицо). У каждой персоны свои потребности: разработчику нужен self-service, SRE — наблюдаемость и контроль, тимлиду — метрики и compliance.

Roadmap и приоритизация

У платформенной команды есть roadmap, как у любой продуктовой команды. Бэклог приоритизирован по impact-у: какая фича снимет самую большую боль у самого большого числа разработчиков? Roadmap публичный — разработчики видят, что планируется, и дают обратную связь. Без roadmap платформенная команда скатывается в реактивный service desk и тушит пожары.

Онбординг и документация

Первые пять минут использования платформы определяют, вернётся ли разработчик. Хороший онбординг — это getting started guide, который за 10 минут приводит к работающему результату: создал сервис, задеплоил, увидел в мониторинге. Документация живёт рядом с платформой (TechDocs в Backstage, корпоративная вики) и обновляется с каждым релизом.

Метрики продукта

Как платформенная команда измеряет свой успех? Три категории метрик.

Adoption. Какой процент команд использует платформу? Какой процент новых сервисов создаётся через golden paths? Adoption не растёт — есть проблема с ценностью или с discoverability.

Satisfaction. Как разработчики оценивают платформу? NPS, CSAT или кастомный developer satisfaction survey. Gartner зафиксировал, что 85% компаний с platform engineering отмечают зависимость разработчиков от платформы — но зависимость и удовлетворённость — разные вещи.

Efficiency. Сколько времени уходит на задачу с платформой vs без неё? Time-to-first-deploy, время провижининга инфраструктуры, количество тикетов в ops-команду. По данным того же Gartner, 71% зрелых платформенных команд отмечают ускорение time-to-market.

Антипаттерны

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

«Платформа ради платформы». Команда строит платформу, потому что «так все делают» или «Gartner сказал». Без конкретной проблемы, которую решает платформа, выходит дорогое упражнение в CV-driven development.

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

«Ivory tower platform». Платформенная команда строит то, что сама считает правильным, без разговоров с разработчиками. Разрыв между тем, что платформа предоставляет, и тем, что разработчикам нужно, растёт с каждым спринтом.

С чего начать

Внедрение platform-as-a-product подхода удобно разбить на три шага. Первый: пять интервью с разработчиками из разных команд и список самых частых проблем с инфраструктурой. Второй: одна проблема, которую можно решить за две недели — это будет TVP. Третий: показать результат остальным командам, собрать обратную связь и добавить в roadmap следующую итерацию. Через три месяца получится либо работающая платформа с реальными пользователями, либо понимание, что организации платформа пока не нужна. Оба результата ценны.