Что такое developer experience, как его затащить и применить в своих командах? Какие метрики мы можем навесить, чтобы измерить уровень счастья? Обсудили с Андреем Синицыным.
Спикер: Андрей Синицын
Devops, управленец, предприниматель. SRE Team Lead. DevOps-infected, профессионал эксплуатации, поклонник больших систем и высоких нагрузок. Фанат автоматизации и правильных SRE-практик. В индустрии с 2003 года.
Devops, управленец, предприниматель. SRE Team Lead. DevOps-infected, профессионал эксплуатации, поклонник больших систем и высоких нагрузок. Фанат автоматизации и правильных SRE-практик. В индустрии с 2003 года.
UnionVK
Материал подготовлен на основе онлайн-встречи UnionVK, сообщества текущих и бывших сотрудников группы компаний VK. Присоединяйся к комьюнити, если тоже являешься выпускником группы VK :)
А полную запись встречи можно посмотреть по ссылке на нашем YouTube канале.
А полную запись встречи можно посмотреть по ссылке на нашем YouTube канале.
Опыт разработчика (DX) важен настолько же, насколько пользовательский опыт (UX).
И да: разработчику нужно, чтобы о нём позаботились. Ведь это случается далеко не всегда
Взглянем на популярный софт для разработчиков – Jenkins. Очень полезная вещь с огромным количеством фич, но выглядит как оживший кошмар.
Взглянем на популярный софт для разработчиков – Jenkins. Очень полезная вещь с огромным количеством фич, но выглядит как оживший кошмар.
Есть альтернатива – argo-cd, с хорошим функционалом. Несмотря на то, что количество фич в ней меньше, интерфейс не вводит разработчика в ужас.
Что такое DX (DevEx) и как он улучшает атмосферу?
Итак, DevEx – опыт, который разработчики «переживают» при работе над определенной технологией, продуктом или сервисом. DevEx направлен на создание положительного опыта для разработчиков, что, в свою очередь, способствует повышению их продуктивности и удовлетворённости работой.
DX можно включить на любой стадии SDLC.
DevEx включает в себя несколько пунктов:
Далее разберём их подробнее.
- Удобное окружение
- Коммуникация
- Документация
- Автоматизация и инструменты
- Обратная связь
- Развитие
- Work-life balance
Далее разберём их подробнее.
I. Удобное окружение
В первый день онбординга специалист должен получить следующие штуки:
- Доступы, артефакты, репозитории
- «Give me the latest version» (новичок получает важные апдейты, сетапы, возможность склонировать репу на Gitlab и т.д.)
- «Бесшовные» интеграции со всеми продуктами
Писать свои утилиты вместо огромных Markdowns не страшно.
А ещё можно причесать документацию с помощью технических писателей и Chat GPT 😉
II. Коммуникация
- Общие чат-пространства и эффективные встречи
Если твой мессенджер позволяет, можно сделать отдельный чат под каждую задачу из трекера, помечая её флажком или галочкой⛳
Зачем нужен общий чат?
Представим ситуацию: В большом проекте что-то случилось. Система на какое-то время теряет стабильность – ничего страшного, такое бывает. Мы организуем созвон кругом людей, которые решат проблему, пофиксим и забудем. Да, неполадку устраним, но опыт её решения не будет доступен для других членов команды. А это плохо.
Как по-другому: Записывать follow up’ы, а затем распространять в едином чат-пространстве или в отдельной ветке на GitHub с подключённым ai-ассистентом.
Конечно, главный навык разработчика – писать хороший код. Но он должен знать и другие стороны процесса, например, что его продукт удобно интегрируется. Ведь часто приходится делать merge кода вручную, а это потеря времени.
Представим ситуацию: В большом проекте что-то случилось. Система на какое-то время теряет стабильность – ничего страшного, такое бывает. Мы организуем созвон кругом людей, которые решат проблему, пофиксим и забудем. Да, неполадку устраним, но опыт её решения не будет доступен для других членов команды. А это плохо.
Как по-другому: Записывать 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
Очевидно, что технические специалисты работают в довольно стрессовых условиях. Им необходим гибкий график.
Стимулируйте своих подчинённых не только посещать события своей профессиональной отрасли, но и делать выводы, исходя из полученных знаний.
Образовательные программы
Хороший формат – масштабные ивенты, на которых разные отделы знакомятся со спецификой работы друг друга. Так devops наконец-то поймёт, как и зачем работает product менеджер 😉
Программы онбординга
Фиксируй, сколько времени прошло от приёма сотрудника на работу до первого commit’а, который уехал на прод.Эта метрика позволит пранализировать эффективность онбординга.
Work-life balance
Очевидно, что технические специалисты работают в довольно стрессовых условиях. Им необходим гибкий график.
Но есть нюанс. При оценке работы мы делаем упор не на потраченное время, а на выполненные задачи. Перефразируя знаменитый закон Гудхарда, отмечу: когда специалист упорно пытается достичь KPI, он неизбежно найдёт путь исказить исходную задачу так, чтобы в первую очередь достичь нужного показателя конкретной метрики, а не решить проблему. Одна из вариаций такого подхода – отсидеть «необходимое» время. Менеджеру нужно отслеживать такие ситуации.
Если разработчик набрал тысячу задач на спринт – это его ответственность. Разработчику нужно грамотно расценивать свои ресурсы. Это тоже важный аспект work-life balance.
Метрики счастья технической команды
Как менеджер, я исповедую подход «People first». Хотя стоит понимать, что его легче внедрить на небольших проектах, где не так много корпоративных правил и бюрократии.
Метрика «WTF per hour»
На старте у нас есть документация (репозиторий или папка с названием Docs) и tooling. Но при дальнейшем внедрении количество WTF в час растёт по экспоненте.
Что стимулирует рост WTF/hour:
🤬 Плохая организация кода
🤬 Куча легаси
🤬 Отсутствие прозрачности и отлаженности процессов
🤬 Устаревшие инструменты
Ещё одна важная проблема – переключение контекста
На старте у нас есть документация (репозиторий или папка с названием Docs) и tooling. Но при дальнейшем внедрении количество WTF в час растёт по экспоненте.
Что стимулирует рост WTF/hour:
🤬 Плохая организация кода
🤬 Куча легаси
🤬 Отсутствие прозрачности и отлаженности процессов
🤬 Устаревшие инструменты
Ещё одна важная проблема – переключение контекста
Переключение процессора с одной задачи на другую – знакомая всем ситуация. Из-за высокой ресурсоёмкости эффективность процессора падает (ему нужно время на сброс старого контекста и поднятие нового). Та же ситуация случается и в команде разработчиков.
Чем больше времени в течение рабочего дня специалист находится в одном контексте, тем он эффективнее решает задачу.
Чтобы снизить показатель WTF, обрати внимание на метрики ниже ⬇️
- Метрика «Usability» (удобство использования)🥰. Выражается в количестве действий, необходимых для достижения результата.Чем ниже число, тем счастливее человек. Здесь же измеряем, насколько типовые те или иные процессы, степень удобства интеграций со внешними (эйчары) и смежными службами
- Метрика «Findability» (прозрачность поиска) 🔎. Например, при использовании ChatOps может быть непонятно, кто владелец бота, не слишком ли много графиков, где их вообще искать и т.п.
- Метрика «Credibility» (доверие) 🙏. Показатель высокого уровня доверия – использование твоего инструмента другими частями команды.
Objectives для DevEx: когда всё хорошо
📈 Productive | Продуктивность
Когда всё хорошо: Технические специалисты способны эффективно решать свои задачи в рамках всех инфраструктурных инструментов.
Индикаторы продуктивности:
💯 Effectiveness | Результативность (частота факапов и успешных проектов);
🔝 Efficiency | Эффективность (время начала работы до полной удовлетворенности результатом).
🤤Happy | Счастье
Когда всё хорошо: Технические специалисты СЧАСТЛИВЫ, работая с системами, процессами, активностями и инструментами.
Индикаторы счастья:
💃Счастливые инженеры (Процент специалистов, полностью удовлетворенный окружением, инструментами и активностями);
🉐 DX Score* (Интегральная метрика, показывающая общую атмосферу счастья в команде).
Когда всё хорошо: Технические специалисты способны эффективно решать свои задачи в рамках всех инфраструктурных инструментов.
Индикаторы продуктивности:
💯 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 (по ним должно быть удобно водить Васю).
🌭 Пойми и изучи потребности (в нашем случае – это scope для разработчика, который нужно построить. Осознай его и распиши в конкретные процессы);
👮 Придумай персонажей (например: «Вася-программист ломает билд. Что делать?»);
🗺️ Создавай карты путей пользователей – CJM (по ним должно быть удобно водить Васю).
Счастливые и положительно мотивированные разработчики перформят лучше!
Запугать можно сторожа, а команде с важной бизнес-задачей и тяжелейшим пайплайном нужно, чтобы их похвалили. Так процент выполненных задач станет в разы выше.
Хочешь стать ещё более скилловым менеджером, крутым разработчиком или реализовать собственный проект? Оставайся с нами и читай материалы о разных сторонах мира IT 😉
Запугать можно сторожа, а команде с важной бизнес-задачей и тяжелейшим пайплайном нужно, чтобы их похвалили. Так процент выполненных задач станет в разы выше.
Хочешь стать ещё более скилловым менеджером, крутым разработчиком или реализовать собственный проект? Оставайся с нами и читай материалы о разных сторонах мира IT 😉