Как измерять Developer Experience во времени

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

Отсюда стартерпак для тех, кто только начинает. Артём, который как раз готовит собственный доклад про Developer Experience и платформы, советует просто провести опрос — хоть в Яндекс Формах, хоть в любом другом инструменте: стоит это недорого, а результаты можно закинуть в современную нейросеть и попросить помочь с анализом. Вопросы Google, по его памяти, либо открыты, либо легко находятся в интернете и устраивают большинство организаций; дальше видно, у кого что болит, и можно приоритизировать задачи. Обратная сторона — обязанность показать реакцию: он видел компании, где задачи в бэклог взяли, но с опросом их не связали, а люди сами не догадаются. Проговорить нужно явно — ртом, дашбордом, презентацией, статьёй на внутреннем портале. Ещё два наблюдения: к концу опроса люди прокликивают середину шкалы, и обязательно нужно открытое поле — инженеры, в отличие от менеджеров, охотно в него жалуются.

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

С одним пунктом Артём не согласен: идея сменяемых ответственных ему нравится, но как пристроить её у себя, он не придумал, и ценности не видит. Ему ближе продакт-менеджер, который владеет опросом, улучшает его и защищает: когда приходят с просьбой добавить свои вопросы, владелец объясняет, что вопрос слишком узкий и интересен только одному подразделению — можно провести отдельно, но не тащить в общий большой опрос. Александр возражает: за опросом стоит внутренняя команда в несколько десятков исследователей, про её работу с запросами топ-менеджеров можно почитать в «Software Engineering at Google», а сменяемость сделали ради экстернализации знания — методология выгружена наружу, поэтому опрос знает не один человек, и каждый следующий приходит без эффекта накатанной колеи. Артём соглашается, что это вопрос зрелости и размера команды: через два-три года процесс всё равно едет по рельсам. Александру нравится и выборка: три когорты, каждая отвечает раз в три квартала, и за счёт смещения не попадает в один и тот же сезон.

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

В статье поэтому ушли от вопросов про конкретные инструменты к пяти общим темам: результаты, стратегия и развитие продуктов, работа команд, инструменты и ресурсы, workflow and execution. Внутри последней жил техдолг — сам термин, вспоминает Александр, не нравится Диме Гаевскому, который отвечает за внутреннюю платформу разработки. Проблему увидели в больших опросах, дальше пошли фокусные исследования, разбивка по типам долга и по частям кодовой базы, и за несколько лет ответ сместился с «мешает работать» до «уже не мешает». Но культа из больших опросов Артём делать не советует: тренд продуктовый — звёздочки от одного до пяти и поле для комментария сразу после сценария, потому что постфактум человек помнит только, что было плохо или хорошо, но не что именно. Он иллюстрирует это кофемашиной: после трёх поломок второй машины следующую он купит другой марки, хотя и понимает, что брак бывает у процента изделий. Финальный тезис Александра — вторая нога из логов: часы до первого коммита в платформе его компании упали с 51 в 2021 году до 9 в 2024-м.