{"id":13472,"url":"\/distributions\/13472\/click?bit=1&hash=4a05616fb570ab538ab8c04fa1f08afa00a090b2c2700fcd6146507f1b1658df","title":"\u041a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0431\u043e\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435 \u0431\u0443\u0434\u0435\u0442 \u0431\u0435\u0441\u0438\u0442\u044c \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}
Yulia Murashova

Какие задачи решают Developer Relations: роли, подходы, результаты

Сейчас в мире IT происходят не только технологические прорывы, но и формируется новое направление, связанное с коммуникациями - Developer Relations. Чем занимается DevRel? Зачем это нужно и какие задачи решает? В этой статье вы найдете ответы на эти вопросы, а также систематизированную картину на основании западного опыта и моей практики реализации DevRel проектов как в СНГ, так и на глобальном рынке.

Чем занимаются Developer Relations?

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

Почему Developer Relations оформились в отдельное направление? Потому что настройка коммуникаций с разработчиками и IT миром в целом - это большая проблема для бизнеса. Сегодня DevRel решает много бизнес-задач через коммуникацию с сообществами и создание новых вокруг своих продуктов и своего бренда в целом.

Немного примеров:

  1. IT-компании ведут блоги, где разработчики пишут для разработчиков, например Slack Platform blog, Google developers на medium.
  2. Такие гиганты, как Google или Amazon, создают вокруг своих продуктов и технологий глобальные сообщества, например Google cloud AI developer community или AWS Community.
  3. Вне зависимости от размера, бизнес все активнее участвует в IT-конференциях и создают свои каналы транслирования экспертизы в комьюнити. Яркий пример - Мероприятия Яндекса.

Developer Relations - это большая функция, которая может решать разные задачи. Они могут лежать как в плоскости b2c, так и в b2e. Что я имею ввиду:

  • Например, DevRel отдел в компании JetBrains будет заниматься продвижением Kotlin, созданием сообщества вокруг этого языка программирования и плотной коммуникацией с Kotlin-сообществом. Эта деятельность лежит в пространстве b2c (business-to-customer).

  • DevRel в компаниях, которые не делают продукт для разработчиков, будет сфокусирован на работе с имиджем компании, как работодателя (через конференции, митапы, блоги). Это пространство b2e (business-to-employees).

Таким образом, пространство и бизнес-задачи, в рамках которых работают Developer Relations, рождают особенности в ролях и KPI. Давайте разберем, а в чем состоят эти особенности, и действительно ли есть большая разница между DevRel для продвижения продукта и для бренда компании.

Developer Relations в b2c: продвижение продуктов для разработчиков

Компания, создавая какой-то программный продукт для девелоперов, остро нуждается не только в классическом продвижении, но и в системной обратной связи от пользователей, чтобы улучшать продукт за счёт этой обратной связи и, одновременно, завоевывать бОльшую аудиторию. Именно этот блок задач закрывают Developer Relations.

Фокус внимания Developer Relations в данном случае направлен на:

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

Для решения всех этих задач выделились некоторые ипостаси Developer Relations: Developer Advocate, Developer Evangelist, Community Manager.

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

Рассмотрим наглядно, в чем разница между этими ролями:

Сравнение ролей: Advocate, Evangelist, Community manager Y.Murashova
  • Developer Advocate занимается коммуникацией с конечными пользователями, т.е. разработчиками, для продвижения и улучшения продукта, через выстраивание долгосрочных отношений, культивируя доверие между пользователем и компанией. Часто эта работа может быть связана с публичными выступлениями, проведением тренингов, большим количеством нетворкинга. Здесь требуется не только высокий уровень технических знаний, но и эмпатия, эмоциональный интеллект, умение поставить себя на место пользователя. Developer Advocate непосредственно влияет на разработку продукта, вносит предложения по изменениям, плотно работает с Product командой. Поэтому очень важно уметь верно интерпретировать и донести обратную связь от разработчиков-пользователей к разработчикам продукта.
  • Developer Evangelist. Часто роли адвоката и евангелиста путают или объединяют, но они не взаимозаменяемы. Евангелист - это спикер, медиатор между компанией и ее сотрудниками и внешней аудиторией. Он выступают от лица компании на конференциях, митапах, ведет блоги в тех.медиа, инструктирует разработчиков-пользователей, как лучше применять продукт, рассказывает о преимуществах, возможностях, объясняют, как продукт решает задачи и помогает девелоперам сделать свою работу.
  • Community Manager – в то время как усилия людей выше направлены на работу с комьюнити внутри и вокруг продукта, кто-то должен управлять организационными процессами. Этот человек организует и поддерживает сообщество, занимается его развитием и придает импульс для движения вперед. Здесь нужны очень хорошие организаторские способности, плюс понимание того, как функционирует сообщество, что интересно и волнует аудиторию.

Developer Relations в b2e: работа с брендом работодателя

Этот подход к Developer Relations сейчас активно формируется на рынке России и Восточной Европы, и у многих плотно ассоциируется c HR. Но всецело приписывать Developer Relations к HR все же не корректно, и вот почему.

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

Хорошо продуманные и системные Developer Relations играют огромную роль в рекрутинге. Судите сами, ведь много людей хотят присоединиться к Google или Amazon потому, что они вдохновлены брендом, технологиями и вкладом этих компаний в индустрию.

В рамках b2e подхода мы имеем дело с имиджем компании и с аудиторией не только разработчиков, но и всех других IT-профессий. Отсюда появляется новый набор факторов, с которыми предстоит работать - это критерии выбора работодателя. Согласно ежегодному исследованию Хабра и Экопси, зарплата, ДМС, обстановка офиса уже не так важны. Люди IT-профессий придают больше значения интересным задачам, технологиям, ищут возможности роста и обучения, хотят, чтобы рядом были профессионалы и работать только в такой компании, которая делает мир лучше. Поэтому появляется необходимость не только во внешних Developer Relations, но и в работе с аудиторией внутри.

DevRel в b2e от b2c в большей степени отличает именно наличие огромного пласта работы с сотрудниками компании.

Внешний DevRel в b2e занимается:

  • работой с брендом и имиджем, Tech PR
  • выстраиванием внешних коммуникаций с IT-сообществом
  • маркетингом для разработчиков и поддержкой рекрутинга

Внутренний DevRel это:

  • продвижение культуры обмена знаниями внутри компании
  • создание инфраструктуры и базы для внутренних сообществ
  • развитие экспертов

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

Y. Murashova

Культура обмена знаниями и опытом – ключевой компонент Developer Relations. Даже если компания не производит свой собственный продукт, или этот продукт не предназначен для разработчиков, внутри все равно решаются сложные технические дилеммы, и опыт решения этих дилемм может быть полезен другим людям.

Блок внутренних задач DevRel’а связан не только с коммуникациями, но и:

  • с выстраиванием инфраструктуры

  • выстраиванием процессов,

  • созданием и развитием внутренних сообществ

  • развитием сотрудников, как спикеров и авторов текстов,
  • созданием механизмов нематериального поощрения активных сотрудников и т.д.

В заключении

В этом тексте мне хотелось рассмотреть подходы к Developer Relations, их особенности и задачи. В любой зоне применения DevRel - это действительно кросс-функциональная роль. Учитывая, насколько перегрет рынок IT сегодня, компаниям жизненно необходимо выстраивать отношения с кандидатами, иначе они будут проигрывать соревнование за людей. И это рождает интересную проблематику системы оценки эффективности, создания EVP, выбора инструментов и подсчета конкретных эффектов DevRel деятельности. Поговорим об этих темах в следующих публикациях.

0
6 комментариев
Написать комментарий...
Kirill Muchow

Юля, спасибо. Хорошо структурировано для понимания каждой роли

Ответить
Развернуть ветку
Maxim Mescheryakov

Отличная статья и очень полезные материалы

Ответить
Развернуть ветку
Ekaterina Shadrina

Очень понравилось, как описаны роли)
Полезно: в закладки 👍

Ответить
Развернуть ветку
Stanislav Black

Отличная статья и доступное изложение!

Ответить
Развернуть ветку
Константин Лобанов

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

Ответить
Развернуть ветку
Yulia Murashova
Автор

очень рада, что полезно)))

Ответить
Развернуть ветку
Читать все 6 комментариев
null