🔥

Тред (Настя Катаева)


Если вы прочитали предыдущий тред-знакомство, то уже поняли, что я пришла в деврел из разработки. Когда я рассказываю об этом вживую, то в ответ часто ловлю удивлённый возглас собеседника: «Это ж нафига ты так сдауншифтилась?»

Конечно, если размышлять в парадигме «ушла из разработки в HR», то это выглядит неразумно. Щас объясню, почему так думать неправильно.

Давайте вспомним слова любимого @jbaruch про то, что DevRel — это вовсе не человек, а целое направление деятельности. Оно про коммуникацию компании и разработчиков.

Если компания продаёт продукты для инженеров (как, например, JetBrains), то DevRel в этой компании берёт на себя следующие задачи: — прокачивает опыт взаимодействия пользователя с продуктом, — собирает обратную связь и доносит массовые боли до своих разработчиков,

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

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

В этом случае, вроде как DevRel и HR вообще никак не пересекаются. Давайте усложнять. Переходим к нашему случаю: компания разрабатывает сервисы, которые вообще не про разработку. Например, делает сервисы для автоматизации бизнеса.

В этом случае продуктом DevRel-команды становится сама компания. И вот какие задач берут на себя её деврелы: — увеличивают узнаваемость компании среди разработчиков, — прокачивают взаимодействие разработчиков с компанией через технические кейсы, опенсорсы и совместные активности,

— отлавливает тренды (aka четырёхдневная рабочая неделя), собирает массовые боли (aka тупые долгие собеседования) и приносит эту информацию тем чувакам в компании, которые могут на это влиять (спойлер: иногда это сам деврел),

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

Ну и чо, сильно этот список отличается от списка задач деврелов в JetBrains? НИ ХЕ РА 🌈 А теперь скажите мне, способен ли человек без опыта разработки выполнять задачи из этого списка хоть сколько-нибудь хорошо?

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

Давайте резюмируем: — DevRel — это не про хантинг разработчиков, — DevRel — это про коммуникации с инженерами. Мы не просто подсвечиваем хорошие стороны в продукте/компании, а выясняем, что можно сделать лучше. Если есть кому делегировать — отдаём, если нет — идём и меняем сами.

Настя КатаеваНастя Катаева