Про Developer Experience любят говорить, проводя параллели со счастьем. Счастливый разработчик пишет хороший код, остаётся в компании, приводит друзей. Звучит хорошо, продаётся хорошо. Только когда я спрашиваю на интервью «а сколько это счастье стоит и что оно приносит бизнесу», в ответ обычно начинается мычание. Потому что счастье — это маркетинговая обёртка, в которую упаковали DX, чтобы продать его людям с бюджетами. Обёртка свою работу сделала, про DX начали говорить. Но если вы строите стратегию вокруг счастья, то вы почему-то начинаете покупать в офис кресла и фрукты, а пайплайн как собирался 40 минут, так и собирается.

Счастье разработчика — это побочный продукт нормально работающих инструментов. После серии интервью с руководителями разработки из российских компаний — от небольших аутсорсеров до Сбера и Яндекса — и параллельного ковыряния в отчётах Stripe, McKinsey и работах Gloria Mark у меня в голове сложилась мысль, которую я сначала постеснялся произносить вслух: DX — это про деньги, и счастье разработчика идёт прицепом, а компания зарабатывает на скорости и предсказуемости поставки.

Сколько стоит разработчик, которому неудобно

В 2018 году Stripe посчитали, что средний разработчик тратит больше 17 часов в неделю на возню с легаси, дебаг и рефакторинг. Ещё 4 часа в неделю уходят на разгребание чужого плохого кода. 42% оплачиваемого времени, в течение которого человек ничего нового бизнесу не приносит. В мировом масштабе Stripe оценили это в 300 миллиардов долларов недополученного ВВП в год.

Цифра большая и абстрактная, поэтому посчитайте на своей команде. Допустим, у вас 50 инженеров со средней зарплатой 300 тысяч в месяц. 42% от ФОТ — это 75,6 миллиона рублей в год, которые ушли в трение, а не в продукт. Сократите эту долю хотя бы на четверть, и вы освободите бюджет на десяток новых инженеров, никого не нанимая.

С наймом, кстати, тоже проблема. По данным Linux Foundation State of Tech Talent 2024, цикл закрытия технической вакансии в среднем занимает 5,4 месяца. 64% компаний ищут инженера дольше четырёх месяцев. Каждый такой месяц — это незакрытые задачи, сорванные сроки и не отгруженная выручка. DX бьёт в обе стороны: и в продуктивность тех, кто уже в команде, и в скорость, с которой новый человек выходит на полезность.

Что я услышал на интервью

Я разговаривал с людьми, которые рулят командами от 15 до нескольких сотен разработчиков. Общее в этих разговорах одно: словосочетание «Developer Experience» половине из них ничего не говорит, а боли, которые этим словосочетанием описывают, знакомы каждому.

Ту же картину дал опрос, который я провёл в Telegram (240 респондентов). 35% впервые услышали термин в этом опросе. Ещё 9% слышали, но затруднились объяснить, что это. 11% знали, но в их компании DX никто не занимается. Больше половины аудитории не видит DX в своей повседневной работе. Выделенная команда или роль есть всего у 3%.

Боли при этом у всех одни и те же. Пайплайн крутится по полчаса, и за это время разработчик успевает потерять контекст, открыть Хабр и забыть, ради чего он вообще что-то коммитил. Документация полугодовой давности — в неё страшно заглядывать, потому что половина того, что там написано, уже неправда. Новичок на онбординге две недели собирает доступы вместо того, чтобы писать код. Observability нет вообще, поэтому разработчики лезут в поды читать логи руками. Инструменты никто специально не выбирал, они накопились сами и теперь живут вместе как соседи по коммуналке.

Один из моих респондентов сформулировал суть максимально «в цель»: «DX — это про то, насколько тебе дёшево нанимать, обслуживать и развивать продукт. Через точку зрения удобства разработчика». Чистая бизнес-логика, без эфемерики.

