Опыт разработчика: что измерять и как это делать честно

Платформенная команда из шести человек показывает на квартальном ревью дашборд. Средняя оценка платформы в опросе — 4,4 из 5. Доля сервисов на золотом пути — 71 %. Среднее время сборки — 15 минут. Количество деплоев выросло на 34 % за квартал. Все графики зелёные, руководитель доволен, команде согласуют ещё двух инженеров.

В тот же день в чате продуктовой команды идёт другой разговор: «У нас релиз в среду, я вчера три раза перезапускал пайплайн из-за флаки-теста, потом ждал 50 минут, потом оказалось, что шаблон сервиса не умеет отдавать метрику с кастомным лейблом, и мы сделали свой деплой-скрипт мимо платформы». Эта команда не отвечала на опрос — им некогда. В телеметрии платформы их деплой-скрипта не видно: события шлёт только штатный путь. В числителе метрики «доля на золотом пути» их нет, а в знаменателе — тоже нет, потому что знаменатель считается по сервисам, зарегистрированным в каталоге платформы.

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

Что такое опыт разработчика и почему это не «удобство»

Слово «удобно» бесполезно как инженерный термин: оно не операционализируется. Рабочее определение:

Опыт разработчика (DX) — это суммарная стоимость выполнения типового рабочего действия для инженера продуктовой команды: время ожидания, объём того, что нужно держать в голове, и неопределённость результата.

Три составляющие берутся не с потолка. Это ровно три измерения из работы Ноды, Стори, Форсгрен и Грейлер «DevEx: What Actually Drives Productivity» (ACM Queue, 2023):

Полезность этой рамки в том, что она разделяет вещи, которые постоянно путают. Быстрая, но непредсказуемая сборка (p50 = 4 минуты, p99 = 70 минут) убивает поток сильнее, чем медленная, но стабильная. Мощная, но сложная абстракция даёт отличный «функциональный охват» и чудовищную когнитивную нагрузку. Если вы измеряете только скорость, вы не увидите ни первого, ни второго. При этом когнитивная нагрузка — это тот же рычаг, о котором говорят Team Topologies: платформа существует, чтобы снизить внешнюю нагрузку продуктовой команды, а значит, снижение нагрузки — измеряемый результат, а не риторика.

Единица измерения — путь, а не команда

Самая частая ошибка первого замера: агрегировать по командам или по сервисам. Получается «средняя температура»: у одной команды всё быстро, у другой всё сломано, среднее выглядит приемлемо и не подсказывает ни одного действия. Правильная единица — типовой путь: последовательность шагов, которую инженер проходит ради конкретного результата. Путей немного, обычно 6–10 на всю компанию:

1. Завести новый сервис и довести до прода.
2. Внести изменение в существующий сервис и выкатить.
3. Добавить зависимость: очередь, базу, кэш.
4. Расследовать инцидент в чужом сервисе.
5. Поднять окружение для ручной проверки и выкатить откат.
6. Выдать доступ новому человеку и провести изменение схемы БД.

Для каждого пути измеряется сквозное время и число переключений, а не время отдельного шага. Это прямое применение локальной оптимизации: ускорив сборку с 15 до 8 минут, вы можете не изменить сквозное время вообще, если между сборкой и деплоем стоит ручное согласование на четыре часа.

Вот как выглядит замер пути «новый сервис в прод» до и после работы платформы. Показательны не суммы, а места, где время не тратится, а теряется.

А теперь то же самое, но с типичной болью: тикет вместо API, человек вместо правила, ожидание вместо ответа.

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

Три класса сигналов и почему нужны все три

Ни один класс не самодостаточен. Телеметрия видит только тех, кто на платформе. Опрос собирает мнение лояльных. Поведение показывает факт, но не причину.

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

Каталог метрик, которые действительно что-то значат

Ниже — набор, который окупает стоимость сбора. Для каждой метрики важно сразу зафиксировать, как именно она врёт: метрика без известного способа обмана обязательно будет обманута.

Четыре метрики DORA — частота деплоя, сквозное время изменения, доля неудачных изменений, время восстановления — остаются лучшим стартовым набором для потокового класса. Важная оговорка, которую в отчётах обычно пропускают: DORA задумана как диагностический инструмент для команды, а не как рейтинг команд между собой, а ежегодные State of DevOps полезны как ориентир формы кривой, а не как норматив, к которому надо подтянуться. Второй ориентир — рамка SPACE (Форсгрен и соавторы, ACM Queue, 2021): удовлетворённость, производительность, активность, коммуникация, эффективность потока. Её главный практический тезис прост и полезен: берите метрики минимум из двух разных измерений, иначе система оптимизируется в одну сторону и сломается в другую.

