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

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

В широком смысле, это направление отвечает за выстраивание отношений между компанией и 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.

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

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

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

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

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

• Developer Advocate занимается коммуникацией с конечными пользователями, т.е. разработчиками, для продвижения и улучшения продукта, через выстраивание долгосрочных отношений, культивируя доверие между пользователем и компанией. Часто эта работа может быть связана с публичными выступлениями, проведением тренингов, большим количеством нетворкинга. Здесь требуется не только высокий уровень технических знаний, но и эмпатия, эмоциональный интеллект, умение поставить себя на место пользователя. Developer Advocate непосредственно влияет на разработку продукта, вносит предложения по изменениям, плотно работает с Product командой. Поэтому очень важно уметь верно интерпретировать и донести обратную связь от разработчиков-пользователей к разработчикам продукта.

• Developer Evangelist. Часто роли адвоката и евангелиста путают или объединяют, но они не взаимозаменяемы. Евангелист - это спикер, медиатор между компанией и ее сотрудниками и внешней аудиторией. Он выступают от лица компании на конференциях, митапах, ведет блоги в тех.медиа, инструктирует разработчиков-пользователей, как лучше применять продукт, рассказывает о преимуществах, возможностях, объясняют, как продукт решает задачи и помогает девелоперам сделать свою работу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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