Как измерять продуктивность разработчиков: DORA, SPACE и DevEx

Артём начинает с себя: сейчас он руководит проектным и продуктовым офисом в Яндексе, а до этого девять лет проработал в Сбере, куда пришёл почти сразу после университета: отвечал за надёжность, руководил проектным офисом, был директором по развитию — должность, которую сам называет выдуманной. Последние годы его задача — эффективность разработки: смена процессов, новые практики, платформенные решения, копилоты для разработчиков. Отсюда его главный тезис: платформы пора перестать делать как «инженеры для инженеров» и начать делать как продукты для инженеров. Аргумент бытовой — iPhone изменил ожидания от интерфейсов сначала в бизнес-приложениях, а теперь очередь дошла до внутренних инструментов: никто не хочет полгода читать мануал и идти к седому старцу в горах за секретом, где ставить точку с запятой, — все хотят большую красную кнопку. Александр задаёт рамку: Discovery — делать правильные вещи, Delivery — делать вещи правильно, и дальше разговор идёт про Delivery.

Проблемы «слева» всё равно достают Delivery: по регулярным опросам Developer Experience Артём видит, что разработчики сами всё чаще отмечают, как продуктовая неразбериха бьёт по их производительности; отсюда метафора машины, которую разгоняют, забыв спросить, куда едем. Внедрение платформы Александр описывает как адаптивную модель: сначала пилоты с ранними адаптерами и разрешительный режим, форсирование и миграции — только когда основные сценарии закрыты; форсировать раньше готовности значит получить заслуженный хейт, ведь без вас люди жили нормально. Плохая альтернатива — не улучшать платформу, а задирать switch cost своим синтаксисом и адовыми YAML-файлами. Александр добавляет экономику масштаба: две платформы внутри компании рано или поздно становятся слишком дорогими, и вспоминает историю Уилла Ларсона про Uber, где заход в каждый город своими силами дал около 125 кастомных решений, а на предложение унифицировать отвечали ссылкой на ценности компании. При этом сильная платформа — ещё и аргумент в найме: Артём кивает на Spotify, выложившую свою в опенсорс.

Про метрики Александр начинает с кладбища старых подходов: количество строк кода, утилизация ресурсов, velocity. У каждого свой способ обмана — velocity надувают оценками, команда, которой считают закрытые ревью, дробит задачи помельче, а стопроцентную утилизацию все видели в очереди в поликлинике: загрузка полная, люди ждут. Артём приводит формулу бывшего руководителя: метрика живёт квартал, максимум два, а потом её начинают взламывать, особенно если от неё зависит премия. Рядом Александр вспоминает закон, придуманный, по его словам, статистиками и социологами одновременно: как только метрика становится целью, она перестаёт быть хорошей метрикой; и, с оговоркой «по-моему», близкий тезис Кэмпбелла — измеряемое поведение уплывает. Вывод Артёма простой: мерить надо то, что болит. Болит качество тестирования — считайте дефекты на тестовой среде и в продакшене; метрик в Сбере и Яндексе, по его словам, отслеживают куда больше четырёх.

Книгу Accelerate Артём не осилил — читал отчёты и статьи; Александр разбирал английский оригинал, где читает втрое медленнее и потому обдумывает больше. Четвёрку DORA — модель компании DevOps Research and Assessment, которую потом купил Google, — они проходят по очереди. Lead time Артём называет базовой метрикой, но она разъезжается на определениях: продуктовая команда считает от «взяли в работу» до прода, внутренний подрядчик — до своего тестового контура, поэтому в их системе метрик стоит разводящая страница: сначала настраиваешь пространство в Jira и статусы, потом смотришь дашборд. Про частоту поставок Александр рассказывает происхождение, которого Артём не знал: её взяли как прокси размера батча, потому что спрашивать про батч напрямую было нельзя — у всех разный масштаб систем. Идея из Just-in-Time: важно не то, какими кусками режут колбасу, а как часто отрезают; маленькие порции дают низкую вариабельность и позволяют понять, от чего случился эффект. Время восстановления Артём сводит к одной мысли — быстро значит, что клиент ничего не заметил.

SPACE 2021 года Александр показывает своей визуализацией: обычные таблички его бесят, он рисует паутинки — и в схеме ему нравится, что пять осей раскладываются на три уровня, индивидуальный, командный и системный. Артём тут же отправил картинку сотруднице, которая готовит продуктовое видение метрик эффективности: «Саша за тебя всё сделал, осталось описать страничку в вики». Против satisfaction and wellbeing у него психологическое отторжение — он приходит на работу работать за зарплату, а мотивировать его на 150 процентов должны менеджеры, — но измерять удовлетворённость инструментами и процессами считает правильным: начав мерить NPS своих инструментов, оказываешься рядом с продуктовым подходом и смотришь на собственную админку глазами пользователя дистанционного банковского обслуживания. На индивидуальном уровне метрики полезны самому инженеру, но не для его оценки: поставьте норму коммитов — и люди станут коммитить чаще.

В DevEx 2023 года, где среди авторов снова Николь Форсгрен, Александр обращает внимание на то, что это ещё и товарный знак: у авторов есть своя платформа, и часть исследования опирается на инженеров компаний, которые ею уже пользуются, — то есть на заинтересованных темой. Там же виден откат: SPACE тянул данные из реальных систем, а DevEx возвращается к опросам, потому что облачный продукт не может лазить в логи каждой компании. Модель Google Александр разбирает по книге Software Engineering at Google и серии статей «Developer Productivity for Humans»: исследователи челленджат входящие запросы и не берутся за работу, если по её результатам ничего делать не собираются, а измерение сместилось с инструментов на сценарии — вместо код-ревью формулируется «обеспечение качества кода, написанного другим человеком», в логах расставляются реперные точки, и видно не только золотой путь, но и реальную траекторию с походами в документацию, звонками и встречей. Артём говорит, что перестраивает у себя ровно это: согласованная с техдиректорами стратегия ставит сценарий выше инструмента.