Какие задачи решают Developer Relations: роли, подходы, результаты
Сейчас в мире IT происходят не только технологические прорывы, но и формируется новое направление, связанное с коммуникациями - Developer Relations. Чем занимается DevRel? Зачем это нужно и какие задачи решает? В этой статье вы найдете ответы на эти вопросы, а также систематизированную картину на основании западного опыта и моей практики реализации DevRel проектов как в СНГ, так и на глобальном рынке.
Чем занимаются Developer Relations?
В широком смысле, это направление отвечает за выстраивание отношений между компанией и IT-сообществом. Изначально DevRel'ы занимались продвижением продуктов для разработчиков среди разработчиков. Но немного позже DevRel как функция стал применяться бизнесом для работы с брендом компании как работодателя.
Почему Developer Relations оформились в отдельное направление? Потому что настройка коммуникаций с разработчиками и IT миром в целом - это большая проблема для бизнеса. Сегодня DevRel решает много бизнес-задач через коммуникацию с сообществами и создание новых вокруг своих продуктов и своего бренда в целом.
Немного примеров:
- IT-компании ведут блоги, где разработчики пишут для разработчиков, например Slack Platform blog, Google developers на medium.
- Такие гиганты, как Google или Amazon, создают вокруг своих продуктов и технологий глобальные сообщества, например Google cloud AI developer community или AWS Community.
- Вне зависимости от размера, бизнес все активнее участвует в 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 ему ставить, как оценивать эффективность его работы.
Рассмотрим наглядно, в чем разница между этими ролями:
- 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 внутри, не получится качественных внешних коммуникаций.
Культура обмена знаниями и опытом – ключевой компонент Developer Relations. Даже если компания не производит свой собственный продукт, или этот продукт не предназначен для разработчиков, внутри все равно решаются сложные технические дилеммы, и опыт решения этих дилемм может быть полезен другим людям.
Блок внутренних задач DevRel’а связан не только с коммуникациями, но и:
с выстраиванием инфраструктуры
выстраиванием процессов,
созданием и развитием внутренних сообществ
- развитием сотрудников, как спикеров и авторов текстов,
- созданием механизмов нематериального поощрения активных сотрудников и т.д.
В заключении
В этом тексте мне хотелось рассмотреть подходы к Developer Relations, их особенности и задачи. В любой зоне применения DevRel - это действительно кросс-функциональная роль. Учитывая, насколько перегрет рынок IT сегодня, компаниям жизненно необходимо выстраивать отношения с кандидатами, иначе они будут проигрывать соревнование за людей. И это рождает интересную проблематику системы оценки эффективности, создания EVP, выбора инструментов и подсчета конкретных эффектов DevRel деятельности. Поговорим об этих темах в следующих публикациях.