[Перевод] От DevOps к DevEx: не мешайте работать инженерам

368104b7324f99d6a260580d55d3b2ef.png

У компаний, стремящихся привлечь и удержать лучших технических специалистов, появляется новая цель — сделать так, чтобы им было приятно работать.

Поскольку мир все больше живет новыми технологиями, технические специалисты все так же важны для бизнеса, как и раньше. По прогнозам, к 2024 году численность разработчиков во всем мире приблизится к 29 млн человек (превысив все население Австралии), но все равно будет едва поспевать за ростом спроса, как уже обсуждалось в отчете «Технологические тренды 2023». Несмотря на этот рост, производительность разработчиков в большинстве организаций далека от оптимальной: на разработку функциональности они обычно тратят только 30–40% времени.

Читайте новою главу отчета Tech Trends 2024 от Deloitte в переводе Хабр-редакции КРОК под катом!

В последние годы повсеместным стал переход к Agile, DevSecOps и облачному инжинирингу, поскольку так повышается скорость, качество и улучшается кросс-функциональное взаимодействие. Теперь у тех, кто хочет привлечь и удержать лучшие кадры, появляется новая цель — «Developer Experience» (DevEx), т.е. такой подход, когда работа инженеров-программистов ставится во главу угла и делается все, чтобы они работали эффективно и с удовольствием, для чего прорабатываются все точки их касания с другими отделами внутри организации.

Руководители сходятся во мнении, что чем лучше работается программисту, тем довольнее конечные пользователи и клиенты, и это все сильнее смещает акцент с измерения скорости и количества на предоставление подходящих инструментов, платформ и механизмов обратной связи и, в конечном итоге, на создание культуры, ориентированной на разработчиков. Скорость и тому подобные метрики (число строк кода или сторипойнтов на одного разработчика) уступают место более целостным показателям, таким как: 1) время до первого запроса на включение изменений (pull request), т.е. сколько времени требуется разработчику для публикации своего первого крупного пакета кода; 2) изменения в бэклоге; и 3) коэффициенты дефектов. На смену децентрализованным командам и фрагментированным наборам инструментов приходят pod-структуры («простые структуры данных»), которые формализуют сотрудничество команд, занятых проектированием, пользовательским опытом, киберпространством, рисками, управлением качеством и продуктами. Сюда же стоит добавить адаптивное управление производительностью, а также упрощение архитектуры и инструментария. Что хорошего во всех этих изменениях? 81% компаний осознали, что инвестиции в создание условий для разработчиков оказывают умеренное или даже серьезное влияние на прибыль.

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

Вчера: инженеры пользовались большим спросом, но им мешали работать

Недавняя пандемия COVID-19 ускорила цифровую трансформацию. 85% руководителей компаний по всему миру подтверждают, что форсировали трансформацию в своих организациях  после 2020 г., и ожидают, что расходы на цифровую трансформацию вырастут в 2024 г. до $2,51 трлн, что почти вдвое превысит показатель 2020 г. Рост инвестиций привел к повышению роли руководителей и сотрудников технологических отделов, о чем говорилось в «Глобальном исследовании роли руководителей технических отделов» за 2023 г. Компании из разных — не только технологических — отраслей включают ПО в свои основные предложения для клиентов и операционную инфраструктуру. Взять хотя бы разрабатываемые автопроизводителями алгоритмы беспилотного вождения и платформы для организации связи между автомобилями, которые позволяют оказывать новые транспортные услуги. Кроме того, стоит вспомнить про использование промышленными производителями подключенного оборудования (такого как турбины и генераторы) для сбора данных о производительности, выявления проблем до сбоев и оптимизации планирования технического обслуживания;, а также про приложения дополненной реальности, которые позволяют покупателям виртуально примерять одежду. Безупречный код и программисты, которые могут его написать, имеют решающее значение для компаний, так как позволяют воспользоваться благоприятными возможностями трансформации.

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

Государственные и коммерческие компании стремятся привлечь и удержать разработчиков, следуя по стопам передовых технологических компаний. Например, внедрение CI/CD-конвейеров приводит к более частым релизам кода; идея «сдвига влево» требует добавления автоматизации и тестирования на более ранних этапах процесса разработки ПО;, а комплексное проектирование позволяет техническим специалистам участвовать во всех аспектах разработки продукта (фронт-энд, бэк-энд, веб и т.д.) посредством моделирования, моделей стажировки и ротации.

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

