Блог UnionVK

Developer Experience: поиск счастья для технической команды

Что такое developer experience, как его затащить и применить в своих командах? Какие метрики мы можем навесить, чтобы измерить уровень счастья? Обсудили с Андреем Синицыным.
Спикер: Андрей Синицын
Devops, управленец, предприниматель. SRE Team Lead. DevOps-infected, профессионал эксплуатации, поклонник больших систем и высоких нагрузок. Фанат автоматизации и правильных SRE-практик. В индустрии с 2003 года.

UnionVK

Материал подготовлен на основе онлайн-встречи UnionVK, сообщества текущих и бывших сотрудников группы компаний VK. Присоединяйся к комьюнити, если тоже являешься выпускником группы VK :)

А полную запись встречи можно посмотреть по ссылке на нашем YouTube канале.
Опыт разработчика (DX) важен настолько же, насколько пользовательский опыт (UX).
И да: разработчику нужно, чтобы о нём позаботились. Ведь это случается далеко не всегда
Взглянем на популярный софт для разработчиков – Jenkins. Очень полезная вещь с огромным количеством фич, но выглядит как оживший кошмар.
Есть альтернатива – argo-cd, с хорошим функционалом. Несмотря на то, что количество фич в ней меньше, интерфейс не вводит разработчика в ужас.

Что такое DX (DevEx) и как он улучшает атмосферу?

Итак, DevEx – опыт, который разработчики «переживают» при работе над определенной технологией, продуктом или сервисом. DevEx направлен на создание положительного опыта для разработчиков, что, в свою очередь, способствует повышению их продуктивности и удовлетворённости работой.
DX можно включить на любой стадии SDLC.
DevEx включает в себя несколько пунктов:

  • Удобное окружение
  • Коммуникация
  • Документация
  • Автоматизация и инструменты
  • Обратная связь
  • Развитие
  • Work-life balance

Далее разберём их подробнее.

I. Удобное окружение

В первый день онбординга специалист должен получить следующие штуки:

  • Доступы, артефакты, репозитории
  • «Give me the latest version» (новичок получает важные апдейты, сетапы, возможность склонировать репу на Gitlab и т.д.)
  • «Бесшовные» интеграции со всеми продуктами
Писать свои утилиты вместо огромных Markdowns не страшно.
А ещё можно причесать документацию с помощью технических писателей и Chat GPT 😉

II. Коммуникация

  1. Общие чат-пространства и эффективные встречи
Когда я прихожу в большую команду, первым делом ввожу запрет на профессиональное общение в личке. Все рабочие вопросы решаются в общих чатах.
Если твой мессенджер позволяет, можно сделать отдельный чат под каждую задачу из трекера, помечая её флажком или галочкой⛳
Зачем нужен общий чат?
Представим ситуацию: В большом проекте что-то случилось. Система на какое-то время теряет стабильность – ничего страшного, такое бывает. Мы организуем созвон кругом людей, которые решат проблему, пофиксим и забудем. Да, неполадку устраним, но опыт её решения не будет доступен для других членов команды. А это плохо.

Как по-другому: Записывать follow up’ы, а затем распространять в едином чат-пространстве или в отдельной ветке на GitHub с подключённым ai-ассистентом.

Конечно, главный навык разработчика – писать хороший код. Но он должен знать и другие стороны процесса, например, что его продукт удобно интегрируется. Ведь часто приходится делать merge кода вручную, а это потеря времени.
Это чревато увеличением коэффициента Time to market, одной из ключевых метрик продукта. Чем её значение ниже, тем лучше ты умеешь деливерить фичи.

III. Документация

Цель менеджера – выработать систему, в которой каждый разработчик раз в неделю будет уделять ей хотя бы полчаса. Считаю, что уровень приоритетности этой задачи – P1.

