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

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

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

Что такое опыт разработчика (DX)?

Опыт разработчика (DX) - это опыт, который получает разработчик при выполнении определенной задачи или работе.

Хотя это определение может показаться упрощенным, его реальное значение многогранно и сложно.

DX для инструментов

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

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

Альберт Кавальканте написал пост о DX для инструментов разработчика, в котором также показал связь DX и пользовательского опыта (UX). Он перечисляет следующие основные факторы для хорошего DX инструмента разработки:

  • Функция: инструмент выполняет то, что должен делать.
  • Стабильность: Инструмент надежен и работает, когда это необходимо. Если возникают ошибки, они исправляются как можно быстрее.
  • Простота использования. Инструмент интуитивно понятен - вы можете найти всю необходимую информацию, и есть умные настройки по умолчанию. (Это включает в себя не только пользовательский интерфейс, но и такие вещи, как документация, шаблоны, ярлыки, поддержка сообщества и т. Д.)
  • Ясность: инструмент отображает всю необходимую информацию в понятной форме и обеспечивает полную видимость последствий любого действия.

Помимо того, что упомянуто в статье, безусловно, есть и другие вещи, которые следует учитывать, когда вы предоставляете инструмент с отличным DX, например:

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

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

Наш опыт

Мы в DevSpace, как поставщик инструментов для разработки, поняли, что на самом деле у нашего решения даже больше, чем один опыт. С одной стороны, обычно есть кто-то, настраивающий DevSpace / Loft - администратор - которому нужен подробный доступ и обзор, а также техническая база рядом с Kubernetes.

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

DX в командах

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

Опять же, чтобы иметь действительно хороший DX в команде, играют роль многие факторы:

  • Коммуникация. Коммуникация должна быть четкой и стандартизированной. Сюда входят инструменты, используемые для общения (например, личное, чат, электронная почта, телефон и т. Д.), А также аудитория (т. Е. Правильное общение с нужным человеком).
  • Стандартизация рабочего процесса: все в команде должны использовать один и тот же рабочий процесс для одной и той же задачи, чтобы избежать дополнительных проблем и конфликтов. Например, это может включать стандартизированный процесс тестирования и отладки перед развертыванием.
  • Выбор набора инструментов. Все в команде должны использовать одни и те же инструменты для одной и той же задачи, и они должны быть настроены одинаково. (Идентичная конфигурация в основном включает общие инструменты, такие как инструменты CI / CD или промежуточные среды. Конечно, это не означает, что у всех должны быть одни и те же настройки / пользовательские предпочтения, такие как темный режим в среде IDE.)
  • Документация. Не только существующее программное обеспечение, но также рабочие процессы и процессы должны быть должным образом задокументированы, а документация должна быть простой для понимания и использования.
  • Адаптация. Если к команде присоединяются новые разработчики, должно быть ясно, что они должны делать. Им нужно знать, какие инструменты им следует установить и использовать, какие задачи следует выполнять и к кому обращаться со своими вопросами.

Этот список, вероятно, можно было бы расширить за счет многих других факторов. Однако уже должно быть ясно, что обеспечить все это и поддерживать в актуальном состоянии не всегда легко. Вот почему я хочу предложить новую роль в командах разработчиков: владелец опыта разработки, DXO.

Владелец опыта разработки (DXO)

Кто такой владелец опыта разработки (DXO)?

DXO - это член группы инженеров, которому поручено заботиться о DX команды, выбирая и настраивая инструменты, определяя рабочие процессы, адаптируя новых членов команды и являясь центральным контактным лицом по всем вопросам, касающимся DX.

Типичные задачи DXO

Задачи, которые должен выполнять DXO, столь же многогранны, как и сам DX. Как правило, DXO должен нести ответственность за выбор инструментов, используемых в команде. DXO должен постоянно оценивать, оптимальны ли используемые в настоящее время инструменты для поставленных задач, и определять, следует ли их заменить или настроить по-другому.

Инструментальный ландшафт, особенно в CI / CD, развивается очень быстро, и средний разработчик не хочет управлять связанными с ним процессами. Здесь разработчикам часто требуется доступ к промежуточной среде, которой также может управлять DXO, либо посредством управления самой промежуточной средой, либо посредством управления доступом разработчиков к ней .

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

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

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

Преимущества DXO

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

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

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

Конечно, всего этого можно достичь без специального DXO. Однако, подобно концепции владения кодом, владение DX налагает ответственность за него. Также будет легче поддерживать синхронизацию в команде, потому что в процессе принятия решений будет меньше людей.

Роль DXO

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

Обычно для этого требуется более высокий пост для DXO, но я считаю, что в этом нет необходимости, если в противном случае можно найти подходящего кандидата.

Как правило, DXO должен иметь исключительное понимание программной инженерии и связанных с ней процессов. Если предполагается, что DXO управляет командой как с фронтенд-инженерами, так и с админ-инженерами, это должен быть человек, который понимает оба мира. Поскольку эта роль также часто включает CI / CD, понимание DevOps или даже операционных технологий, безусловно, также будет полезным.

Еще одна очень важная черта идеального DXO - это способность общаться очень эффективно, но при этом сочувственно. Им нужно быть доверенным лицом, к которому члены команды могут обращаться даже с «глупыми» вопросами. Это также требует очень хорошей репутации у своих коллег, поскольку DXO должны иметь право принимать решения.

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

Наш опыт

Роль DXO уже существует во многих командах, но не называется DXO. Обычно это довольно неявная роль, которую берет на себя кто-то в команде.

Судя по нашему опыту предоставления инструментов разработчика DevSpace, неявные DXO часто первыми испытывают наши решения. Они оценивают их и часто также настраивают их для сценария использования своей команды, если они решили представить их своим компаниям. Обычно мы видим, что у этих неявных DXO есть официальные роли, такие как вице-президент по разработке, старший инженер или инженер DevOps.

Рекомендации и заключение

Некоторые компании уже нанимают DX-инженеров, но это в основном внешняя роль для инженера, отвечающего за SDK, используемых внешними разработчиками, или который работает в качестве разработчика программного обеспечения с открытым исходным кодом. Я считаю, что внутренняя роль, заботящаяся об опыте ваших собственных разработчиков, по крайней мере так же важна, как и внешняя.

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

Так что, возможно, подумайте о своей команде или поспрашивайте, есть ли уже неявный DXO. Если нет, вам следует подумать о повышении кого-то до DXO. И если он есть, вам действительно стоит подумать о том, чтобы ценить то, что они делают, чтобы сделать своих коллег счастливыми, а инженерные процессы лучше, дав им дополнительный титул, больше времени и, возможно, повышение за важную работу, которую они делают.