Дальше начинается грустное. Разработчики в больших компаниях привыкают к неудобствам и закладывают неэффективность в оценку задач. Выдача базы данных занимает пять дней? Ну ок, заложили в спринт, ни у кого пульс не подскочил. Тимлид спрашивает: «У вас всё нормально?» — «Да, нормально». Потому что формально нормально: задача закрыта в срок, который изначально включал эти пять дней ожидания. Но если разобрать структуру цикла разработки по минутам, окажется, что половина — мёртвое время, которое никто не замечает, потому что все привыкли.

Почему DORA — не ответ

Когда руководитель доходит до вопроса «а как мы это будем измерять», ему первым в голову лезет DORA. Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service. Каждая метрика по отдельности рабочая. Если вы деплоите раз в месяц и не понимаете, почему так редко, Lead Time for Changes покажет, где затыкается. Если после релиза горит продакшн, Change Failure Rate подсветит проблему.

С DORA как со стандартом и базовым фреймворком измерения эффективности я согласиться не готов. Объясню, почему.

Из 18 моих интервью DORA-метрики системно отслеживает один человек. Он же сам признаётся, что у его компании с DORA отношения качельные: внедряли два-три года назад, активно качали, потом фокус ослаб, сейчас на дашборд смотрят раз в месяц для проформы. Остальные респонденты либо не слышали про DORA, либо слышали и прошли мимо. Один из руководителей небольшого аутсорсера на вопрос про DORA ответил без украшений: «Не используем, нет. Мы не суперпродвинутые ребята». Среди интервьюируемых были люди из крупнейших российских банков, маркетплейсов, медиа и инфраструктурных компаний — масштабы и профили разные, картина похожая. На больших конференциях про DORA говорят как про индустриальный стандарт. На уровне практики я этого стандарта не вижу.

Сама DORA не отвечает на вопрос «почему». Если у вас Deployment Frequency упала, причиной могут быть болеющие разработчики, затянувшийся архитектурный спор, пятница перед длинными выходными или баг в CI. Метрика фиксирует следствие, причину каждый раз приходится докапывать руками. Эту претензию я не сам сочинил: отчёт DORA 2024 года сам признаёт, что Change Failure Rate ведёт себя нестабильно и не коррелирует с остальными метриками так, как от неё ждали авторы.

Главное возражение лежит выше. DORA измеряет скорость доставки кода и молчит о том, нужен ли этот код кому-то. Можно деплоить 50 раз в день с Lead Time в 15 минут и при этом пилить функции, которые ни один пользователь не откроет. Все четыре цифры на дашборде будут зелёными, а P&L останется плоским.

Kent Beck и Gergely Orosz в своём разборе фреймворка McKinsey, который надстроен над DORA, написали, что такие фреймворки скорее ломают инженерную культуру, чем чинят её. Я с ними согласен. DORA даёт руководителю иллюзию контроля: он смотрит на четыре цифры на дашборде и думает, что понимает, как работает его разработка, хотя видит только то, как работают эти четыре цифры.

Невидимые потери: 23 минуты за каждое прерывание

Gloria Mark из UC Irvine двадцать лет изучает, как люди переключают внимание. По её данным, после прерывания человек тратит в среднем 23 минуты и 15 секунд, чтобы вернуться к задаче с тем же уровнем погружения. А средняя длительность фокуса на одном экране за двадцать лет упала с двух с половиной минут до 47 секунд.

Кто пишет бэкенд, тот точно знает про переключения контекста и видел график context switches на CPU. Если процессор слишком часто переключается между задачами, он тратит такты не на полезную работу, а на сохранение и восстановление состояния. Нагрузка на ядро растёт, throughput падает. Когда количество переключений уходит в потолок, то нет смысла наваливать на CPU ещё задач, надо разбираться, почему система захлёбывается. С людьми работает тот же принцип, только с поправкой на масштаб: у CPU переключение занимает микросекунды, у разработчика — 23 минуты.

