Путь к успеху в сфере DevRel: информирование, помощь, вовлечение

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Только за последний год у меня было несколько десятков разговоров с людьми, которых интересовало, как разделить обязанности в команде Developer Relations (эта команда выстраивает отношения с разработчиками). Неважно, какая перед вами стоит задача: понять, какого именно специалиста по Developer Relations нанять на работу (кого-то с опытом разработчика? человека, который управлял форумом сообщества разработчиков? или кандидата, который успешно справляется с креативными задачами — например, как сделать так, чтобы люди узнали о вашем новом продукте?), или решить, каким образом распределить задачи между членами вашей команды (как раз этим я сейчас занимаюсь в Camunda!). В любом случае важно иметь чёткую систему, позволяющую разделять обязанности и делать в нашей работе нужные акценты.

В предыдущей публикации я писала о том, что краеугольный камень нашей работы как специалистов по Developer Relations — это помощь нашей компании в её деятельности, направленной на расширение возможностей ИТ-сообщества. Это базовое понятие затем можно разделить на несколько категорий: информирование, помощь и вовлечение.

Давайте начнём с определений. Что я имею в виду под расширением возможностей?

Действия, которые вселяют в человека уверенность или придают ему сил для совершения каких-либо поступков.

Путь к расширению возможностей

Чтобы ИТ-специалист успешно работал с вашим продуктом, он должен быть уверен в том, что он сможет им пользоваться или как минимум найти ресурсы, которые ему в этом помогут.

Чтобы такая уверенность возникла, прежде всего, этот человек должен быть проинформирован о том, что ваш продукт существует и может удовлетворить его потребности.

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

Наконец, после того как участник сообщества внедрил ваш продукт, наступает время вовлечь его в деятельность сообщества.

Миссия команды DevRel в Camunda звучит так: «дать разработчикам возможность достичь большего успеха, познакомив их с нашими решениями, обеспечив отличный опыт их использования и способствуя развитию культуры сотрудничества».

Мы помогаем разработчикам и другим ИТ-специалистам добиться успеха, информируя их о наших продуктах и проектах, предоставляя им доступ к нашему контенту и выдающемуся опыту работы, а также вовлекая их в совместную работу как с нами, так и с другими членами сообщества Camunda.

Три функции команды developer relations

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

Примечание: это обобщенная схема, основанная на том диапазоне обязанностей, которые выполняет моя команда. Я понимаю, что некоторые из этих обязанностей могут находиться за рамками этих конкретных ролей, а также относиться сразу к нескольким функциям команды Developer Relations. Есть также элементы, которые относятся сразу ко всем трём функциям (см. внутренний треугольник). Считаете, что я что-то упустила или какие-то элементы расположены не там, где нужно? Оставьте комментарий ниже!

Отдельное спасибо Даниэль Андрист за создание этой наглядной схемы.

Вообще говоря, наши Developer Advocates несут ответственность, чтобы наше сообщество было проинформировано о решениях, которые мы предлагаем. Для этого они создают контент (публикации в блогах, выступления на мероприятиях, прямые трансляции и т. д.), разрабатывают типовые приложения и интеграции, а также налаживают связи с широким кругом представителей технологической отрасли. Кроме того, они информируют наших менеджеров по продуктам, руководителей разработки и других заинтересованных лиц на всех уровнях компании о значимой и полезной обратной связи, полученной от нашего сообщества пользователей, а также более широкого круга технических специалистов. Такая обратная связь по продуктам вместе с более общей информацией о происходящем в технологической отрасли (какие наблюдаются тенденции, как другие сообщества разработчиков ПО с открытым исходным кодом решают определённые проблемы, на какую новую систему или расширение нам стоит обратить внимание?) невероятно ценна и играет важную роль в том, как мы помогаем членам нашего сообщества.

Наша команда по созданию опыта для разработчиков отвечает за помощь разработчикам. Эти люди заканчивают ту работу, которая начинается с вдохновляющей речи Developer Advocate на технической конференции: от стандартизации, обеспечения доступности и удобочитаемости нашей документации к формированию первого опыта использования нашего продукта для разработчиков и до работы с людьми, которые приняли участие в разработке. Developer Advocate рассказывает людям о существовании наших продуктов. Команда по созданию опыта для разработчиков вселяет в людей уверенность в том, что они смогут легко решить свои проблемы, если воспользуются нашими замечательными руководствами и ресурсами. Кроме того, эти люди уверяют разработчиков в том, что, если им удастся найти область, в улучшении которой они хотели бы поучаствовать, мы не только к этому готовы, но с радостью окажем им необходимую поддержку и содействие. Вот где начинается дорога к вовлечению. Когда мы делаем акцент на опыте вовлечённого члена сообщества, мы начинаем задавать себе вопросы о том, как расширить наше с ним взаимодействие, как сохранить его вовлечённость и помочь ему сделать ещё несколько шагов на пути к тому, чтобы стать чемпионом Camunda.

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

Не забывайте о своём внутреннем сообществе

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

Внутри компании по отношению к нашим коллегам: 

За пределами нашей компании по отношению к нашему сообществу:

Примечание для тех из вас, кто выполняет все эти функции в одиночку или вдвоём с коллегой. Я понимаю, что нам в Camunda крупно повезло: у нас относительно большая команда, а руководство компании осознаёт ценность нашей работы. Если вы отвечаете за информирование, помощь и вовлечение и пытаетесь найти баланс между этими функциями, сочувствую вам! Советую вам прочитать статью First, Understand the Company Goals (Для начала разберитесь с целями компании), она поможет вам расставить приоритеты и найти способ донести до заинтересованных сторон ценность вашей работы. 

Затем найдите в вашей компании союзников. Людей, заинтересованных в информировании, вы, скорее всего, встретите в отделе маркетинга. Специалистов по поддержке стоит искать в подразделениях, занимающихся продуктами и разработкой. И наконец, заведите друзей в службах поддержки и работы с клиентами — они помогут устранить пробелы в вовлечённости. Грамотно расставив приоритеты и сотрудничая с другими командами для достижения поставленных целей, вы добьётесь результатов во всех трёх областях.

Хотите узнать больше о том, как охватить все три функции, если у вас маленькая команда? Отпишитесь в комментариях ниже, и я постараюсь в будущем написать статью на эту тему.

P.S. От переводчика

Тема DevRel постоянно подогревается в русскоязычном сегменте интернета. Ко мне, как к Developer Advocate в Yandex Cloud, приходят коллеги и задают массу вопросов. На какие-то у меня есть ответы, а на какие-то нет. Решил перевести ряд полезных публикаций, чтобы в любой момент можно было их вытаскивать как козырные тузы из рукавов. И начать решил с заметки от бесподобной Мэри Тенгвал.

Источник: https://habr.com/ru/post/596913/


Интересные статьи

Интересные статьи

Один из самых распространённых вопросов от подписчиков — как получить путь к команде Linux, которую только что установили в систему с помощью пакетного менеджера, например, команды apt или DNF. Мног...
Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматиза...
7 сентября мы поговорили в прямом эфире с Алексеем Левановым, исполнительным директором в Сбербанке. Леша пришел в Сбербанк в 2014 году на позицию Junior-разработчика. Сейчас он исп...
Деньги любят счет!Привет жители планеты! Моё имя Антон и я уже 3 года веду личную бухгалтерию. Выводов пока не очень много, но они есть и достаточно интересные. Первые 2 года я исполь...
У тебя есть всё — высокая должность, зарплата в несколько сотен тысяч рублей, надёжность и стабильность государственной корпорации, ранговые корпоративные игры. У тебя малиновые штаны — и подчинё...