Хвост, а не среднее

Инженер не переживает среднее. Он переживает вчерашние полтора часа ожидания.

Из тысячи сборок за неделю 120 ждут дольше 25 минут, а 20 — дольше часа. Именно эти 20 определяют, как о платформе говорят на кухне. Среднее в 15 минут не показывает их вообще, а медиана в 12 минут делает вид, что их не существует.

Практическое правило: для любой метрики времени публикуйте p50 и p90 рядом, а порог здоровья ставьте по p90. Это ровно та же логика, что в SLI и SLO и в измерении производительности, только пользователь здесь — свой инженер. Считать перцентили при этом нужно аккуратно: наивная агрегация «среднее из перцентилей по дням» математически бессмысленна.

import math
from statistics import median


def percentile(values: list[float], q: float) -> float:
    """Перцентиль по методу ближайшего ранга; q — доля, 0.9 это p90.

    Сложность: O(n log n) по времени из-за сортировки, O(n) по памяти.
    Для потокового расчёта на больших объёмах берите t-digest или DDSketch —
    там O(1) памяти при приемлемой относительной ошибке.
    """
    if not values:
        raise ValueError("пустая выборка")
    ordered = sorted(values)
    rank = min(len(ordered), max(1, math.ceil(q * len(ordered))))
    return ordered[rank - 1]


def feedback_health(durations_sec: list[float]) -> dict[str, float]:
    """Здоровье петли обратной связи описывается тремя числами, а не одним.

    spread — во сколько раз худший типичный случай хуже обычного. Именно он
    ломает поток: при spread > 3 инженер перестаёт ждать сборку и уходит
    переключаться на другую задачу.
    """
    p50 = median(durations_sec)
    p90 = percentile(durations_sec, 0.90)
    return {
        "p50_min": round(p50 / 60, 1),
        "p90_min": round(p90 / 60, 1),
        "spread": round(p90 / p50, 2),
    }


# Пример: быстрая, но непредсказуемая сборка проигрывает медленной и ровной.
fast_but_jittery = [60] * 85 + [1800] * 15   # 85 сборок по минуте, 15 по полчаса
slow_but_steady = [520] * 50 + [640] * 50    # всегда около девяти-одиннадцати минут

print(feedback_health(fast_but_jittery))  # p50 1.0, p90 30.0, spread 30.0 — поток разрушен
print(feedback_health(slow_but_steady))   # p50 9.7, p90 10.7, spread 1.1 — с этим можно жить

Метрика spread стоит того, чтобы её завести отдельно. Она отвечает на вопрос, который не задаёт ни один стандартный дашборд: можно ли планировать свой день вокруг этой платформы.

Кто не попал в измерение

Самая опасная ошибка измерения DX — систематическая, а не случайная. Телеметрия платформы по построению видит только тех, кто платформой пользуется.

Механика тут неприятная: средняя оценка платформы растёт при оттоке. Ушла недовольная команда — среднее по оставшимся выросло, дашборд стал зеленее, а платформа стала хуже. Это тот же эффект выжившего, что и в опросах пользователей продукта; в метриках продукта его лечат когортами, и здесь лечится тем же.

Три обязательных правила против слепой зоны:

1. Знаменатель — все команды компании. Не зарегистрированные в каталоге, не «онбордившиеся», а все, кто пишет код. Список берите из HR-системы или оргструктуры, а не из своей базы.
2. Активно ищите обходы. Скан всех репозиториев на предмет собственных пайплайнов, деплой-скриптов, форков ваших модулей IaC. Обход — это не нарушение, это заявка на функциональность, которую вам не подали.
3. Опрашивайте тех, кто ушёл. Пятнадцатиминутное интервью с командой, которая слезла с платформы, даёт больше, чем сто ответов от лояльных.

Запрос когорт удержания на событиях платформы выглядит примерно так:

