Гик, маркетолог, адвокат, евангелист, мать ̶д̶р̶а̶к̶о̶н̶о̶в̶ разработчиков — разбираемся в специалистах DevRel
Developer Advocate облачной платформы Yandex Cloud Антон Черноусов рассказывает, какими бывают специалисты DevRel и чем занимаются, как начать карьеру в этой сфере и балансировать между интересами компании и комьюнити.
Что такое Developer Relations
В российской IT-сфере в последнее время всё чаще упоминаются «Developer Relations». При этом, кажется, компании, сообщества, отдельные IT-специалисты вкладывают в это понятие разные значения. Крупные IT-корпорации и финтех-компании размещают вакансии с указанием должностей DevRel, Developer relations Manager, «Менеджер по работе с IT-сообществом» с самыми разнообразными списками требуемых навыков и исполняемых обязанностей. Попробуем разобраться, кто все эти специалисты и каким компаниям они нужны. Developer relations — не профессия, не должность и не бессмысленная структурная единица компании. Это целое направление деятельности внутри IT-индустрии. Мэтью Броберг, мейнтейнер свободного ПО, подкастер, сооснователь сообществ K8sContributors и DevRel Collective характеризует эту отрасль так: «DevRel теоретически представляет собой пересечение трех областей знаний: инженерии, маркетинга и управления сообществом».
Кому нужна команда DevRel
Распространенное обывательское представление о DevRel, выполняющем функцию найма сотрудников, это локальное искажение. Необходимость в Developer Relations чаще всего появляется в компаниях, которые сосредоточены на создании продуктов и услуг «от разработчиков для разработчиков». В этом случае уже недостаточно просто предоставить готовую «коробку» с ПО, провести маркетинговую или PR-кампанию. Необходимо сформировать собственное комьюнити IT-специалистов или завоевать внимание существующих сообществ, получать и работать с обратной связью, доносить важность вашей технологии и продукта для индустрии, рассказывать о функциональности и показывать примеры использования.
Команда Developer Relations работает как с конечными пользователями, покупателями технологии и с сообществом целиком, так и с руководством и инженерами компании. Мэри Тенгвал, основатель Persea Consulting и автор книги «The Business Value of Developer Relations», характеризует деятельность специалистов DevRel так: «В комьюнити я представляю компанию, в компании я представляю комьюнити, и я всегда должна помнить об интересах и тех, и других».
Главная цель команды Developer Relations в том, чтобы обеспечить успех технологических продуктов компании у аудитории разработчиков и донести их потребности до остальной части компании. При этом косвенно решаются задачи повышения и закрепления узнаваемости бренда в целевой среде и привлечения специалистов как в комьюнити продукта, так и найма их в компанию. Главный фокус команды Developer Relations — обеспечить успешную работу IT-специалистов внутри комьюнити и постоянно поддерживать обратную связь между ним и командами продукта и разработки.
Например, я веду сообщество Yandex Serverless Ecosystem для поддержки и продвижения продуктов группы сервисов Serverless, разрабатываемых Yandex Cloud. Одна из важнейших задач — формирование культуры общения в сообществе между разработчиками сервисов и теми, кто эти сервисы потребляет. Наверное, многие сталкивались с токсичным поведением некоторых людей в чатах, особенно, когда ситуация накаляется. Задание некоторой рамки общения позволяет создать конструктивный контекст и безопасную, дружелюбную атмосферу. Происходит выстраивание быстрой обратной связи между потребителями сервисов и членами команды: участники комьюнити делятся опытом использования продуктов, а разработчики сервисов со своей стороны помогают решать ряд мелких проблем пользуясь знанием того, как система работает изнутри. Это запускает позитивную обратную связь и вновь прибывшие участники комьюнити получают поддержку уже от старожилов чата.
Роли в Developer Relations
Управлением командой DevRel занимается Developer Relations Manager. На эту роль очень сложно найти кандидата. С одной стороны, он должен обладать большим опытом работы с техническими продуктами, владеть профессиональным сленгом и разбираться в технологиях компании, с другой, — обладать высоким уровнем «мягких навыков», иметь опыт планирования и управления командой и уметь рассмотреть лес из-за деревьев, не зацикливаясь исключительно на технических деталях. Его главный фокус, как и любого другого руководителя — формирование целей DevRel, выстраивание процессов, налаживание связей с другими подразделениями и защита своей команды.
Одна из важных ролей в команде— Developer Advocate. Задачи Developer Аdvocate варьируются в зависимости от размера команды DevRel и назначения продуктов компании, но неизменной остается основная роль — технологического мостика между комьюнити и компанией.
Developer advocate в продуктовой компании является, по сути, двусторонним проводником информации. Этот человек помогает сообществу, пользователям и клиентам продукта решать инженерные проблемы с помощью продукта, и помогает компании лучше понять нужды, запросы, и проблемы, с которыми сталкиваются пользователи при использовании, или во время принятия решения об использовании продукта.
В реальной ситуации Developer Advocate обычно «человек-оркестр». Я и мои коллеги по цеху заняты созданием и продвижением дополнительного контента, связанного с технологическими продуктами: дополнительной документацией, примерами и how-to, практикумами-воркшопами. Любой developer advocate существенно вкладывается в публичные активности: выступления на конференциях, ведение собственных подкастов и участие в различных мероприятиях в качестве гостя-эксперта.
Все это направлено вовне компании. Но одна из важнейших обязанностей developer advocate связана с получением обратной связи от рынка, текущих или потенциальных клиентов. Чаще всего такая обратная связь выражена в создании новых идей и предложений. Мы проверяем эти запросы на адекватность и способность улучшить продукт, после чего доносим их значимость до команд разработки. За кадром остается много мелкой технической работы. В конечном итоге компания от работы developer advocate получает более широкую известность продуктов у технической аудитории и более простой онбординг клиентов.
Основной фокус работы developer advocate это создание технического контента для инженеров и работа с фидбеком IT-комьюнити, и почти всегда на эту роль приходят бывшие разработчики, с наработанными «мягкими навыками» или специалисты из технического пресейла. Но случается, что на эту позицию приходят специалисты PR, маркетинга, продаж или HR, имеющие бэкграунд в разработке или серьезно прокачавшие технические навыки.
В продуктовой компании мы нанимаем Developer Advocate, чтобы сделать продукт лучше. И мы должны удостовериться, что дали ему все необходимые инструменты, чтобы с одной стороны влиять на разработку, а с другой — обеспечить устойчивую связь с комьюнити.
Следующий представитель DevRel команды, с которым вы чаще всего сталкивались — Community Builder. Именно эту позицию в русскоязычном IT-секторе принято называть DevRel и это порождает много неразберихи, так как DevRel это направление работы и можно сказать отрасль, а не конкретный человек.
Community Builder сопровождает процессы коммуникации, находит и знакомит между собой людей, организует митапы и выступления на них. Основной фокус работы Community Builder в работе среди существующих сообществ разработчиков. Он «держит руку на пульсе» процессов, происходящих в сообществе, знает ярких представителей как в комьюнити, так и в компании и организует их участие в митапах и других активностях.
Community Builder тоже пригодятся технические навыки, но эта роль требует прежде всего «мягких навыков» и понимания маркетинга и развития бизнеса.
То, что действительно объединяет Community Builder и Developer Advocate — сбор информации внутри сообщества об интересных кейсах использования продуктов, возникающих проблемах или возможностях совместных проектов.
При масштабировании сообщества и росте команды DevRel возникает необходимость в выделении еще одной, отдельной роли — Developer Experience Manager. Как понятно из наименования этот специалист работает с пользовательским опытом разработчиков. Функциональность продукта и DX это фундамент, без которого бессмысленны и гениальный маркетинг, и усилия по созданию комьюнити. Developer Experience Manager контролирует все процессы, касающиеся опыта разработчиков: адаптацию новых разработчиков, дизайн SDK/API и документацию к ним, разнообразные инструкции, даже UX или дизайн сайта.
Еще одна, пожалуй самая известная, роль в DevRel это Developer/Technical Evangelist или Ambassador. На первый взгляд технический евангелист очень похож на Developer Advocate, но на самом деле евангелист гораздо больше занимается продажами продукта, чем взаимодействием с комьюнити по техническим вопросам. Главная цель Technical Evangelist формировать повестку по новым продуктовым направлениям и чистая пропаганда. Чаще всего Technical Evangelist нужны для еще новых направлений в индустрии, когда необходимо объяснить, какие проблемы решает продукт, и кому он может быть полезен. Technical Evangelist сфокусированы на выступлениях среди бизнес-аудитории, конференциях и встречах CTO и CEO, формируют и доносят до аудитории важность конкретной технологии и продукта для индустрии в целом.
Кроме основных ролей в среде DevRel выделяют множество специальностей, которые нужны ситуативно. Например, Technical Engagement Manager поможет компании тогда, когда требуется вовлекать техническую аудиторию в общение в онлайне.
Востребованы ли специалисты DevRel
Это направление напрямую влияет на улучшение технологического продукта и его проникновение в комьюнити разработчиков. Поэтому для компаний, разрабатывающих технологический продукт, DevRel — одна из важнейших областей компетенций, и специалисты в этой области очень востребованы на рынке.
Отследить предложения в области DevRel на российском рынке труда достаточно сложно из-за путаницы, о которой я рассказывал выше. Тем не менее, вакансии можно выловить как на сайтах самих технологических компаний, так и на джоб-бордах. Среди работодателей есть и финансовые, логистические, телеком и IT-компании: Газпромбанк, МТС, Росбанк, QIWI, inDriver, Лаборатория Касперского. Спойлер: Yandex Cloud, конечно, тоже в этом списке.
По моему опыту, стать, например, Developer Advocate может любой технический специалист, готовый к публичности и плотному взаимодействию с технической аудиторией. И искать таких людей нужно прежде всего среди собственных сотрудников, если команда DevRel уже сформирована. Хороший опыт разработки и использования технологических продуктов — прекрасный базис для этой работы. Проще всего переход в эту профессию дается людям, долгие годы участвующим в создании подкастов или написании статей для гиков. А опыт участия в конференциях в качестве докладчика будет приятным бонусом.
Как мне кажется, переход на позиции Community Builder открыт людям имеющим опыт в HR-области и технически подкованным SMM-специалистам Хотя возможно потребуется дополнительное погружение в продукт и быстрых результатов от них ждать не желательно. В любом случае подбор людей в команду Developer Relations — это всегда штучный набор узкоспециализированных профессионалов.
Подписывайтесь на блог Yandex Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.
Другие истории, которые активно читают наши подписчики:
Списки, списки, списки