Переход на платформу внутренней разработки (IDP) не только ускоряет релизы и сокращает число ошибок. В процессе компания обычно преодолевает немало трудностей — от не стыкующихся друг с другом сервисов до открытого неприятия новшества командой. Некоторые можно успешно преодолеть, отладив коммуникации и четко сформулировав правила. Другие остается просто принять как данность и учесть при планировании.
Внутренние платформы разработки (Internal Developer Platform, IDP) — растущий тренд, и все большее число крупных компаний выбирает для себя именно этот путь. Сервисы и инструменты, которые подойдут для реализации IDP, отличаются разнообразием. А вот проблемы, с которыми сталкивается бизнес, остаются типовыми. Хотя каждая компания зачастую вынуждена заново изобретать велосипед в поисках их решений.
Рынок внутренних платформ разработки растет на фоне практического запроса бизнеса на ускорение разработки и упрощение внутренних процессов. Компаниям важно сокращать time-to-market, снижать зависимость от дефицитных DevOps-специалистов и выстраивать управляемый внутренний контур с учетом требований безопасности и комплаенса — на это обращает внимание генеральный директор HDTech Владимир Вощук.
Рост интереса к внутренним платформам разработки связан не только с трендом на автоматизацию, но и с усложнением самой разработки и инфраструктуры. Как отмечает руководитель продукта GitFlic «Группы Астра» Кирилл Довгаль, IDP в первую очередь решает задачу объединения разрозненных инструментов и процессов в единый контур, формируя общий стандарт разработки и повышая управляемость жизненного цикла ПО.
Топ-5 российских внутренних платформ разработки (IDP). Структура баллов
Подробнее: Обзор «Платформы автоматизации разработки ПО (IDP) 2026»
Проблемы создателей IDP можно разделить на несколько групп:
- трудности систематизации — излишне жесткая унификация сулит бизнесу немало проблем, как и недостаточно четко определенные правила игры;
- технологические сложности — от не стыкующихся с новыми сервисами старых приложений до ошибки в какой-то одной настройке IDP, которая может буквально обрушить все;
- поиски идеального баланса между затраченным временем и бюджетом;
- все оттенки трудностей коммуникации в командах разработчиков — от недопонимания до саботажа.
Разберем каждую из них чуть более подробно.
Систематизация в IDP — в поисках баланса между унификацией и гибкостью
Чтобы конкретная IDP была эффективна для конкретной компании, она должна полностью отвечать ее потребностям. Бизнесу платформа внутренней разработки, в конечном итоге, нужна, чтобы сократить расходы, время до новых релизов и количество ошибок, вызванных слишком большим стеком используемых технологий.
Но в процессе разработки придется неизбежно учитывать потребности всех вовлеченных команд:
- непосредственно разработчиков;
- DevOps;
- ответственных за информационную безопасность;
- ответственных за покупку лицензий и прочее IT-обеспечение.
Добиться стопроцентной удовлетворенности каждого подразделения новой платформой — практически невыполнимая задача. Иногда их интересы прямо противоречат друг другу. Например, разработчики заинтересованы, чтобы число инструментов внутри IDP увеличивалось как можно быстрее, а ИБ-департамент отдает предпочтение нескольким проверенным вдоль и поперек решениям и не торопится «давать добро» на новые.
На практике это противоречие усиливается тем, что IDP одновременно выступает и инструментом стандартизации, и способом скрыть сложность современных стеков. Директор по техническому развитию платформы «Сфера» (Т1) Александр Степчков говорит, что платформа становится «единым центром управления», который позволяет работать с микросервисной архитектурой и разнородными инструментами без ручной координации между командами.
Важно привлекать к выбору итогового технологического стека и разработке правил представителей всех команд, стараясь по максимуму учитывать их запросы.
Вторая проблема, связанная с конфигурацией самой IDP, — поиск баланса между жесткими правилами и свободой творчества. Здесь возможны две крайности:
- Недостаточно унифицированные регламенты и контроль процесса со стороны платформы. В этом случае желаемый эффект сокращения времени разработки и уменьшения количества ошибок не будет достигнут.
- Слишком жесткое «закручивание гаек». Все процессы настолько регламентированы, что разработчикам остается свобода действий лишь в нескольких фрагментах кода. Тогда специалисты будут массово действовать в обход платформы, например, делать все через свой API с интеграцией через OAuth.
При этом чрезмерная жесткость правил часто дает обратный эффект. «Платформа должна предлагать самый простой и безопасный способ выполнения задач, но не превращаться в диктатуру», — отмечает Александр Степчков.
И как говорит Владимир Вощук: «Для заказчика важнее не количество функций, а понятный эффект в ежедневной работе».
Результат использования любого из этих сценариев не будет отвечать потребностям бизнеса. Так, если IDP предлагает разработчикам слишком много решений, увеличиваются также:
- загрузка технической поддержки, ведь к каждому из них надо как минимум написать актуальный гайдлайн и оперативно отвечать на вопросы разработчиков;
- бюджет проекта за счет расходов, связанных с поддержкой.
Если же указать только один путь из пункта А в пункт Б, выбрав кратчайший вариант, неизбежны проблемы уже технологического характера.
IDP и конфликт технологий
Создание внутренней платформы — шаг, к которому обычно приходят компании с большим пулом уже имеющихся проектов и приложений. Именно при их переносе на IDP возникает больше всего сложностей. Если приложение было сделано способом X, а теперь его надо «обточить» под правила Y, это напоминает попытки впихнуть куб в круглое отверстие.
Чтобы избежать лишних трудозатрат и расходов, компании переводят такие приложения на платформы без спешки, при необходимости корректируя правила. Или оставляют как есть, разворачивая на платформе только новые разработки с нуля.
Проблема возрастающей цены ошибок на IDP не обходит стороной ни старые, ни совершенно новые приложения и сервисы. Унификация политик и правил в разработке нужна, чтобы избежать неточностей, которые может случайно добавить в процесс каждый его участник. Однако наличие IDP вовсе не гарантирует, что они исчезнут полностью. Число самих промахов становится меньше, но последствия могут быть куда более серьезными. Например, иногда ошибка при настройке одного сервиса, используемого на IDP, автоматически «ломает» все новые релизы компании. В таких условиях бизнесу приходится по максимуму сосредотачивать усилия на тестировании — проверять и перепроверять каждый шаг. А это, в свою очередь, переводит возможные проблемы при внедрении IDP на новый уровень.
Время и расходы: что сокращается, а что — растет
Основная цель IDP — уменьшить время между новыми релизами. Но в первые месяцы после запуска все происходит наоборот — оно увеличивается. На первом этапе команда будет осваивать утвержденный стек технологий, учиться следовать политикам и правилам, а также заваливать вопросами платформенную команду и тестировать особенности сочетания выбранных инструментов В одних компаниях этот период длится несколько месяцев. Другие в процессе понимают, что нужны серьезные доработки платформы, поэтому он вполне может растянуться и на несколько лет.
При этом сложности внедрения связаны не только с технологиями, но и с внутренними изменениями в компании. Переход на IDP затрагивает процессы и зоны ответственности команд, требует организационной зрелости и согласованности, а также осложняется дефицитом специалистов и необходимостью интеграции с уже существующим, часто неоднородным ИТ-ландшафтом — такие ограничения выделяет Владимир Вощук.
Чем больше итоговый вариант будет отличаться от представленных на рынке готовых решений по набору функций, тем больше будет и сумма в бюджете. Такие расходы оказываются непомерно высокими для малых команд разработчиков — до 50 человек в штате. Для них использование IDP таит еще одну опасность — унификация и систематизация платформы «убивает» креативность стартапа, лишая его важного преимущества по сравнению с уже устоявшимся бизнесом. При этом миграция на внутреннюю платформу разработки большинству коллективов и так дается нелегко.
Почему команду «штормит» при переходе к IDP и что с этим делать
Мотивация команды и внутренние конфликты — еще один камень преткновения бизнеса при миграции на внутреннюю платформу разработки. Опытные разработчики нередко встречают в штыки саму идею и добавляют сложностей при переезде.
Во многом это объясняется тем, что речь идет не только о технологиях. «Переход на IDP — это не техническая, а культурная трансформация», — подчеркивает Александр Степчков.
Пытаться унифицировать причины сопротивления команды было бы большой ошибкой. Вот лишь некоторые возможные мотивы:
- Привычка и сопротивление. Ранее каждая микрокоманда разработчиков самостоятельно выбирала инструменты и по сути была абсолютна свободна в этих решениях. Ограничения, даже если они во благо, вряд ли сразу найдут поддержку.
- Непонимание и раздражение от новых регламентов. Переход к IDP — дело не одного месяца. В течение этого периода у команды будет неизбежно возникать множество вопросов и возражений. От того, как компания будет их отрабатывать, во многом зависит отношение к IDP.
- Перераспределение командных ролей. Каждая команда, работающая над отдельной задачей, ранее была изолирована в рамках своего подразделения и по-своему выстраивала взаимодействие с соседними юнитами. Теперь необходимо вывести эти стихийные коммуникации на новый уровень.
- Опасения и взгляд в будущее. В некоторых случаях попытки унификации процедуры разработки вызывают у специалистов сомнения в собственной нужности компании в дальнейшем.
В преимуществах перехода к внутренним платформам часто отмечают, что они облегчают процесс онбординга для новичков. Но прежде такое вводное обучение понадобится провести абсолютно для всей команды. Максимально открытая коммуникация по каждому шагу и вовлеченность администрирующей команды должны снизить градус напряжения.
В некоторых компаниях, помимо ответственной за разработку платформы команды, выделяют также команду вовлечения или enabling team. В ее задачи входит как раз обеспечение максимально гладкого перехода на IDP для всех участников процесса. Если нужно, сотрудники команды вовлечения практически за руку проводят каждого разработчика по его первому проекту в рамках IDP.
Главное в IDP — баланс
Его приходится искать буквально в каждом аспекте внедрения платформы. Предоставить разработчикам максимум свободы или ограничить по полной, внедрять IDP только для новых приложений или перетаскивать туда и старые, всей командой теряя нервные клетки? Наконец, как найти идеальное соотношение трудозатрат платформенной команды и бюджета на создание и внедрение IDP? От ответов на эти вопросы во многом зависит успех перехода на внутреннюю платформу разработки в конкретной компании.
На практике компании все чаще приходят к итерационному подходу — внедряют платформу поэтапно, адаптируя ее под реальные процессы и постепенно объединяя инструменты в единый контур. Такой подход, как отмечает руководитель продукта GitFlic «Группы Астра» Кирилл Довгаль, позволяет снизить сопротивление команд и ускорить достижение практического эффекта от IDP.
Поделиться