-- Удержание команд по месяцам: сколько из тех, кто пользовался платформой
-- в месяц N, всё ещё пользуются ею в месяце N+1. Знаменатель принятия берётся
-- из справочника команд компании, а не из событий платформы.
WITH monthly AS (
    SELECT date_trunc('month', occurred_at) AS month,
           team_id,
           count(*)                          AS actions
    FROM platform_events
    WHERE event_type IN ('deploy', 'service_created', 'env_provisioned')
    GROUP BY 1, 2
),
cohorts AS (
    SELECT cur.month,
           count(DISTINCT cur.team_id)                              AS active_now,
           count(DISTINCT prev.team_id)                             AS active_prev,
           count(DISTINCT CASE WHEN prev.team_id IS NOT NULL
                               THEN cur.team_id END)                AS retained
    FROM monthly cur
    LEFT JOIN monthly prev ON prev.team_id = cur.team_id
                          AND prev.month = cur.month - INTERVAL '1 month'
    GROUP BY 1
)
SELECT c.month, c.active_now,
       round(100.0 * c.active_now / t.total_teams, 1)           AS adoption_pct,
       round(100.0 * c.retained / nullif(c.active_prev, 0), 1)  AS retention_pct
FROM cohorts c
CROSS JOIN (SELECT count(*) AS total_teams FROM company_teams WHERE writes_code) t
ORDER BY c.month;

Удержание — самая честная метрика платформы. Принятие можно продавить приказом, удержание продавить нельзя: команда, которой платформа мешает, найдёт способ уйти обратно.

Золотой путь: измерять не только тех, кто на нём

Золотой путь помогает ровно до момента, когда он превращается в забор. Отличить одно от другого можно измерением, и это самая недооценённая часть DX-программы.

Заведите реестр исключений: команда, которая не может пойти по золотому пути, регистрирует это одной строкой — что не подходит и почему. Не как просьбу о разрешении, а как заявку в бэклог платформы. Дальше реестр читается как продуктовый сигнал:

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

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

Переход adopted → partial — самый дорогой и самый незаметный. Он почти всегда происходит после одного инцидента, где платформа подвела в плохой момент. Отсюда практическое следствие: у платформы должны быть собственные SLO — на доступность конвейера, на время выкатки, на время ответа поддержки. Механика ровно та же, что в SLO продуктовых сервисов, и нарушение бюджета ошибок платформы должно останавливать её собственные фичи так же, как останавливает продуктовые.

Что делать с числами: приоритизация боли

Собранные метрики бесполезны, пока не превращены в порядок работ. Работающая формула ранга проста и не требует математики:

вес боли = частота действия × потерянное время за раз × число затронутых инженеров

Она сразу расставляет вещи иначе, чем интуиция. Настройка нового сервиса — редкое действие: пусть даже она занимает день, но случается двенадцать раз в год. Ожидание сборки — сорок раз в день у ста инженеров. Пять минут на сборке весят больше, чем целый день на онбординге сервиса.

Правый верхний угол — то, что чинят первым. Левый верхний соблазнителен: там красивые проекты вроде «портала для создания сервисов», которые хорошо смотрятся в презентации и почти не влияют на суммарное время. Именно так рождается портал, которым никто не пользуется: его построили под редкое действие. Отдельно стоит вспомнить точки воздействия: самый сильный рычаг обычно не в ускорении шага, а в удалении шага. Ускорить согласование доступа с трёх дней до одного — улучшение. Заменить согласование правилом в коде — изменение порядка величины.

Цена платформенной команды: точка окупаемости

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

WORK_MINUTES_PER_WEEK = 40 * 60  # 2400 минут в рабочей неделе


def breakeven(platform_size: int, product_engineers: int,
              realization: float = 0.5) -> float:
    """Сколько минут в неделю платформа должна экономить КАЖДОМУ инженеру,
    чтобы просто окупить собственную зарплатную нагрузку.

    realization — доля сэкономленного времени, которая реально превращается
    в полезную работу. Ставить 1.0 нечестно: пятнадцать освободившихся минут
    редко становятся пятнадцатью минутами фичи. Разумный диапазон 0,3–0,7;
    берите нижнюю границу, если хотите, чтобы вам верили.
    """
    return WORK_MINUTES_PER_WEEK * (platform_size / product_engineers) / realization


def payback_ratio(platform_size: int, product_engineers: int,
                  saved_minutes_per_week: float) -> float:
    """Возвращённое время к потраченному. Меньше 1 — платформа является налогом,
    сколько бы зелёных дашбордов у неё ни было."""
    return round(saved_minutes_per_week / breakeven(platform_size, product_engineers), 2)


print(breakeven(6, 300))                  # 96 минут в неделю на инженера
print(breakeven(2, 25))                   # 384 минуты — больше шести часов в неделю
print(payback_ratio(2, 25, 120))          # 0.31 — не окупается

