Platform as a Product

Самый честный вопрос к внутренней платформе звучит грубо: если завтра команды перестанут быть обязаны ею пользоваться, сколько из них останется? Я регулярно вижу платформы, у которых честный ответ — «ни одной». Это не приговор инженерам, которые её строили. Это диагноз способа принятия решений: возможности выбирались из того, что было интересно или очевидно команде платформы, а не из того, за чем к ней приходят. Обязательность маскирует такую платформу годами, пока кто-нибудь не начнёт считать, во сколько она обходится.

Platform as a Product — способ управлять внутренней платформой как продуктом: у неё есть сегменты пользователей, владелец, roadmap, обратная связь и правила удаления невостребованного. Отличие от Stakeholder Management в объекте: там отношения с людьми вокруг сервиса, здесь продуктовые решения о наборе возможностей. От Toil Automation отличие ещё жёстче: автоматизация убирает ручную работу, а платформа обязана ещё и сохранять поддерживаемый интерфейс к результату этой автоматизации.

Что должен уметь

Лист начинается с L4, потому что продуктовые решения о платформе требуют доступа к пользователям и права сказать «нет». Главный навык на уровне L5 — обосновать отказ: почему возможность не берётся сейчас и что должно измениться, чтобы взялась. Платформа без внятных отказов набирает возможности до состояния, когда её невозможно ни поддерживать, ни объяснить.

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

Ведёт roadmap платформы и обосновывает отказы; решение «не делаем» фиксируется вместе с условием пересмотра.
Проектирует границу возможности: что платформа гарантирует, что остаётся за командой и где проходит документированный путь отклонения от типового.
Вводит правило удаления невостребованного: срок, миграционный путь, владелец переезда. Возможность без потребителя стоит денег и внимания, даже когда «просто лежит».
Считает спрос по реальному использованию и доведённым до конца сценариям, а не по числу созданных шаблонов и подключённых репозиториев.

L6+

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

Материалы

Книги

Matthew Skelton, Manuel Pais — Team Topologies (IT Revolution, 1-е изд. 2019, 2-е изд. 2025). Читать ради двух вещей: platform team как один из четырёх типов команд и thinnest viable platform. Вторая идея полезнее первой, потому что прямо противостоит желанию сделать платформу побольше. Во втором издании авторы отдельно уточняют, что platform team корректнее понимать как platform grouping, а не как одну команду.
Matthew Skelton, Manuel Pais — Key concepts (teamtopologies.com). Короткая бесплатная выжимка, если книгу читать некогда: platform team там определена как «a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams», а TVP — как способ дать ровно столько возможностей, сколько нужно, без лишней сложности.

Статьи и документация

Evan Bottcher — What I Talk About When I Talk About Platforms (martinfowler.com, март 2018). Короткая статья с определением, которое стоит держать под рукой: платформа как «foundation of self-service APIs, tools, services, knowledge and support», собранный в убедительный внутренний продукт. Слово «compelling» здесь несёт основную нагрузку.
CNCF TAG App Delivery — Platforms White Paper. Определяет платформу через нужды её пользователей и прямо говорит, что платформа развивается по тем же правилам, что и остальные программные продукты. Отдельная ценность — раздел про измерение успеха, где итоговым мерилом названы результаты продуктов организации, а не показатели самой платформы.
CNCF TAG App Delivery — Platform Engineering Maturity Model. Пять аспектов: Investment, Adoption, Interfaces, Operations, Measurement. По моим наблюдениям, его чаще используют как чек-лист «докуда мы доросли», хотя полезнее его предупреждение: верхний уровень зрелости не самоцель, каждый следующий требует больше денег и людского времени.
Spotify Engineering — How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (август 2020). Самый полезный публичный текст про то, как платформа удерживает пользователей без принуждения.

Инструменты

Каталог возможностей платформы — минимальный обязательный инструмент: что предлагается, кто владеет, в каком статусе, куда идти. Я вижу, что чаще это начинается страницей в вики и живёт так дольше, чем предполагали, и это нормальная стадия: каталог ценен содержимым, а не движком.
Internal Developer Portal (Backstage, Port, Cortex) — интерфейс к каталогу и к действиям. По моим наблюдениям, портал берут, когда каталог уже перестал помещаться в вики и появился второй сегмент пользователей; до этого он даёт красивую витрину пустого магазина.
Каналы обратной связи — регулярные разговоры с командами и разбор ухода с платформы. Опросы удовлетворённости здесь я считаю слабейшим из работающих инструментов: они показывают настроение, но почти никогда не показывают, на каком шаге путь ломается.

Best practices

Публичный случай, на который я ссылаюсь чаще других, — golden paths в Spotify. Показателен там не сам факт типовых путей, а правило вокруг них: разработчик может сойти с golden path и делать по-своему, но тогда не получает той же поддержки. «Blessed» инструменты видны в Backstage, так что выбор остаётся, а стоимость выбора становится явной. Это ровно продуктовая логика: платформа выигрывает конкуренцию за пользователя, а не назначается ему.

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

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

Тонкая платформа побеждает толстую. Из Team Topologies я беру в первую очередь thinnest viable platform: ровно столько возможностей, сколько командам хватает, и ничего сверх. Авторы прямо предупреждают, что внутренние платформы чаще раздуваются и начинают замедлять команды вместо того, чтобы их ускорять. Соблазн всегда обратный. Добавить ещё одну штуку, раз она «почти готова». По моим наблюдениям, платформы умирают не от недостатка возможностей, а от стоимости сопровождения того, чем пользуются две команды из тридцати.

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

Связанные листья

Golden Paths — самый заметный для пользователя результат продуктовых решений: конкретный поддерживаемый маршрут и цена схода с него.
Team Topologies — организационная сторона: platform team как тип команды и режим взаимодействия с потребителями. Здесь — что именно она поставляет.
Toil Automation — источник большинства первых возможностей платформы; разница в том, что у платформы автоматизация обязана иметь поддерживаемый интерфейс и владельца.
Service Ownership — данные о владении сервисами; каталог платформы отражает этот источник истины, а не заводит второй.
Stakeholder Management — как договариваться с теми, кто платит за платформу и чьи команды ею пользуются.
Cloud Cost Control — стоимость платформы и её возможностей; без неё разговор про удаление невостребованного упирается в «пусть лежит, есть не просит».

Открытые вопросы

Как измерять реальное внедрение, когда у платформы нет альтернативы по объективным причинам (единственный кластер, единственный способ выкатки)? Я не знаю честной метрики для этого случая: подключения растут, а сигнала о качестве в них нет.
Нужен ли отдельный лист Developer Experience, или измерение опыта остаётся частью Platform Adoption & Measurement.
Как считать стоимость возможности, которой пользуются редко, но в критический момент — тот же вопрос, что и со стоимостью самой возможности иметь сигнал в Telemetry Economics.