Здесь есть несколько нюансов, которые помогут менеджеру наладить работу с доками.

  • Continuous improvement при работе с документами (совет: лучше измерять продолжительное улучшение на коротких отрезках, но регулярно);
  • Напоминания в таск-трекер (со ссылкой, галочкой / флажком и просьбой к разработчику описать подробнее свою задачу);
  • Runbooks и Troubleshooting Guides (например, если твой сервис пока не умеет обрабатывать специфическое состояние сети, закинь подробное описание проблемы в ранбук; возможно, специалист, который станет частью команды в будущем, решит эту задачу);
  • Скринкасты с решением проблем (в таком случае, столкнувшись со схожей ситуацией, специалист получит более наглядную и однозначную инструкцию);

IV. Обратная связь

Для её получения можно использовать:

  • Ретроспективы повторяющихся процессов (по ним можно отслеживать прогресс; для этого мне хватает одной двухчасовой встречи с командой раз в две недели);
  • Инструменты для обратной связи: кремниевые и белковые (полезны и one to one, и общие встречи; не забывайте хвалить команду, напоминать о важности общего дела).

V. Развитие

Конференции, митапы и семинары
Стимулируйте своих подчинённых не только посещать события своей профессиональной отрасли, но и делать выводы, исходя из полученных знаний.

Образовательные программы
Хороший формат – масштабные ивенты, на которых разные отделы знакомятся со спецификой работы друг друга. Так devops наконец-то поймёт, как и зачем работает product менеджер 😉

Программы онбординга
Фиксируй, сколько времени прошло от приёма сотрудника на работу до первого commit’а, который уехал на прод.Эта метрика позволит пранализировать эффективность онбординга.

Work-life balance
Очевидно, что технические специалисты работают в довольно стрессовых условиях. Им необходим гибкий график.
Но есть нюанс. При оценке работы мы делаем упор не на потраченное время, а на выполненные задачи. Перефразируя знаменитый закон Гудхарда, отмечу: когда специалист упорно пытается достичь KPI, он неизбежно найдёт путь исказить исходную задачу так, чтобы в первую очередь достичь нужного показателя конкретной метрики, а не решить проблему. Одна из вариаций такого подхода – отсидеть «необходимое» время. Менеджеру нужно отслеживать такие ситуации.
Если разработчик набрал тысячу задач на спринт – это его ответственность. Разработчику нужно грамотно расценивать свои ресурсы. Это тоже важный аспект work-life balance.

Метрики счастья технической команды

Как менеджер, я исповедую подход «People first». Хотя стоит понимать, что его легче внедрить на небольших проектах, где не так много корпоративных правил и бюрократии.
Метрика «WTF per hour»
На старте у нас есть документация (репозиторий или папка с названием Docs) и tooling. Но при дальнейшем внедрении количество WTF в час растёт по экспоненте.

Что стимулирует рост WTF/hour:
🤬 Плохая организация кода
🤬 Куча легаси
🤬 Отсутствие прозрачности и отлаженности процессов
🤬 Устаревшие инструменты

Ещё одна важная проблема – переключение контекста
Переключение процессора с одной задачи на другую – знакомая всем ситуация. Из-за высокой ресурсоёмкости эффективность процессора падает (ему нужно время на сброс старого контекста и поднятие нового). Та же ситуация случается и в команде разработчиков.
Чем больше времени в течение рабочего дня специалист находится в одном контексте, тем он эффективнее решает задачу.
Чтобы снизить показатель WTF, обрати внимание на метрики ниже ⬇️
  1. Метрика «Usability» (удобство использования)🥰. Выражается в количестве действий, необходимых для достижения результата.Чем ниже число, тем счастливее человек. Здесь же измеряем, насколько типовые те или иные процессы, степень удобства интеграций со внешними (эйчары) и смежными службами
  2. Метрика «Findability» (прозрачность поиска) 🔎. Например, при использовании ChatOps может быть непонятно, кто владелец бота, не слишком ли много графиков, где их вообще искать и т.п.
  3. Метрика «Credibility» (доверие) 🙏. Показатель высокого уровня доверия – использование твоего инструмента другими частями команды.