Числа отрезвляющие. При соотношении 6 к 300 платформа должна экономить каждому инженеру около полутора часов в неделю — это достижимо: одна только разница между тикетом на доступ и декларативной заявкой съедает больше. При соотношении 2 к 25 требуется экономить больше шести часов в неделю с человека, и это почти всегда недостижимо. Отсюда честный вывод для маленькой компании: выделенная платформенная команда там обычно не окупается, а окупается платформенная работа, размазанная по продуктовым командам. Подробнее — в главе про небольшие компании и в главе про состав команды.

Пять оговорок, без которых модель превращается в манипуляцию:

1. Коэффициент реализации нельзя брать равным единице. Сэкономленные минуты не складываются в фичи один к одному. Берите 0,3–0,5 и говорите об этом вслух — это резко повышает доверие к остальным вашим числам.
2. Экономию надо измерять, а не декларировать. «Мы автоматизировали и сэкономили 200 часов» без замера до и после — это не расчёт, а лозунг. Замер до внедрения — обязательная часть работы; сделать его после уже нельзя.
3. Не приписывайте себе чужие улучшения. Если сквозное время упало одновременно с реорганизацией команд, разделять эффекты придётся честно, вплоть до «мы не знаем».
4. У платформы есть и невременная выгода: снижение риска инцидентов, соответствие требованиям, снижение стоимости инфраструктуры. Считайте её отдельной моделью и не подмешивайте в расчёт экономии времени — смешанные модели невозможно проверить.
5. Стоимость платформы — это не только зарплаты. Это ещё и инфраструктура под саму платформу, лицензии и — самое дорогое — время продуктовых команд на миграции. Про это отдельная глава про миграции и про стоимость.

Пятый пункт стоит развернуть: миграция сорока команд на новый способ деплоя, каждая по два дня, — это 80 человеко-дней, изъятых из поставки. Если платформа экономит 96 минут в неделю на инженера, миграция окупится примерно за квартал — и это надо посчитать до начала, а не после.

Опрос, сделанный честно

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

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

Вопросы конкретные и привязанные к недавнему опыту. Плохо: «Насколько вы довольны платформой?» Хорошо:

• «Сколько разных систем вам пришлось тронуть, чтобы выкатить последнее изменение?» — числовой ответ.
• «Вспомните последний раз, когда вы потеряли больше двух часов из-за инструментов. Что это было?» — свободный текст, лучший источник гипотез.
• «Насколько вы уверены, что сможете откатить свой сервис в проде прямо сейчас?» — шкала от 1 до 5.
• «Что вы делаете вместо того, что предлагает платформа?» — прямой вопрос про обход, который телеметрия не задаст.

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

Методика интервью полностью переносится из продуктовой практики: смотрите дискавери и юзабилити-тестирование. Самая недооценённая техника — посадить инженера из другой команды заводить сервис по вашей документации и молча смотреть двадцать минут; один такой сеанс даёт больше, чем квартальный опрос.

Типовые провалы измерения

Метрика-витрина. Дашборд собран, чтобы показывать руководителю, а не чтобы принимать решения. Признак: на нём нет ни одного графика, который может стать красным по вине платформенной команды. Лечение: на каждый показатель — явный порог и явное действие при пробое.

Среднее по компании. Одна команда страдает, девять довольны, среднее приемлемое. Лечение: распределение по командам и отдельный список «худших пяти» — работать надо с ними, а не со средним.

Сравнение команд и оценка людей. Как только числа начинают использовать для сравнения команд, они перестают быть данными и становятся политикой: команды учатся выглядеть хорошо. Это закон Гудхарта в чистом виде. Ещё хуже, когда метрика уезжает в оценку человека: строки кода, число коммитов, число PR на человека — это не производительность, а способ сломать и данные, и доверие. Как только инженер понимает, что его меряют по числу PR, он начинает дробить PR. Метрики DX — диагностика системы; оценка людей строится иначе, см. грейды и рост.

Платформа-обёртка над облаком. Вы завернули облачный API в свой CLI, добавили сорок секунд на каждый вызов, отняли треть возможностей и добавили обязательный поход в вашу документацию, потому что публичной документации облака теперь недостаточно. Измеримый признак: время выполнения типового действия через платформу больше, чем напрямую, а число обращений в поддержку растёт вместе с принятием. Про то, где абстракция уместна, а где вредна, — глава про абстракции.

Портал, которым никто не пользуется. Метрика «просмотры страниц портала» растёт, а метрика «задач, доведённых до конца в портале» стоит. Портал построили вокруг редкого действия (создание сервиса), а ежедневная работа идёт мимо. Признак диагностируется одним числом: доля сессий, закончившихся результатом, а не уходом в консоль облака.

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

Цена владения инструментами

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