Более того, разработчиков обычно загоняют в тесные рамки корпоративных KPI, что мешает им чувствовать удовлетворение от работы. Вдобавок ко всему, распространение платформ low-code и no-code, где нужно мало кода или он не нужен вовсе (Appian, Outsystems и Zoho Creator), снизило порог для «вступления в ряды разработчиков ПО» и породило идею о том, что «программировать может кто угодно». В итоге появляются не только новые возможности, например, ускорение инноваций за счет децентрализации разработки ПО в компании, но и риски, связанные со стратегическим управлением, безопасностью и накоплением технического долга.

Программисты страдают от рутинных задач, мешающих им заниматься собственно программированием

Рисунок 1

Рисунок 1

Источник: Stripe, «Коэффициент использования программистов», сентябрь 2018 г.

Пытаясь обеспечить программистам оптимальные условия труда, руководители отделов разработки сталкиваются с целым комплексом проблем. Разовые меры тут не помогут. Нужно в целом изменить подход к организации труда программистов и дать им инструменты, метрики и процессы для достижения успеха. Только так можно привлечь и удержать лучшие кадры.

Сегодня: DevEx меняет правила игры

При переходе на DevOps упор делался на инструменты и фреймворки повышения производительности. DevEx же сочетает в себе совокупность взаимодополняющих возможностей, которые организация предоставляет разработчикам, чтобы те были максимально продуктивны и довольны и работали в так называемом «круге благоприятных возможностей». Программисты, работающие с нужными инструментами, процессами и в подходящей культуре, обычно показывают более высокие результаты. И действительно, по данным Harvard Business Review, сотрудники демонстрируют большую вовлеченность (+230%) и более склонны оставаться на своей работе дольше 3 лет (+85%), если есть технологии, помогающие им в работе. В свою очередь, довольные жизнью программисты могут двигаться вперед быстрее, выдавать код чаще и эффективнее взаимодействовать с коллегами.

Чтобы реализовать этот круг благоприятных возможностей, организациям нужен новый тщательно продуманный фреймворк, который учитывает все, что влияет на разработчиков, а не только инструменты и профессиональное развитие. Переход на DevEx может повысить как производительность продуктов, так и качество обслуживания клиентов.

Организации могут повышать эффективность и профессиональный уровень инженеров унифицированными средствами.

Платформы и инструменты

Способы работы в потоке

Профессиональное развитие

—  Архитектура

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

—  Акселераторы разработки

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

—  Сообщество и культура

Формирование и продвижение комфортной, продуктивной и разнообразной рабочей среды

—  Измерительные инструменты

Сбор данных о работоспособности платформы, использовании продуктов и эффективности разработчиков

—  Владение сервисами

Назначение владельца сервиса и ответственного за интеграцию на весь жизненный цикл для снижения рисков

—  Непрерывное обучение

Разработка образовательных программ для инженеров на протяжении всей их работы в компании

—  Инструменты поддержки

Создание инструментов для взаимодействия и обмена знаниями между инженерами

—  Управление рабочими процессами и DevSecOps

Более организованная и скоординированная деятельность как залог достижения результата

—  Карьерный рост и развитие

Предоставление инженерам возможностей карьерного роста на всех этапах их работы в компании 

Источник: Анализ Deloitte.

Платформы и инструменты

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

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

•    Измерительные инструменты — сбор данных о работоспособности платформы, использовании продуктов и эффективности разработчиков.

•    Инструменты поддержки — создание инструментов для совместной работы и обмена знаниями между инженерами.

Ведущие организации подхватили этот тренд и создают для разработчиков единые платформы, где те могут получить доступ к хранилищу исходного кода, информации для новых сотрудников, документации, инструментам, наборам средств разработки ПО (SDK) и многому другому. Сегодня доступ к такому порталу имеют лишь 37% разработчиков, но, по оценкам Gartner, к 2025 г. 75% организаций с командами, работающими на единых платформах, будут предоставлять разработчикам порталы самообслуживания, чтобы улучшить их условия труда и ускорить инновации.

Способы работы в потоке

Как только идеальные технологии (то есть платформы и инструменты) будут созданы, вторым аспектом DevEx станет построение прозрачных непрерывных процессов для разработчиков, чтобы они могли выполнять задачи в потоке и без помех (как то отключение систем или плохое стратегическое управление). Есть три аспекта для решения этой проблемы:

•    Акселераторы разработки — повышение эффективности и снижение числа помех в повседневной деятельности, связанной с разработкой.

•    Владение сервисами — назначение владельца сервиса и ответственного за интеграцию на весь жизненный цикл для снижения рисков.

•    Управление рабочими процессами и DevSecOps — более организованная и скоординированная деятельность как залог достижения результата.

Лучший вариант для разработчика — единый корпоративный процесс и конвейер для валидации и тестирования кода, измерения производительности и безопасного отката к предыдущим версиям кода без сбоев. И хотя передовые технологические компании именно к этому и стремятся, предприятия в других отраслях улучшают DevEx описанными выше способами.

