Что изменилось в понимании Developer Experience за последнее время?

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

Если раньше в большинстве стартапов разработчики выполняли функцию исполнителя, то сейчас они не только молча пишут код, но и влияют на весь процесс разработки. И формируют свой Developer Experience.

UX или DX: что важнее?

Каждый, кто взаимодействует с продуктом, знает, как важно учитывать опыт пользователя (User Experience) при создании того или иного функционала. Пару десятилетий назад это определение только входило в моду, а сейчас практически в каждой IT-компании есть UX/UI-дизайнеры, UX-писатели и ресерчеры.

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

Сегодняшний девелопер тратит на написание кода треть своего рабочего времени — гораздо больше ресурсов уходит на его сопровождение, тестирование, устранение багов и многое другое. Все это и составляет Developer Experience или, проще говоря, опыт разработчика.

Почему важно развивать DX в команде?

DX это своеобразный эквивалент UX, только основным пользователем продукта тут является разработчик. Опыт разработчика учитывается при использовании продукта, SDK или API, документации, библиотек, фреймворков. И если вся команда учитывает принципы Developer Experience — у разработчика появляется больше времени на модернизацию продукта и он меньше ресурсов тратит на хаотичную замену костылей и правку багов.

Особенно это относится к маркетологам, которым часто нужно что-то выкатить на прод еще вчера. Им кажется, что написать код и внедрить его в уже существующий функционал так же просто, как отправить email-рассылку, поэтому когда в ответ маркетолог слышит: “Сделаем в течение двухнедельного спринта” он начинает недоумевать.

В итоге в команде возникает конфликт, все делается на скорую руку, а страдает ни в чем не повинный пользователь, который получает некачественный продукт. Если не налажена разработка и отсутствует DX — крутой интерфейс, маркетинг, гениальные идеи не смогут скрыть плохую функциональность продукта. Но, ребят из маркетинга можно понять — только их приучили к значимости UX и кастдева, так теперь еще нужно учитывать капризы разработчиков.

Но процесс идет, API внедряется, MVP реализуется, no-code и law-code платформы становятся все популярнее, а это значит, что у разрабов появляется больше времени на то, чтобы оторваться от монитора, выдохнуть и реализовать весь свой Developer Experience, ускорив тем самым неизбежную эволюцию ПО и технологических стеков.

0
2 комментария
Андрей Синицын

Law-code? Серьезно? :D

Ответить
Развернуть ветку
Дмитрий Колосов
Автор

Конечно нет) Low-code платформы имелись ввиду, досадная очепятка.

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда