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-ассистентом, вы определяете самую острую проблему разработчиков, решаете её минимальными средствами, собираете обратную связь и итерируете. Начали с wiki и 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, wiki в внутренней системе) и обновляется с каждым релизом.

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

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

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 следующую итерацию. Через три месяца у вас будет работающая платформа с реальными пользователями — или понимание, что вашей организации платформа пока не нужна. Оба результата ценны.