Objectives для DevEx: когда всё хорошо

📈 Productive | Продуктивность
Когда всё хорошо: Технические специалисты способны эффективно решать свои задачи в рамках всех инфраструктурных инструментов.

Индикаторы продуктивности:
💯 Effectiveness | Результативность (частота факапов и успешных проектов);
🔝 Efficiency | Эффективность (время начала работы до полной удовлетворенности результатом).

🤤Happy | Счастье
Когда всё хорошо: Технические специалисты СЧАСТЛИВЫ, работая с системами, процессами, активностями и инструментами.

Индикаторы счастья:
💃Счастливые инженеры (Процент специалистов, полностью удовлетворенный окружением, инструментами и активностями);
🉐 DX Score* (Интегральная метрика, показывающая общую атмосферу счастья в команде).
*Из чего она будет складываться и в чём выражаться? Ответить на этот вопрос можешь только ты. Но её главная задача – быть доступной каждому члену команды, чтобы твои подчинённые были заинтересованы в её росте.

А теперь – о цифрах

Один из принципов моей работы состоит в следующем: артефакт не должен меняться после сборки и прохождения quality и security gates. Если мы пушим один и тот же код, но меняем версию сборки, результат должен оставаться одинаковым.
  • Build Time (P50 и P90) – в секундах (а не в часах или минутах);
  • Code Review Response Time (P50 и P90) – в минутах (поэтому pull requests не должны быть на несколько тысяч строк);
  • CI-детерминизм (уверенность в том, что тесты и линтеры правильные и работающие);
  • Deployment Success Rate (очевидно, должен быть высоким. Однако на всякий случай необходимо выработать процедуру отката релизов);
  • Net User Satisfaction (NSAT) – разговор с командой раз в квартал о том, насколько ей хорошо 😀

Look’N’Feel подход

Как и многие другие особенности DX, он пришёл из UX. В этом подходе ты получаешь конкретные инструкции для менеджера.

  • Говорите с людьми (не обязательно о работе)
  • Проводите опросы (можно использовать NPS-метрику)
Есть интересная корреляция: чем счастливее команда, тем выше процент заполнивших анкету в формате NPS. Ведь удовлетворённая команда будет лучше осознавать, зачем этот сбор данных нужен, а не восклицать в пустоту о том, что «всё это – трата времени».
  • Проводи тестирование инструментов индивидуально, под проект и команду
  • Проси обратную связь (не в виде опроса, а «по-человечески»: «что я могу сделать, чтобы вам было комфортнее?»)
  • Не бросай людей с проблемами
Лучшая книга, которую стоит прочесть IT-менеджеру, это «Общаться с ребенком. Как?» Юлии Гиппенрейтер. Стоит понимать, что разработчик – это человек с очень специфическим майндсетом. Если он начал вам доверять, то довести с ним дело до конца – твоя святая обязанность.
Я понял, что DX нужен. А с чего начать?
🌭 Пойми и изучи потребности (в нашем случае – это scope для разработчика, который нужно построить. Осознай его и распиши в конкретные процессы);
👮 Придумай персонажей (например: «Вася-программист ломает билд. Что делать?»);
🗺️ Создавай карты путей пользователей – CJM (по ним должно быть удобно водить Васю).
Счастливые и положительно мотивированные разработчики перформят лучше!
Запугать можно сторожа, а команде с важной бизнес-задачей и тяжелейшим пайплайном нужно, чтобы их похвалили. Так процент выполненных задач станет в разы выше.
Хочешь стать ещё более скилловым менеджером, крутым разработчиком или реализовать собственный проект? Оставайся с нами и читай материалы о разных сторонах мира IT 😉

Читай далее

10 вредных советов по управлению командами и проектами
Инженерная культура Microsoft
2024-06-12 13:26