Сегодня рассказываем про интересную инженерную специальность — DevRel-инженер.
Если вы были на конференциях для разработчиков, проходили обучающие курсы по программным продуктам или слушали технический подкаст, то скорее всего, вы видели финальный продукт работы специалистов DevRel. Это направление может называться по-разному: Developer Advocacy, Developer Experience или Developer Evangelism. Но самый распространённый вариант названия на русском — Developer Relations, то есть «отношения с разработчиками».
В отличие от разработчиков фронтенда и бэкенда и тестировщиков, у DevRel меньше чётких обязанностей, но при этом часто больше ответственности за то, как выглядит компания в глазах людей. Получается техническая бизнес-профессия, где нужно общаться с разными людьми. Дальше рассказываем, как это уживается в одном человеке.
Что за профессия и что там делают
DevRel нужен, чтобы разработчики понимали продукт, доверяли ему и могли успешно использовать его в своих проектах. Для этого специалист выстраивает отношения с технической аудиторией, помогает ей разобраться в продукте и приносит внутрь компании обратную связь.
Developer Relations включают в себя 4 составляющих:
- Advocacy или Защита интересов. Означает, что специалист выступает двусторонним переводчиком между компанией и разработчиками. Он общается с разработчиками и потом приносит внутрь компании их боль: документация непонятная, API работает неоптимально, инструмент не покрывает важный сценарий. В обратную сторону это тоже работает: например, нужно объяснять инженерам, как работает продукт и почему есть определённые ограничения.
- Community Engagement или Взаимодействие с сообществом. Это выступления на конференциях, чаты в мессенджерах, митапы и хакатоны. Смысл всех этих мероприятий в том, чтобы разработчики не оставались один на один с продуктом. Они могут задавать вопросы, делиться решениями, смотреть чужие примеры решений. Для компании это полезно, потому что вокруг продукта появляется живая среда. Новому разработчику проще начать, если он видит, что продуктом уже пользуются другие. При этом это не значит, что в DevRel обязательно нужно где-то выступать: список того, что может делать специалист, довольно широкий. Чаще всего они делятся между членами команды в зависимости от опыта и навыков.
- Education или Обучение. DevRel может создавать или помогать в создании статей, туториалов, видео, демо-проектов. Например, компания выпускает новый API. Просто дать справочник методов мало. Разработчику нужно понять, как быстро сделать первый рабочий пример, подключить авторизацию, обработать ошибку. Эти вопросы должно закрывать обучение как обязанность DevRel.
- Technical Support или Техническая поддержка. DevRel может отвечать на вопросы, разбирать проблемы, помогать партнёрам или клиентским разработчикам. Но чаще всего это не первая линия поддержки, а более глубокие вопросы о встраивании API, ошибках интеграции, выборе модулей продукта для конкретной задачи.
DevRel может быть консультантом для тех, кто что-то разрабатывает поверх продукта — например, собственные кастомизированные решения для основного сервиса. А ещё специалисты из техподдержки могут перейти в DevRel — и это будет очень хорошим опытом для новой должности, потому что техподдержка тоже помогает пользователям и разработчикам разобраться в продукте.
Откуда появилась эта должность
Точной даты рождения у профессии нет, но первым появлением DevRel можно считать начало
Роль популяризировал Гай Кавасаки, который работал как software evangelist Apple в
Современный термин Developer Relations появился позднее — примерно в
Какие навыки нужны в DevRel
Сначала главное: точные обязанности в роли DevRel могут сильно меняться в зависимости от компании и периода её существования. Но есть несколько вещей, которые почти наверняка пригодятся.
Разбираться в продукте
DevRel должен хорошо понимать продукт, потому что он объясняет его разработчикам, партнёрам и внутренним командам.
Для работы важно знать не только возможности и функции сервиса, но и более внутреннее устройство: модули, ограничения, типовые сценарии. Это глубокая экспертиза: специалист помогает всем внешним разработчикам понять технологию и приносит внутрь компании обратную связь о том, как продукт используют на практике.
Уметь читать код
DevRel нужна техническая база: умение читать код, видеть логику программы и разбираться в незнакомых фрагментах.
Почему это важно: DevRel часто работает с документацией, техническими примерами и обратной связью от разработчиков. Здесь важна техническая глубина и настоящая экспертиза. Поэтому читать код — обязательное требование. Хорошо подготовленный DevRel должен уметь построчно объяснить код, а если встречает незнакомую функцию — стараться понять её смысл по контексту, синтаксису и общей логике программирования.
Доводить задачу до конца
DevRel часто работает с задачами, где нет готовой инструкции: нужно разобраться в проблеме, найти источник, проверить гипотезу, собрать пример.
Многое на этом пути будет сначала непонятно, поэтому важно умение дойти до понятного результата: объяснения, решения или хотя бы точной формулировки проблемы. Можно сказать, что это связано с любопытством и желанием досконально разобраться в продукте. Похожую мысль можно встретить в описании роли Developer Advocate: он превращает обратную связь сообщества в конкретные действия для продукта.
Разрабатывать автоматизацию
DevRel должен замечать повторяющиеся процессы, которые отнимают время, и понимать, где их можно автоматизировать.
Пример — сбор статистики по репозиториям: данные лежат в разных источниках, и каждый месяц на их ручной сбор уходит день. Значит, можно написать скрипт, который сам забирает данные, объединяет их и строит графики. Получается, что DevRel строит внутреннюю инфраструктуру, которая помогает разработчикам быстрее работать.
Самому писать код необязательно — достаточно понимать, как правильно поставить задачу ИИ-агенту и проверить результат.
Это команда или одиночные специалисты?
DevRel может начинаться с одного инженера, а по мере роста — превратиться в команду.
Один человек вполне способен закрывать первые задачи: писать материалы, общаться с разработчиками, собирать обратную связь. Если вокруг продукта появляется больше разработчиков, DevRel может вырасти до нескольких сотрудников или даже разделиться на несколько направлений, например на обучение, комьюнити, инженерные инструменты. В некоторых компаниях отдельного DevRel-отдела нет, потому что его функции распределены между разработкой, маркетингом, документацией и поддержкой.
Разные люди в команде могут отвечать за разные задачи — это зависит от их навыков и сильных сторон. Один человек может лучше разбираться в разработке и делать демо-проекты или автоматизацию, другой — общаться с разработчиками-клиентами и собирать обратную связь. Кто-то сильнее в публичных выступлениях и берёт на себя внешнюю коммуникацию. Так команда закрывает разные стороны DevRel: инженерную, образовательную, продуктовую и публичную.
Откуда приходят в DevRel
Лучший способ попасть в эту профессию — перейти в DevRel внутри продукта. То есть сменить трек развития из разработки, тестирования, документации, технической поддержки. Такому человеку проще накопить продуктовую экспертизу и понимать реальные проблемы пользователей.
Получается, что в идеальном варианте человек должен какое-то время проработать внутри продукта. Ему должен быть интересен сам продукт: без этого сложно убедительно объяснять его разработчикам, поддерживать партнёров и развивать доверие.
При этом всегда сохраняется возможность, что специалиста нанимают со стороны: это зависит от того, какие задачи нужно выполнять в команде и каких специалистов не хватает.
Что нужно развивать после перехода из других специальностей
После перехода из смежной специальности DevRel важно начать смотреть на задачи шире. Например, в поддержке специалист обычно разбирает конкретное обращение: почему не работает этот сценарий и как помочь здесь и сейчас. DevRel работает с теми же сигналами, но должен думать, как эти проблемы влияют на компанию и продукт в целом и как сделать так, чтобы проблемы не повторялись.
Поэтому один из главных навыков для развития — умение доходить до источника проблемы. DevRel не ограничивается ответом на вопрос разработчика, а пытается понять, почему этот вопрос возник: не хватает примера, непонятно описан метод, неудобно устроен сценарий или в продукте есть ограничение, о котором нужно предупредить. Это пограничный навык: в нём есть и техническое мышление, и любопытство, и способность переводить отдельные запросы в выводы для продукта.
Как меняется роль DevRel с развитием AI и вайбкодинга
С развитием AI и вайбкодинга роль DevRel может стать ещё важнее, потому что теперь он становится связующим звеном между продуктом и людьми, которые начинают сами собирать решения поверх продукта.
Пользователь или клиентская команда могут с помощью AI быстро написать доработку, отчёт или интеграцию, но им всё равно нужна экспертиза: например, понимать, какие ограничения нужно учитывать и как не сломать архитектуру. В таком контексте DevRel работает как технический консультант. Он помогает не тратить время и токены на случайный поиск решения, а сразу направляет разработчика или вайбкодера к правильному сценарию. В отличие от искусственного интеллекта DevRel понимает продуктовую логику, архитектуру и последствия решений.
Различаются ли навыки DevRel по уровням
Навыки DevRel редко делятся как жёсткий список инструментов для разных уровней джуна, миддла и сеньора. Чаще различаются зоны ответственности внутри команды. Один специалист может лучше понимать backend и архитектуру, другой — дизайн интерфейсов или developer experience.
По мере развития роли у DevRel появляются задачи, которые связаны уже не только с контентом или технической экспертизой, но и с организацией работы команды. Особенно это заметно на уровне team lead: нужно продумывать процессы, регламенты, распределять ответственность. DevRel в такой позиции отвечает за то, чтобы команда могла стабильно создавать полезные инструменты и материалы. Часть этой работы может выглядеть внутренней, но результат всегда направлен наружу — на партнёров, клиентов и внешних разработчиков.
Где учиться на DevRel
В эту роль часто приходят из областей, где человек уже сталкивался с продуктом, разработчиками и техническими задачами. Поэтому DevRel проще воспринимать как синтетическую профессию на стыке инженерии, коммуникации, обучения и продуктового мышления.
Получается, что у DevRel чаще всего нет очевидной образовательной траектории, как у некоторых классических IT-специальностей. Это скорее рост и трансформация из другой IT-должности.
Плюсы и минусы профессии
Из-за разносторонности профессии плюсы DevRel могут быть одновременно минусами.
Есть плюсы: глубокое погружение в продукт, влияние на его развитие и возможность помогать сразу нескольким аудиториям: внутренним командам, клиентам и партнёрам. В этой роли обычно много разных задач: сегодня нужно разобраться в техническом сценарии, завтра — помочь с документацией или обсудить проблему с партнёром. Это разнообразие даёт развитие и пространство для творческого подхода.
Из тех же особенностей вырастают минусы. В DevRel часто нет жёстко очерченного набора обязанностей, поэтому специалисту приходится работать в условиях неопределённости и самому понимать, где его участие принесёт больше пользы. А ещё это социальная роль: нужно регулярно общаться с разными людьми, а значит, одной технической экспертизы может быть недостаточно.
Будет ли расти роль DevRel и стоит ли туда целиться
Будущее DevRel сложно описать одним прогнозом, потому что сегодня в разных компаниях эта роль развивается по-разному. Специалист Developer Relations особенно важен там, где продуктом пользуются разработчики, где нужно публично объяснять технологию и поддерживать доверие к компании.
С развитием AI эта роль может стать заметнее: компании должны объяснять, как устроены их инструменты, где проходят границы безопасности и что происходит с кодом и клиентской информацией. В такой среде DevRel помогает не только продвигать продукт, но и поддерживать профессиональное доверие: показывать экспертизу, отвечать на сложные вопросы и помогать разработчикам безопасно применять новые технологии.
Источник: Владимир Верхотуров, Team Lead отдела Продуктовый DevRel в Битрикс24
