Почему внутренняя платформа влияет на эффективность, стабильность поставки и масштабирование ИИ в разработке ПО.
5.12.2025 Эта публикация - адаптированный перевод отчёта «2025 State of AI-Assisted Software Development» от Google Cloud и DORA. Оригинал доступен по ссылке. Время на прочтение: 9 мин. Эта глава подготовлена при участии: Eric Maxwell - руководитель направления 10x Technology, Google Cloud Benjamin Good - руководитель платформенной инженерии, Google Cloud
В отчете 2024 года мы начали изучать, как внутренние платформы влияют на эффективность поставки ПО.
Тогда данные показали: платформы повышают результативность организации и продуктивность команд, но одновременно увеличивают нестабильность поставки и снижают пропускную способность. В исследовании этого года мы вышли за рамки констатации пользы платформенной инженерии и сосредоточились на том, как успешные платформы реально работают.
Результаты показывают: платформа - это не набор инструментов, а целостный пользовательский опыт, который напрямую влияет на эффективность, устойчивость и способность организации использовать новые технологии.
Пользователи воспринимают платформу как единое целое, и общая согласованность этого опыта важнее качества отдельных функций. В этой главе разобраны ключевые закономерности развития платформенной инженерии: широкое распространение практики, изменения в командных структурах и роль платформ как стратегического фундамента для инноваций и управления рисками.
Платформы стали стандартом: уровень внедрения - около 90%. 76% компаний используют выделенные платформенные команды.
Задача меняется: важна не сама адаптация, а управление многокомандной платформенной средой.
Качество платформы усиливает влияние ИИ на результаты организации.
Чем выше качество, тем заметнее эффект.
Сильные платформы повышают эффективность, продуктивность и благополучие команд.
Платформа - целостный продукт, который должен обеспечивать качественный опыт разработчика.
Платформа помогает управлять рисками и ускоряет экспериментирование.
Это сопровождается небольшим, но оправданным ростом нестабильности поставки - приемлемый обмен ради более высокой эффективности.
Большинство компаний уже используют внутренние платформы.
90% организаций внедрили хотя бы одну платформу, и почти 30% работают в мультиплатформенной среде. У 76% компаний есть выделенная платформенная команда.
Более четверти респондентов работают там, где таких команд несколько.
Это говорит не о дублировании, а о переходе от универсальной платформы к набору специализированных и федеративных платформ под разные домены и стеки.
Для лидеров задача тоже изменилась.
Теперь важно не просто «иметь платформу», а управлять экосистемой из нескольких платформ.
Это требует принципов слабой связанности между командами, четких границ ответственности и согласованных интерфейсов.
Такая структура помогает платформам работать как единая система, улучшая опыт разработчиков, а не создавая новые организационные барьеры.
Респондентов попросили оценить, насколько хорошо их платформа выполняет разные задачи. Например: «Платформа помогает мне создавать и запускать безопасные сервисы».
Базовые технические возможности - надежность и безопасность - воспринимаются как сильные стороны. А элементы пользовательского опыта - работа с обратной связью, удобство и степень автоматизации - заметно слабее.
Общее впечатление разработчика о платформе - как о партнере, который помогает, или как об источнике трения - сильно влияет на оценку каждой конкретной функции. То, что возможности платформы сгруппированы довольно плотно, показывает: респонденты не воспринимают платформу как набор отдельных компонентов, они ощущают ее как единое целое.
Разрыв в опыте, вероятно, отражает ситуацию, когда технические основы платформы создаются в первую очередь.
Эти данные показывают: пока пользовательский опыт не улучшен, платформа не раскрывает свою полную ценность.
Принятие продуктового подхода к платформе - когда внутренние инструменты разработки рассматриваются как продукты, а разработчики - как пользователи - помогает удерживать фокус на пользователе.
Это ключевой вывод отчета 2024 года.
Ориентация на пользователя помогает избежать распространенных ошибок при создании внутренних платформ для разработчиков. «Построим - и они придут»
Команда создает платформу, исходя из собственных представлений о том, что нужно разработчикам, не проводя исследований, интервью или проверок гипотез.
Они сосредоточены только на технологиях, считая, что ценность будет очевидной сама по себе.
Платформа превращается в «город-призрак»: она не решает реальные проблемы разработчиков или не вписывается в их рабочие процессы.
Продуктовый подход начинается с эмпатии и изучения потребностей разработчиков.
Команда платформы постоянно общается с пользователями, чтобы понимать их основные сложности и создавать то, что действительно нужно.
У них нет видения и дорожной карты, работа полностью реактивная и состоит из бесконечного потока запросов от разработчиков («Создайте базу», «Настройте CI/CD»).
Возникает узкое место, растет нагрузка и на команду платформы, и на разработчиков.
Команда тратит все время на разовые задачи и не успевает создавать целостные, самообслуживаемые возможности.
Продуктовый подход предполагает создание платформы самообслуживания с четкой стратегией.
Цель - убрать очереди тикетов, дав разработчикам инструменты и автоматизацию, позволяющие самостоятельно получать нужные ресурсы. Платформа «слон в башне из слоновой кости»
Центральная команда сверху диктует архитектуру платформы и набор инструментов, устанавливает жесткие стандарты без обратной связи и сотрудничества.
Они выступают «стражами» технологий, а не помощниками разработчиков.
В итоге появляется «теневой ИТ» или неофициальные обходные пути, которые подрывают назначение платформы.
Продуктовый менеджер платформы активно собирает обратную связь, а разработчики рассматриваются как клиенты.
Платформа должна помогать, а не ограничивать: предлагать удобные «золотые пути», которые можно использовать, но не обязательно.
Когда мы рассматриваем возможности платформы и их взаимосвязи, большинство из них коррелируют между собой примерно одинаково. Но две возможности выделяются сильнее остальных. Во-первых, самая связанная с позитивным пользовательским опытом - это понятная обратная связь по выполняемым задачам.
Когда платформа ясно показывает, что задача выполнена успешно или завершилась ошибкой, пользователи чувствуют, что могут действовать дальше:
Во-вторых, «простой и чистый интерфейс»
показывает более слабую корреляцию.
Аккуратный UI может улучшать восприятие, но сам по себе не делает платформу эффективной.
Хотя понятная обратная связь и UI тесно связаны с другими возможностями, по восприятию они остаются среди самых слабых.
Это означает, что улучшать одну возможность отдельно - нерабочая стратегия.
Чтобы улучшить воспринимаемое качество платформы, команды должны относиться к ней как к целостному внутреннему продукту и улучшать весь путь разработчика.
Если платформа технически сильная, но не ориентирована на пользователей (см. отчет DORA 2024), ее нельзя считать успешной.
Платформа высокого качества - в понимании наших метрик - оказывает широкое и статистически значимое позитивное влияние. Она связана с более высокой организационной результативностью, лучшими показателями продукта и ростом продуктивности. В соответствии с предыдущими исследованиями, мы также обнаружили: чем лучше платформа, тем выше небольшой, но достоверный рост нестабильности поставки
ПО - то есть повышается частота отказов изменений и объем переделок. «В целом идея была в том, чтобы делать continuous delivery как можно чаще: если фича попала в main, выкатывай её, запускай, прогоняй тесты - ну, насколько получится, - чтобы поймать проблемы. Но главное - просто выкатывай. И в большинстве случаев это было нормально, потому что даже если что-то ломалось во время деплоя, у нас было много механизмов, которые не давали сайту упасть. То есть деплой мог провалиться, и нам приходилось быстро чинить.
Но сам сайт продолжал работать»
Хорошая платформа работает как усилитель: она напрямую повышает производительность и эффективность.
Небольшой рост нестабильности при этом может быть признаком здоровой высокоскоростной системы - такой, где дополнительные сбои допустимы, пока они не влияют на работу продукта.
Рост эффективности несмотря на рост нестабильности говорит о своеобразной «компенсации риска»: платформа делает откат быстрым и дешевым, команды легче восстанавливаются после ошибок и могут чаще экспериментировать, принимая чуть более высокий уровень мелких сбоев ради скорости.
Небольшую нестабильность стоит рассматривать как управляемый обмен ради значительного прироста производительности.
Улучшения качества продукта, которые дает платформа, вероятно, важнее умеренного роста скорости поставки и небольшого падения стабильности.
Инвестиции в качественную платформу - сильный стратегический рычаг, который дает широкий и устойчивый эффект.
Положительный эффект от внедрения ИИ на эффективность организации напрямую зависит от качества внутренней платформы. Если качество платформы низкое, влияние ИИ почти незаметно. Когда же платформа сильная, эффект становится выраженным и положительным.
Это критически важный вывод для любых руководителей, которые инвестируют в ИИ. «В Wayfair поняли, что наибольший эффект дает не только более быстрое обнаружение ошибок, но и сокращение усилий, необходимых для их исправления. Встраивание ИИ в цикл CI/CD показало: разработчики охотнее всего используют точные, объяснимые рекомендации и автоматически сгенерированные исправления, когда они появляются прямо в тех инструментах, которыми они уже пользуются.»
Высококачественная внутренняя платформа выполняет две ключевые функции, усиливая влияние ИИ на результаты организации. Во-первых, она выступает уровнем распределения и управления, который позволяет масштабировать пользу ИИ - от роста индивидуальной продуктивности к системным улучшениям на уровне всей организации.
Без такой основы внедрение ИИ остается набором разрозненных локальных оптимизаций.
Платформа обеспечивает единый контекст и берет на себя сложные или рутинные аспекты, необходимые для того, чтобы ИИ был полезным и работал в масштабе.
При этом важно учитывать, что ИИ развивается очень быстро.
Не стоит чрезмерно стандартизировать практики, инструменты и методы работы с ИИ, потому что это может ограничить его пользу и способность организации адаптироваться к изменениям. Во-вторых, платформа выступает механизмом управления рисками.
Так как платформа снижает риски и в других областях инженерии, те же эффекты полезны и для внедрения ИИ.
Платформа должна создавать безопасное пространство, где сотрудники могут учиться и экспериментировать.
Это пространство позволяет платформе и её командам быстрее адаптироваться, поддерживать новые модели, способы взаимодействия и подходы к разработке приложений.
Кроме того, независимо от того, написан ли код вручную или с помощью ИИ, к нему применяются те же автоматизированные процессы тестирования и деплоя, что помогает гарантировать безопасность изменений.
Инвестиции в ИИ без параллельных инвестиций в качественные внутренние платформы с высокой вероятностью не дают значимого эффекта на уровне всей организации.
Чтобы получить реальное конкурентное преимущество от ИИ, руководителям нужно рассматривать платформенную инженерию как фундаментальный стратегический инструмент.
Смотрите на платформу целостно Нельзя исправить плохую платформу, улучшив одну-две функции. Относитесь к платформе как к полноценному продукту и работайте над всей «петлёй» опыта разработчика - от обратной связи до автоматизации.
Сделайте платформу фундаментом для ИИ Платформа - стратегическое условие, необходимое для того, чтобы раскрыть ценность ИИ на уровне всей организации. Она - тот самый «движок», который превращает инвестиции в ИИ в конкурентное преимущество.
Используйте платформу, чтобы управлять уровнем риска Хорошая платформа меняет отношение компании к риску: ошибки становятся дешевыми и легко устранимыми. Важно понимать и управлять балансом между скоростью, которую дает платформа, и возникающей из-за этого нестабильностью - при этом помня, что платформа не устраняет локальные последствия риска.
Чтобы понять, как организации превращают ИИ из точечных улучшений в масштабный результат, мы переходим к управлению потоками ценности.
Именно здесь становится видно, почему одни команды получают реальный эффект от ИИ, а другие - теряются в хаотичной активности.
Седьмая часть исследования показывает, что ключевой фактор - не скорость поставки и не набор практик, а умение видеть весь путь создания ценности и управлять им как целостной системой.
Это и есть основа, которая превращает ИИ в конкурентное преимущество, а не в источник дополнительной сложности.