Так, например, CarMax, крупнейший американский продавец подержанных автомобилей, добился явного успеха в модернизации процессов разработки. IT-департамент заменил проектную модель работы продуктовой моделью, основанной на кросс-функциональных командах. Вместо того, чтобы оценивать разработчиков по завершенным проектам, компания CarMax начала устанавливать прозрачные квартальные цели, чтобы разработчики смогли выдавать код чаще. Уделив огромное внимание быстрому тестированию продуктов с участием партнеров и клиентов, компания смогла собирать отзывы и выполнять итерации перед внедрением новой функции. Аналогично, после того как Etsy вложила 20% своего инженерного бюджета в DevEx, ей удалось увеличить штат с 250 человек до почти 1000.

Профессиональное развитие

Наконец, чтобы изменения в процессах и технологиях были приняты, нужна соответствующая культура с фокусом на потребности инженеров. Разработчики во многих компаниях по-прежнему специализируются на традиционных языках и способах работы, которые были характерны еще для мэйнфреймов, в то время как другие готовы тратить время на инновации и идти к целям, которые им созвучны. Компании, стремящиеся привлечь и удержать таких специалистов, могут делать упор на следующее:

•    Сообщество и культура — формирование и продвижение комфортной, продуктивной и разнообразной рабочей среды (это очень важно в технических подразделениях).

•    Непрерывное обучение — разработка образовательных программ для инженеров на протяжении всей их работы в компании. Учитывая, что многие инженеры черпают знания из самых разных источников и пользуются разными методологиями (включая блоги, онлайн-курсы, книги и формальное образование), компаниям как никогда важно унифицировать адаптацию новых сотрудников и обучение.

•    Карьерный рост и развитие — предоставление инженерам возможностей карьерного роста на всех этапах их работы в компании, как уже обсуждалось в отчете «Технологические тренды» за прошлый год. Так, например, Citibank создал карьерные треки для инженеров, желающих и дальше совершенствовать свои технические навыки, что позволит им быть в курсе последних трендов в области программирования. Ставя технические знания во главу угла, компания помогает сотрудникам строить карьеру в долгосрочной перспективе и с серьезным уклоном в технику, открывая перед инженерами разнообразные и привлекательные возможности для развития.

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

В ходе собственной трансформации компания CarMax уделила пристальное внимание не только самим процессам, но и работе с людьми. Помимо физического перемещения сотрудников в кросс-функциональные команды, чтобы IT-специалисты не были изолированы от остального штата, компания организовала демонстрации продуктов. Чтобы повысить прозрачность процесса и услышать отзывы от высшего руководства, каждые две недели инженеры рассказывали о технологических возможностях того, что они разрабатывают, а также о результатах и усвоенных уроках. А чтобы еще больше подчеркнуть возросшую роль технических специалистов, IT-департамент был официально переименован в CarMax Technology и ориентирован на бизнес-результаты, а не на традиционные для IT-требования и сроки.

Завтра: каждый работник — технический специалист

Компании часто надеются нанять «экстраординарных» инженеров, которые будут в 10 раз продуктивнее среднего разработчика. Но поиск таких «зубров» на рынке труда редко приносит результат. Вместо этого, при наличии правильных платформ, процессов и культуры, такие уникумы будут встречаться не так уж редко. Учитывая, что генеративный ИИ продолжает повышать производительность разработчиков и открывает возможности для автоматизации рабочих мест, многие из сегодняшних помех могут исчезнуть в ближайшие пять-десять лет. Рассуждая в прошлом году о тренде на «серийных специалистов», аналитики Deloitte отмечали, что инженеры, которые стремятся решать все более и более сложные задачи, смогут использовать инструменты повышения производительности, чтобы высвободить свое время для работы над новыми интересными проектами и технологиями.

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

Вместо того, чтобы десятикратно наращивать производительность отдельного инженера, можно сделать так, чтобы в развитии своих технических компетенций остальные сотрудники-нетехнари просто прошли путь от нуля до единицы. Этим программистам-любителям, вероятно, будет проще в будущем, когда наиболее распространенным языком программирования будет не Python или Java, а английский или любой другой естественный язык, который они выберут.

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

Продолжение следует

Отчет Tech Trends 2024 от Deloitte в переводе Хабра-редакции КРОК:  

Часть 1: Исследование «Технологические тренды 2024». Противостояние интеллектов 

Часть 2: Цифровой и физический мир без границ: пространственные вычисления и промышленная метавселенная 

Часть 3: Выпустили джинна из бутылки: генеративный ИИ — катализатор роста

Часть 4: Нужно работать не больше, а эффективнее: не железом единым

© Habrahabr.ru