Переложите это на свой день. С утра стендап, потом пинг в мессенджере, потом ревью чужого PR, потом письмо от менеджера. Каждое переключение запускает 23-минутный таймер заново. С виду разработчик занят: IDE открыта, коммиты идут. А глубокая работа, на которой держатся архитектурные решения и сложный код, либо влезает в щели между прерываниями, либо не происходит вообще.

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

Что измерять вместо DORA

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

Time to first commit. Сколько дней проходит от выхода нового разработчика до его первого коммита в продакшн-репозиторий. По моим интервью разброс получился от одного дня до нескольких недель. Каждый день онбординга — оплаченный день без отдачи.

Доля потраченного рабочего времени на инструменты инфраструктуры. Так называемое «инфраструктурное трение» (по-английски называется смешно — Developer Frictions). Сколько процентов рабочего дня разработчик тратит на борьбу с инструментами, а не на написание кода. Stripe в своём отчёте дают 42%. У вас цифра другая, но вы её не узнаете, пока не замерите.

Стоимость инцидента в минутах простоя. И, как следствие, стоимость каждой минуты, сэкономленной за счёт нормального observability.

Cost-to-value платформенной команды. Сколько стоит содержать платформу и сколько она экономит остальным. Один из моих собеседников описывал работу платформенной команды через упрощённый P&L: команда приходит к бизнесу, говорит «у вас сейчас Lead Time 10 дней, дайте нам N денег, мы сократим до 9», и дальше считает экономику этой единицы выигранного дня по всей разработке. Это нормальный продуктовый подход, в котором платформа продаёт себя внутрь компании, а не существует «потому что у нас так принято».

Главный барьер

Самый частый ответ на вопрос «что мешает заниматься DX системно» — нет ресурсов. Второй по частоте — никто не понимает ценность для бизнеса.

Получается замкнутый цикл. DX не получает ресурсов, потому что никто не посчитал, во сколько обходится его отсутствие. Никто не посчитал, потому что в компании нет человека, чья работа — считать. Такого человека нет, потому что бизнес не видит ценности. И бизнес не видит ценности, потому что никто не посчитал.

Этот цикл рвётся в одной точке: вы перестаёте продавать DX через счастье и начинаете продавать его через деньги. Берёте калькулятор. Считаете, сколько стоит час вашего разработчика. Считаете, сколько таких часов уходит в трубу на ожидание выкатки, разбор упавших билдов, поиск нужного куска документации и переключения между задачами. Идёте с этой цифрой к человеку, который распределяет бюджет. С этой стороны разговор обычно становится конкретнее.

Про источники

Все ссылки в этой статье ведут на англоязычные исследования: Stripe, Linux Foundation, DORA, работы Gloria Mark, рассылка Pragmatic Engineer. Русскоязычных исследований по DX я не нашёл — ни одного структурированного отчёта, ни одной попытки посчитать, сколько российскому бизнесу стоит неудобство его собственных разработчиков. Восемнадцать моих интервью и опрос в телеграм-канале — это моя собственная попытка собрать такие данные по российскому рынку. До полноценного отраслевого исследования ей, конечно, далеко.

Что дальше

Параллельно с этой статьёй я запустил Лабораторию DX — открытую базу знаний по Developer Experience на русском: каталог тем, в который заходишь с конкретным вопросом и уходишь с ответом. Сейчас там 15 разделов — от того, что вообще такое DX и как его измерять, до Internal Developer Platforms, когнитивной нагрузки и AI-assisted разработки. Метрики, кейсы внедрения, ссылки на первоисточники, разбор фреймворков — всё в одном месте.

Если вы занимаетесь DX в своей компании, у вас есть кейсы, цифры или метрики, которыми можно поделиться — давайте пообщаемся. Мой e-mail: andrey@sinits.in

Ну и всякое интересное я пишу у себя в ТГ: https://t.me/boombah_in_da_house