Что мы увидим, если посмотрим на монитор разработчика в разгар рабочего дня? Там наверняка будет открыта IDE, Git, таск‑трекер, документация, корпоративный мессенджер. И еще какая‑нибудь мелочевка — в зависимости от того, что принято в команде.
И всегда понятно, что из этого зачем нужно. Код было неудобно хранить — появился Git. Проект стало долго собирать и проверять вручную — автоматизировали сборку и тесты. Понадобилось следить за тем, что происходит с сервисами после релиза, — появились системы мониторинга. Инфраструктура стала слишком сложной, чтобы каждый разработчик разбирался с ней самостоятельно, — начали появляться внутренние платформы.
Вот в этом и проблема — сложно найти инструмент, который можно взять и выкинуть из рабочего процесса без потерь. Каждый что‑нибудь полезное да делает.
В Stack Overflow Developer Survey 2025 разработчиков впервые попросили посчитать, сколько отдельных инструментов они используют в работе. Из 27 378 ответивших 54% назвали шесть и более приложений или платформ. Операционная система и браузер в этот подсчет не входили. Для сайд‑проектов картина оказалась несколько другой — 65% из 25 391 разработчика используют пять инструментов или меньше.
Согласитесь, шесть инструментов — не так уж много. Особенно если учесть, что речь, вообще‑то, идет про современную разработку.
Но тогда возникает еще более интересный вопрос — в какой момент сам по себе полезный набор инструментов начинает сам мешать работе? В количестве ли дело или, может быть, в том, что разработчику приходится постоянно переключать внимание между несколькими системами для решения одной задачи?
Вот вам типичная задача
Разработчику нужно выкатить небольшое изменение в прод. Скажем, поправить логику одного API‑метода. Он открывает IDE, меняет код и запускает локальные тесты. На этом первая часть работы заканчивается — и начинается путешествие по остальному набору инструментов. Код нужно отправить в Git, пройти проверку, собрать, развернуть, а потом еще и убедиться, что ничего не сломалось.
Для каждой микрозадачи — свой инструмент. Проверка изменений нужна, чтобы код не попадал в основную ветку без ревью. Автоматическая сборка и тесты экономят время команды. Мониторинг позволяет быстро понять, что произошло после релиза. Документация хранит информацию, которую иначе пришлось бы каждый раз искать у коллег.
И правда в том, что такие инструменты действительно снижают нагрузку на разработчиков. Мы добавляем инструмент, чтобы убрать одну рутинную операцию. Потом добавляем еще один, чтобы автоматизировать следующую. Например, нам не нужно вручную собирать приложение, заходить на сервер по SSH и проверять десяток параметров после каждого коммита. В результате отдельные действия действительно становятся проще.
А вот сама рабочая среда — сложнее.
Проблема — в переключениях
Помните, чуть выше мы говорили о том, что более половины разработчиков используют шесть и более инструментов? Много это или мало? Да и говорит ли вообще о чем‑то само количество используемых тулзов?
Можно иметь десять систем и почти не замечать их, если они работают как единый конвейер. А можно иметь четыре, между которыми приходится таскать информацию вручную и каждый раз вспоминать, где лежит нужный кусок контекста.
И вот эта постоянная беготня между вкладками и окнами отъедает самый ценный ресурс — время.
В исследовании Atlassian State of Developer Experience 2025 приводятся вот такие интересные цифры — на написание кода у программистов уходит всего 16% рабочего времени. При этом половина опрошенных теряет из‑за неэффективностей 10+ часов в неделю.
Главные пожиратели времени, по версии Atlassian, — это поиск информации, освоение новых технологий и, собственно, переключение между инструментами.
То есть проблема не в том, что систем много. Проблема в стоимости перехода между ними.
И речь не только про очевидную трату времени вроде ожидания загрузки страницы документации. При переключении разработчик вынужден каждый раз заново восстанавливать в голове контекст — что именно мы сейчас проверяем, зачем открыли эту вкладку, какой объект ищем и что делать с результатом.
Конечно, от лишней сложности хочется избавиться. Но просто посносить половину софта и уйти в монастырь Vim не получится — каждый из этих инструментов объективно нужен. Задачка получается со звездочкой — не уменьшить количество систем, а сделать так, чтобы разработчику не приходилось вручную склеивать их в единый процесс.
Если инструментов много, спрячем их
Казалось бы, решение простое — давайте оставим одну систему вместо десяти.
Однако покупать (или делать) гигантский корпоративный «комбайн», который пытается уметь все сразу, обычно плохая идея. Такие системы нередко получаются неповоротливыми. Получается, специализированные инструменты под капотом все равно нужны. Вопрос лишь в том, кто должен в них копаться. Индустрия решила — пусть это будет кто угодно, только не рядовой разработчик. Поэтому компании начали искать способ оставить специализированные инструменты под капотом, но дать разработчику единый интерфейс для типовых операций. На этом и строится современный подход к platform engineering.
По сути, они представляют собой внутренние платформы, которые дают разработчикам возможность рулить стандартными процессами, но прячут от них часть инфраструктурной сложности. По данным DORA за 2025 год, 90% организаций уже их используют, а в 76% есть выделенная команда, которая этим занимается.
Допустим, разработчику нужно создать новый сервис. Можно выдать ему доступы ко всем нужным системам. А можно все это заменить одной кнопкой — «Создать сервис».
Платформа сама создаст ресурсы, подключит стандартный процесс сборки и применит нужные политики. Сложность системы и сложность работы с ней — не одно и то же. Инфраструктура может быть очень сложной, но разработчику не обязательно обо всем этом знать.
Ловушка абстракций
Но и у platform engineering есть своя ловушка.
Если просто поставить еще один слой поверх существующего набора инструментов, сложность никуда не исчезнет. Она переместится внутрь платформы. А иногда добавится еще и новая точка трения — разработчику придется взаимодействовать уже не с инструментом, а с командой, которая эту платформу поддерживает.
Та же DORA обнаружила пару лет назад забавный эффект. В исследовании 2024 года использование внутренних платформ было связано с ростом индивидуальной продуктивности, но при этом частота релизов и их стабильность снизились. А еще, согласно тому же исследованию, когда разработчики могли самостоятельно выполнять задачи на протяжении всего жизненного цикла, не обращаясь за помощью к отдельной команде, продуктивность была примерно на 5% выше.
То есть хорошая платформа — это не просто единая точка входа. Она должна уменьшать количество зависимостей, которые разработчику приходится координировать самостоятельно.
Может, мы вообще не там ищем проблему?
До сих пор мы говорили об инструментах так, будто их количество — хотя бы приблизительный показатель сложности. Но считать окна или приложения — дело неблагодарное.
Разработчик может использовать десятки систем и почти не думать о большинстве из них. CI сам запускает проверки, деплой проходит по стандартному сценарию, мониторинг собирает данные автоматически, а внутренняя платформа дает готовый способ создать сервис.
А иногда проблема возникает уже с двумя‑тремя инструментами, если между ними нет нормального взаимодействия.
То есть количество само по себе мало что объясняет. А часть этой сложности вообще не связана с самими инструментами.
Разработчик переключается между системами, потому что так устроен процесс команды. Ищет информацию, потому что документация разбросана по нескольким местам. Ждет согласования. Разбирается с легаси. Выясняет, почему деплой не прошел, и только потом обнаруживает, что проблема вообще не в коде.
Инструменты в такой ситуации — просто интерфейс, через который эта организационная сложность проявляется. Подсчет их количества просто теряет смысл. Гораздо важнее оценить объем лишней работы между двумя осмысленными шагами. Например, между написанием кода и его реальным запуском в продакшене.
Если для этого достаточно сделать коммит и нажать одну кнопку, набор инструментов может быть огромным, это одно. Если же приходится вручную искать информацию, копировать параметры, переключаться между системами и ждать согласований, использование даже пары приложений — уже серьезное препятствие и стресс.
Вот так мы начали разговор про количество софта, а пришли к Developer Experience. Ведь цель инженерного инструментария не в том, чтобы у разработчика было как можно меньше приложений. Цель в том, чтобы между постановкой задачи и ее результатом было как можно меньше ненужного трения.
Сколько вешать в штуках?
Так сколько инструментов достаточно? Увы, универсального ответа здесь нет и не будет.
Шесть инструментов могут быть абсолютно нормальным рабочим окружением. Десять — тоже. Важно вообще не количество, а то, сколько работы приходится делать человеку, чтобы заставить эти инструменты работать вместе.
Для одних Kubernetes, Terraform, GitHub, Grafana и десяток других систем — нормальный и хорошо отлаженный процесс. Для других тот же набор превратится в бесконечное переключение между консолями, тикетами и чатами.
Поэтому считать количество приложений — занятие бессмысленное. Гораздо важнее оценить, сколько систем приходится открывать для одной обычной задачи и сколько раз за это время теряется нить.
Если захотите поделиться — расскажите в комментариях, как выглядит ваш типичный путь решения какой‑либо рабочей задачи, как много инструментов вы используете и как боритесь с необходимостью постоянного возврата в актуальный контекст.
