DevX: ориентированный на разработчиков подход к измерению и повышению производительности
Привет, Хабр! Меня зовут Олег Хромов, в МТС я руковожу центром «Управление разработкой». В статье расскажу, как мы оцениваем производительность IT-специалистов. Универсальные методы работают плохо, поэтому мы пришли к специально адаптированному для IT подходу под названием DevX. Именно его я и советую применять.
Почему я затрагиваю эту тему? Дело в том, что в МТС я взаимодействую с большим количеством кодеров в МТС и моя главная задача — сделать их счастливыми и эффективными одновременно. Подробнее обо всём этом — под катом.
Почему так сложно оценить эффективность разработчиков?
Проблема состоит из трёх частей:
у компании есть потребность измерять производительность разработчиков,
руководители хотят влиять на эффективность труда кодеров,
методы прямого измерения количества кода или времени, потраченного на задачу, недостаточно хороши, они не дают ожидаемого результата.
Универсальные методы оценки эффективности в нашем случае работают не очень хорошо. Измерить производительность человека, занимающего интеллектуальным трудом вообще непросто. А когда речь про творческий процесс (каким и является разработка), становится ещё сложнее.
IT-специалисты не хотят быть винтиками большой машины. Для них важно, чтобы менеджмент признавал их, скажем так, человечность. Это выражается в том, что сотрудники не всегда могут быть в настроении работать, они могут быть недовольны недостаточной оценкой результатов труда и так далее. Поэтому в IT для повышения эффективности компании продуктивными нужно делать самих людей.
Остановлюсь подробнее, почему разработка — это творчество:
разработка ПО — не алгоритмический процесс. В подавляющем большинстве случаев решить какую-то задачу можно не одним, а несколькими путями. Они могут быть одинаково хороши, со своими плюсами и минусами, но с примерно равной эффективностью,
результат работы далеко не всегда известен с самого начала, при этом любой программный продукт уникален,
создание ПО — это не о получении единообразных, взаимозаменяемых результатов,
в процессе кодинга часто проводят исследовательскую работу.
Как вообще оценивают продуктивность сотрудников? Уже много десятков лет существуют четыре принципа научного менеджмента:
систематическое измерение и оценка производительности,
сознательный подбор, обучение и воспитание сотрудников,
разделение общего объёма работы на задачи, которые можно делегировать специалистам,
предоставление конкретных инструкций по выполнению этих задач каждому профессионалу.
Первые два пункта понятны, с этим всё ок. С третьим непросто: «разбить общий объём на части» в кодинге можно не всегда. Есть трудности и с четвёртым пунктом, если мы не можем рационально декомпозировать главную задачу, и распределить последние между сотрудниками тоже не получится.
Ещё сильнее всё запутывают заблуждения, которые часто возникают при оценке эффективности кодеров:
Производительность зависит от активности разработчиков. Речь про любые метрики, которые используются для оценки труда. Дело в том, что кодер может быть очень продуктивным при низкой общей эффективности его работы. Другими словами, по метрикам все отлично (количество строк кода, потраченные на закрытие таска часы и т. п.), но пользы от такой работы для компании мало.
Один показатель производительности сможет нам раскрыть всю картину. Это не так. Обычно нужно использовать несколько метрик одновременно. И даже в этом случае они не будут 100%-ным показателем результата. Вы получите ориентир, который подскажет направление, но не «волшебную пулю», способную разом исправить все проблемы.
Показатели производительности полезны только менеджерам. На самом деле они нужны и разработчику. Глядя на них он будет лучше понимать, как ему давать оптимальный результат и получать удовольствие от работы.
Как поможет DevX?
Альтернативный подход называется DevX — Developer Experience. Он основывается на изучении того, как специалист проводит свой трудовой день. Из чего он состоит, в каких моментах сотрудник получает больше удовольствия от работы, в каких меньше. Ежедневный опыт кодеров отражает их отношение к работе, то, что они о ней думают и насколько ценят.
Основные метрики
Есть всего три «измерения» DevX:
обратная связь,
когнитивная нагрузка,
состояние потока.
Обратная связь — насколько быстро разработчик получает информацию, от которой зависит его работа. Например, сколько времени занимает код-ревью, пайплайн или что-то ещё, способное отправить человека в простой. Известны исследования, по результатам которых чем быстрее сотрудник получает обратную связь, тем эффективнее его отдел или вся компания в целом.
Быстрые циклы обратной связи помогают кодерам работать без пробуксовок и с минимальными трудностями. Типичный день айтишника состоит из большого количества задач, которые требуют обратной связи от инструментов и людей. Медленные циклы прерывают процесс разработки, что приводит к разочарованию и задержкам. Кодеры либо сидят и ждут, когда к ним вернутся, либо меняют задачу.
Когнитивная нагрузка — это про то, насколько сложно разобраться в одном из модулей своей работы. Например, кодовая база, документация, процессы или что-то ещё. Чтобы быть эффективным, разработчик должен хорошо во всём этом разбираться.
Создание ПО — это сложный процесс по сути. Новые инструменты и технологии дополнительно увеличивают когнитивную нагрузку. Она мешает людям выполнять свою самую важную обязанность — доставлять до клиентов ценность продукта. Выделенные DevX-команды и платформы должны обеспечивать простые инструменты самообслуживания, которые помогут кодерам оптимизировать разработку и выпуск.
Состояние потока — состояние выполняющего определённую деятельность человека, в котором он полностью погружён в работу, вовлечён и получает от процесса удовольствие.
Чем чаще разработчики находятся в состоянии потока, тем выше производительность и больше инноваций. А самое главное — тем активнее развиваются сотрудники и тем больше удовольствия они получают от своих работы и роста. В DevX и команды, и организации должны сосредоточиться на создании оптимальных условий для состояния потока.
Как измерить DevX?
С одной стороны, использовать те три метрики, о которых была речь выше. С другой — есть ещё три:
эмоциональные ощущения,
метрики систем и процессов,
метрики на уровне организации.
Ниже — пример, который поможет провести измерение:
Теперь подробнее поговорим о параметрах, которые на картинке расположены слева по вертикали, я называю их «метрики Х».
Эмоциональные ощущения. Речь здесь о том, что в дополнение к объективным данным об инженерных системах и процессах нужно учитывать восприятие разработчиков. Включая их отношение, чувства и мнения. Сравнительный анализ нужен, поскольку ни один из людей по отдельности не в состоянии дать полную картину. Об этом мы говорили выше — одна метрика не может показать всё, что нас интересует. Требуется комплексный подход.
Возьмём, например, код-ревью. Даже когда в организации по основным метрикам всё прекрасно, разработчики чем-то могут быть недовольны. Вероятна и обратная ситуация: все рады, а вот метрики показывают, что процесс неоптимален.
Метрики систем и процессов позволяют отслеживать работу отдельных частей организации. Они хороши, но нужен и следующий этап.
Метрики на уровне организации. Они крайне важны, поскольку сосредотачиваясь лишь на отдельных факторах, компания рискует упустить общую картину и инвестировать ресурсы в неправильные области. Ключевые показатели эффективности должны измерять результаты, с которыми коррелируют улучшения DevX и которых они стремятся достичь. Может случиться так, что в отдельных командах по метрикам всё хорошо, некоторые из процессов тоже идут как нужно. А вот общая эффективность работы организации низкая.
DevX измеряют фиксируя восприятие разработчиков и их рабочие процессы в разных системах и модулях. Опросы, кстати, один из важнейших инструментов для измерения DevX.
С чего начать?
С базовых вещей, о которых я рассказал выше. DevX подходит для крупных компаний и стартапов. Даже базовое понимание этого подхода даёт первые результаты.
А информация, которую вы получите, оценив производительность сотрудников при помощи нового подхода, позволит понять, где всё это время были проблемы, куда стоит двигаться и в какие направления вкладывать основные ресурсы.
Вместо заключения
Этот пост — результат моей обработки и переосмысления трёх прекрасных статей: DevEx: What Actually Drives Productivity — ACM Queue, A Human-Centered Approach to Developer Productivity | IEEE Journals & Magazine, The SPACE of Developer Productivity — ACM Queue.
Если захотите изучить тему подробнее, рекомендую с ними ознакомиться. Спасибо, что дочитали до конца!