Почему ваша внутренняя платформа ощущается как проект, который никто не хочет использовать

Через несколько месяцев после запуска начинаются жалобы. «Пайплайн слишком жесткий». «Мы не можем получить доступ к базе данных, который нам нужен». «Стейджинг не соответствует продакшену». Команда, построившая платформу, чувствует разочарование. Они все задокументировали. Они предоставили стандартные пайплайны. Они думали, что работа сделана. Но продуктовые команды находят обходные пути, пишут собственные скрипты и тихо покидают платформу.

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

Ловушка проектного мышления

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

Это предположение почти всегда ошибочно.

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

Отношение к платформе как к внутреннему продукту

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

Продуктовая команда не создаёт функции на основе предположений. Они общаются с пользователями, собирают данные и итерируют на основе обратной связи. Команда платформы должна делать то же самое. Им нужно понимать, что замедляет разработчиков. Какие части процесса разработки причиняют больше всего боли? Какие пайплайны чаще всего падают и почему? Какие окружения вызывают больше всего трения?

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

Как продуктовое мышление выглядит на практике

Команда платформы с продуктовым подходом делает несколько вещей иначе.

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

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

Сложная часть: смена организационного мышления

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

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

Это также требует поддержки со стороны организации. Команде платформы нужно разрешение тратить время на исследования, сбор обратной связи и итерации. Их нужно оценивать по результатам, таким как скорость разработки и внедрение платформы, а не только по тому, сдали ли они портал в срок.

Когда платформа не адаптируется

Без продуктового подхода платформа становится узким местом. Разработчики чувствуют себя ограниченными жёсткими процессами, которые не подходят под их конкретные нужды. Они начинают обходить платформу, что создаёт несогласованность между командами. Одни команды используют стандартный пайплайн, другие — кастомные скрипты, а некоторые вообще не используют автоматизацию. Когнитивная нагрузка, которую платформа должна была снизить, на самом деле возрастает, потому что теперь разработчикам приходится изучать и платформу, и обходные пути.

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

Практический чекист для команд платформы

Если вы строите или сопровождаете внутреннюю платформу, вот короткий чекист, чтобы оставаться честными с собой:

• Знаете ли вы, какие команды используют вашу платформу, а какие избегают ё?
• Можете ли вы назвать три главные точки трения, с которыми сталкиваются разработчики при использовании вашей платформы?
• Есть ли у вас регулярный цикл обратной связи с пользователями, а не просто ящик для предложений?
• Измеряете ли вы внедрение и скорость разработки, а не только аптайм и количество функций?
• Есть ли у вас бэклог, который приоритизирует улучшения на основе влияния на пользователей?
• Когда команда обходит вашу платформу, вы исследуете, почему, или вы вините их?

Если вы не можете ответить «да» на большинство этих вопросов, вы, вероятно, ведёте проект, а не продукт.

Вывод

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