Backstage (backstage.io) — фреймворк каталога сервисов, а не готовый продукт. Реалистичная оценка: от полутора до трёх человеко-месяцев на первый полезный запуск и постоянно занятый инженер на поддержку, обновления и плагины. Он оправдан там, где сервисов сотни и проблема «кто владелец» реальна. При двадцати сервисах таблица в вики решает ту же задачу за ноль человеко-месяцев. Оценивайте по метрике «сколько сессий в каталоге закончились найденным ответом», а не по числу заведённых карточек.

Kubernetes (kubernetes.io) — гибкость ценой постоянной когнитивной нагрузки, которую вы обязаны спрятать от продуктовых команд, иначе платформа не выполнила свою работу. Метрика простая: сколько килобайт YAML видит продуктовый инженер, чтобы выкатить сервис. Если больше сотни строк — вы переложили нагрузку на пользователя. Основы — в главе devops про Kubernetes.

Конвейеры метрик. Открытый Four Keys даёт скелет для DORA-метрик; собирать события всё равно придётся под свои системы — бюджет примерно пара недель на первый честный набор и постоянная возня со сменой формата событий. Схему событий сборки и деплоя лучше не изобретать: у OpenTelemetry есть семантические соглашения для CI/CD, и принять чужую схему дешевле, чем поддерживать свою.

Коммерческие DX-платформы (DX, LinearB, Jellyfish и подобные) экономят месяцы на сборе данных и опросах. Их риск ровно один: покупая платформу измерения, легко купить вместе с ней рейтинг команд. Условие покупки — заранее договориться, что числа не пойдут в оценку людей.

Общее правило: сначала измерьте боль, потом выбирайте инструмент. Обратный порядок — «мы внедряем Backstage, потому что все внедряют» — это почти гарантированный портал, которым никто не пользуется.

Программа измерения на квартал

Измерение DX — не разовый проект, а контур обратной связи с периодом в квартал.

Три вещи, которые делают цикл рабочим:

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

Чек-лист честного измерения

• Метрики собраны минимум из трёх классов: телеметрия, опрос, поведение.
• Знаменатель принятия — все команды компании, а не зарегистрированные на платформе.
• Для каждой метрики времени публикуются p50 и p90, порог здоровья — по p90.
• Есть метрика удержания, а не только принятия; обходы ищутся активно, а не ожидаются в отчётах.
• Есть реестр исключений из золотого пути, и он читается как бэклог.
• У платформы есть собственные SLO, и их нарушение останавливает её фичи.
• Для каждой метрики записано, как именно её можно обмануть.
• Посчитана точка окупаемости команды с явным коэффициентом реализации, и у каждой инициативы есть замер до начала работ.
• Ни одна метрика DX не участвует в оценке отдельных людей — письменно и вслух.
• Результаты опроса публикуются вместе со списком «берём в работу / не берём и почему».

Мини-итог

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

Честность измерения держится на трёх вещах. Первая: хвост важнее среднего, потому что инженер помнит худший случай. Вторая: знаменатель берётся по всем командам компании, иначе метрика удовлетворённости будет расти по мере оттока недовольных. Третья: платформенная команда обязана считать собственную окупаемость в сэкономленном времени других — при соотношении шесть к тремстам это порядка полутора часов в неделю на инженера, и если такого счёта нет, платформа незаметно превращается в налог. Все инструменты в этой области — Backstage, Kubernetes, конвейеры DORA-метрик, коммерческие DX-платформы — имеют стоимость владения, которую надо называть до внедрения; порядок всегда один: сначала замер боли, потом выбор инструмента.

Источники

• Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler. DevEx: What Actually Drives Productivity. ACM Queue, 2023 — queue.acm.org/detail.cfm?id=3595878
• Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler. The SPACE of Developer Productivity. ACM Queue, 2021 — queue.acm.org/detail.cfm?id=3454124
• DORA: исследование и метрики поставки — dora.dev, отчёты State of DevOps — dora.dev/research
• Nicole Forsgren, Jez Humble, Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.
• Matthew Skelton, Manuel Pais. Team Topologies. IT Revolution, 2019 — teamtopologies.com
• CNCF Platforms White Paper — tag-app-delivery.cncf.io/whitepapers/platforms
• Four Keys: открытый конвейер для расчёта DORA-метрик — github.com/dora-team/fourkeys
• OpenTelemetry: семантические соглашения для CI/CD — opentelemetry.io/docs/specs/semconv/cicd; Backstage — backstage.io

Что дальше

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

Самообслуживание: от заявки в тикете к платформе, которой пользуются