3 неденежных способа поощрения вашей команды разработчиков

Фотография Brands&People на Unsplash

Чего хотят разработчики?

Большие бонусы? Последний айфон? Новые часы? Хотя мало кто откажется от бесплатного халявы, мы думаем, что для создания привлекательной рабочей среды для разработчиков в 2022 году требуется гораздо больше, чем «вещи».

Зачем привлекать инженеров?

1: Удержание

Нынешний рынок талантов разработчиков является жестким, и ожидается, что он будет расти только с учетом того, что глобальная нехватка талантов, как ожидается, достигнет [85,2 миллиона к 2030 году] (https://www.kornferry.com/insights/featured-topics/future-of-work). ). В дополнение к этому, согласно [Stack Overflow] (https://stackoverflow.blog/2021/12/07/new-data-what-developers-look-for-in-future-job-opportunities/), 74% разработчиков в настоящее время открыты для новых предложений о работе. Если ваши разработчики не вовлечены и не получают удовольствия от своей работы, они могут покинуть гнездо и отправиться на пастбища в кратчайшие сроки, и все это за счет вашей организации.

2: Производительность

По данным Forbes, вовлеченные команды на 21% более прибыльны и на 17% более продуктивны. Любая техническая команда, которая хочет быть высокопроизводительной, должна иметь план взаимодействия, чтобы гарантировать, что разработчики находятся в среде, которая позволяет им выполнять свою работу наилучшим образом.

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

Но какие показатели важны для стимулирования разработчиков в 2022 году?

Фотография Japheth Mast на Unsplash

Какие показатели влияют на вовлеченность разработчиков?

Использование объективных фреймворков, таких как [фреймворк DORA] Google (https://services.google.com/fh/files/misc/dora_research_program.pdf), может стать важным фактором, стимулирующим разработчиков к повышению производительности.

Мы в Aadot считаем, что окончательный набор показателей разработчика можно разделить на три ключевых раздела; работа, благополучие и сотрудничество.

1: Работа

Упрощение понимания того, как выглядит «хорошо», очень мотивирует. Без этого мы рискуем оставить наши команды разработчиков работать разрозненно в стиле конвейерной ленты, выпуская код, но не зная, почему и насколько эффективно они это делают.

[Недавно мы написали блог о том, как Zoopla использует платформу DORA] (https://insights.adadot.com/?p=401), чтобы внедрить строгую научную теорию о производительности разработчиков в свою рабочую среду.

Сделать эти показатели прозрачными также жизненно важно, и с этим Gitlab справляется очень хорошо. Они публикуют всю свою [статистику производительности команды] (https://about.gitlab.com/handbook/engineering/development/performance-indicators/#sales-renewal-csat) на своем веб-сайте, чтобы каждый мог их увидеть. Это забирает силу метрик из скрытых комнат, полных управления, и передает ее в руки тех, кто находится на переднем крае разработки. Это не только делает производительность и тесты общедоступными, но также позволяет людям понять более широкое назначение этих показателей, показывая, к чему они приводят и почему.

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

2: Благополучие

Компания Stack Overflow провела некоторое исследование вовлеченности разработчиков, и, хотя конкурентоспособное вознаграждение остается проблемой номер один для разработчиков (70% респондентов), баланс между работой и личной жизнью не сильно отстает (48,3% респондентов). Необходимость уделять больше внимания благополучию очевидна, и это не должно ограничиваться вашим отделом кадров, оно должно распространяться и на то, как вы измеряете производительность.

[Структура DORA] (https://services.google.com/fh/files/misc/dora_research_program.pdf) не ограничивается работой в одиночку, ключевыми компонентами которой являются выгорание и рабочая среда.

Добавление этих измерений к метрикам, которые вы используете для поощрения производительности разработчиков, гарантирует, что вы распознаете правильное рабочее поведение; переключение средств повышения производительности с увеличения количества часов на повышение эффективности.

3: Совместная работа

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

Однако, снова используя DORA в качестве Библии, мы признаем, что метрики — это еще не все. Важно, чтобы вы освещали более мягкую сторону сотрудничества с помощью эффективных ретроспективных сессий, на которых фиксируются идеи непрерывного улучшения от разработчиков, чтобы их голоса были услышаны, а команда «[проверяла и адаптировала] (https://www.scaledagileframework.com/inspect-and -адаптировать/)' соответственно. Это также дает вашим разработчикам возможность самоорганизовываться и дает автономию, необходимую им для достижения успеха, переходя от любого намека на командно-административное управление к более гибким подходам лидерства-слуги.

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

Эта статья была впервые опубликована [здесь] (https://insights.adadot.com/2022/05/04/how-to-incentivise-developers/)