Привет, Хабр! Меня зовут Олег Хромов, в МТС я руковожу центром «Управление разработкой». В статье расскажу, как мы оцениваем производительность IT-специалистов. Универсальные методы работают плохо, поэтому мы пришли к специально адаптированному для IT подходу под названием DevX. Именно его я и советую применять.

Почему я затрагиваю эту тему? Дело в том, что в МТС я взаимодействую с большим количеством кодеров в МТС и моя главная задача — сделать их счастливыми и эффективными одновременно. Подробнее обо всём этом — под катом.

Почему так сложно оценить эффективность разработчиков?

Проблема состоит из трёх частей:

• у компании есть потребность измерять производительность разработчиков,

• руководители хотят влиять на эффективность труда кодеров,

• методы прямого измерения количества кода или времени, потраченного на задачу, недостаточно хороши, они не дают ожидаемого результата.

Универсальные методы оценки эффективности в нашем случае работают не очень хорошо. Измерить производительность человека, занимающего интеллектуальным трудом вообще непросто. А когда речь про творческий процесс (каким и является разработка), становится ещё сложнее.

IT-специалисты не хотят быть винтиками большой машины. Для них важно, чтобы менеджмент признавал их, скажем так, человечность. Это выражается в том, что сотрудники не всегда могут быть в настроении работать, они могут быть недовольны недостаточной оценкой результатов труда и так далее. Поэтому в IT для повышения эффективности компании продуктивными нужно делать самих людей.

Остановлюсь подробнее, почему разработка — это творчество:

• разработка ПО — не алгоритмический процесс. В подавляющем большинстве случаев решить какую-то задачу можно не одним, а несколькими путями. Они могут быть одинаково хороши, со своими плюсами и минусами, но с примерно равной эффективностью,

• результат работы далеко не всегда известен с самого начала, при этом любой программный продукт уникален,

• создание ПО — это не о получении единообразных, взаимозаменяемых результатов,

• в процессе кодинга часто проводят исследовательскую работу.

Как вообще оценивают продуктивность сотрудников? Уже много десятков лет существуют четыре принципа научного менеджмента:

• систематическое измерение и оценка производительности,

• сознательный подбор, обучение и воспитание сотрудников,

• разделение общего объёма работы на задачи, которые можно делегировать специалистам,

• предоставление конкретных инструкций по выполнению этих задач каждому профессионалу.

Первые два пункта понятны, с этим всё ок. С третьим непросто: «разбить общий объём на части» в кодинге можно не всегда. Есть трудности и с четвёртым пунктом, если мы не можем рационально декомпозировать главную задачу, и распределить последние между сотрудниками тоже не получится.

Ещё сильнее всё запутывают заблуждения, которые часто возникают при оценке эффективности кодеров:

1. Производительность зависит от активности разработчиков. Речь про любые метрики, которые используются для оценки труда. Дело в том, что кодер может быть очень продуктивным при низкой общей эффективности его работы. Другими словами, по метрикам все отлично (количество строк кода, потраченные на закрытие таска часы и т. п.), но пользы от такой работы для компании мало.

2. Один показатель производительности сможет нам раскрыть всю картину. Это не так. Обычно нужно использовать несколько метрик одновременно. И даже в этом случае они не будут 100%-ным показателем результата. Вы получите ориентир, который подскажет направление, но не «волшебную пулю», способную разом исправить все проблемы.

3. Показатели производительности полезны только менеджерам. На самом деле они нужны и разработчику. Глядя на них он будет лучше понимать, как ему давать оптимальный результат и получать удовольствие от работы.

Как поможет 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.

Если захотите изучить тему подробнее, рекомендую с ними ознакомиться. Спасибо, что дочитали до конца!