Connect with us

Обучение

DevRel / Tech PR: Как раскручивают IT-бренд компании?

Техпиар, боль разработчиков и IT-евангелизм во всей красе

 

Devrel — это

DevRel (англ. Developer Relations) — дословно переводится как «отношения с разработчиками».

Это направление при которой компания развивает и продвигает IT-составляющую компании: информационные системы, разработчиков, инженеров. Является своеобразной реинкарнацией PR (Public Relations), только в центре внимания, в этом случае, находятся технические процессы, а не маркетинговые приёмы. DevRel — это открытие миру своего продукта, глазами разработчиков, это политика компании на коммуникации с внешними девелоперами, техника продвижения компании, как IT-бренда.

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

Чем занимается DevRel / TechPR менеджер?

DevRel менеджер позволяет компании посмотреть на технические особенности своего продукта и его показать его рыночные преимущества. DevRel — это технологический евангелист, который постоянно ищет новые и свежие направления, технологии, экосистемы, постоянно экспериментирует и ищет правильные подходы к работе разработке продукта, ищет новые каналы общения и партнеров. Шило в жопе — это про DevRel.

Вы — «голос» разработчиков в компании. Вы должны вести вперед IT-закулисье с программистами на борту, показать им, что они будут узнаваемыми, они будут рок-звездами.

На эту вакансию зачастую требуют опыт работы от одного года — здесь нет никаких исключений из стандартных правил рекрутинга. Опыт обычно требуют в области PR и/или ведения проектов. Могут понадобится знания специфики организации корпоративных мероприятий, основ SMM, маркетинга и рекламы, а также умение общаться с заказчиками

Список обязанностей  может состоять из самых различных задач, вплоть до создания видеоролика о проекте (рассказ об его устройстве и работе) или даже постримить в твиче. Если попробовать упорядочить таски, то конкретика следующая:

  1. Создание сообщества. Формирование и развитие блога/канала технических специалистов. Искать целевую аудиторию, которая поспособствует развитию IT-бренда.
  2. Работа с контентом. Обязательное составление контент-плана, которого нужно будет придерживаться и выполнять вовремя. Оформление и помощь разработчикам с их материалом, его редактирование перед пушем в блог. Написание постов в блоге о платформе и новых возможностях, ответы на интервью. Написание документации к техническим кейсам. Публиковация в ведущих онлайн-СМИ и социальных медиа
  3. Коллаборация с SMM. Вести и раскручивать каналы IT-направлений (Редит, Хабр, Медиум). Сюда же входит раскрутка социальных сетей (Twitter) и мессенджеров (Telegram)
  4. Публичная работа. Участие в мероприятиях, конференциях, митапах. Не только выступать самостоятельно, но и готовить спикеров для этих нужд. К тому же вся инфраструктура мероприятий тоже может лечь на твои плечи: организация регистрации, подготовка технического ландшафта, раздача мерча и т.д. Переговоры с партнерами по интеграции, зачастую очень трудные.
  5. Анализ статистики. Нужно быть знакомым с различными метриками: узнаваемость бренда, охват, ROI. Мониторинг социальных сетей
  6. Прокачка communications skills. Необходимо постоянно мотивировать всех людей вокруг, вовлекать разработчиков в технические активности компании. Обсуждение кода и проблем девелоперов, подгонять продуктовые группы.

Зачем это нужно компаниям?

Борьба за сильных разработчиков в России в последние несколько лет достаточно интенсивна. Поэтому фокусировать внимание на проблемах девелоперов стали все крупные игроки рынка, так или иначе связанных с IT. В чем ценность DevRel?Это забота о сообществах, лечение документации и роль внутреннего защитника разработчиков, получателя обратной связи о продукте и их работе. Можно показывать интенцию компании, направленность, куда она стремится, и для этого также существует много креативных способов. Но что конкретно это дает?

1. Узнаваемость бренда в мире IT. Отношения с разработчиками влияет на то, как позиционирует себя компания. Открытость и коммуникация внутри рынка создает отличную узнаваемость в IT-тусовке — «Эти парни в деле», «Эти ребята знают, что делать». А это неплохой, хоть и не такой явный, показатель для потенциальных инвесторов и партнеров.

2. Профессиональный рост инженерной команды. Привлекая разработчиков, DevRel-менеджер помогает им раскрыть себя с другой стороны, писать примеры кода, проверять концепции, чтобы продемонстрировать, какие сумасшедшие идеи разработчики могут создать с помощью вашего API и ваших инструментов. Эта работа позволяет генерировать новые идеи, новые методы работы. А неподдельный интерес со стороны (какими задачами занимаетесь? Какой используете стек?) сильно мотивирует разработчиков на дальнейшую работу с сообществом. В конце концов это просто приносит удовольствие, когда твою работу могут оценить по достоинству коллеги из других городов, стран, компаний.

2. Положительная репутация в сообществе. Работа с разработчиками сопровождается постоянным обменом сообщениями, поиском нужных примеров и переводом статей и публикацией обширной документации. Получается принцип win-win: разработчики используют ваши веб-API и SDK, а работа DevRel помогает им найти нужную информацию и создает благоприятный фон в сообществе.

3. Хантинг. Вместо того, чтобы просиживать сутками на LinkedIn, HR теперь могут трудоустраивать разработчиков, которые уже внесли какую-либо лепту в рамках сообщества — отлавливать таких кадров гораздо проще. Дружественное отношение к бренду и лояльность с большой долей вероятности уже будут заложены, благодаря сообществу.

4. Успешный мировой опыт. Первопроходцами в области отношений с разработчиками являются ведущие IT-гиганты рынка — Microsoft и Apple. Для компании Билла Гейтса это стало отличной возможностью создавать приложения для Windows руками сторонних разработчиках. На текущий момент практики DevRel используют многие крупные мировые компании AWS, Google, IBM, Facebook, Unity, Salesforce, Twitter, SendGrid, Twilio

 

Это для гуманитариев или технарей?

Амбассадором IT-бренда может стать любой — направленность образования здесь играет далеко не важную роль. Конечно, плюсом будет , но не стоит забывать, насколько в данной профессии важны софт-скиллы, которые как раз больше развиты у людей с образованием в области общественных наук. Например, в компании Badoo — DevRel — Дарья Богомолова. Девушка, которая не скрывает своего гуманитарного бэкграунда

Как найти работу? DevRel вакансии

У направления DevRel, как такового, может быть много смежных профессией, но суть будет примерно одной и той же:

  • Евангелист-разработчик
  • IT-евангелист
  • Digital DevRel
  • DevRel Specialist
  • Адвокат разработчика
  • Менеджер по связям с разработчиками
  • Менеджер сообщества разработчиков
  • Инженер по решениям
  • Технический маркетолог

Самыми ходовыми местами, где ищут подобных сотрудников являются вакансии на vc.ru, либо на площадке хабра — МойКруг. Так же попадаются вакансии на HeadHuhter.

Кто такой Developer Advocat?

Адвокат разработчиков — это инженер (программист), который по воле случая или намеренно перешел от роли программирования к роли защитника интересов разработчиков. Защитники разработчиков или, как их еще называют, «евангелисты разработчиков» — это технический специалист умеющий во внешнюю коммуникацию, способный привнести в разговор, презентацию или встречу четкие технические детали. Способность устанавливать человеческие связи — безусловно, самый важный аспект этой работы, но «Адвокат» должен быть достаточно технически подкован, чтобы участвовать в разговорах. Особенно хорошо в этой роли смотрятся бывшие учителя, имеющие реальный опыт преподавания — здесь он реально может пригодиться.

 

Как строить отношения с разработчиками?

Из зарубежного опыта мы можем выделить 4 группы, четыре столпа, на которых строится DevRel в компаниях: пропаганда, сообщество, продукт, обучение и поддержка. В практической плоскости, для достижения максимального результата должны учитываться все четыре.

Пропаганда

Пропаганда подразумевает собой аутрич-работу, как наиболее заметную частью отношений с разработчиками, и в целом она бывает двух видов: онлайн и лично. Вообще, Outreach — это маркетинговый термин, означающий процесс организации отношений с людьми, работа, выходящая за пределы официальной деятельности организаций, в нашем случае — налаживание контактов между разработчиками и сообществом. Благодаря этой работе люди узнают о вашем продукте, но также помогают им понять его, преодолеть свои первоначальные возражения и сделать все возможное для его использования. В этом поможет высококачественная исследовательская документация, в которой описывается опыт ваших разработчиков.

Сообщество

Создание сообщества рождает вокруг него инфраструктуру, которая позволит разработчикам добиться успеха с вашим продуктом. Сообщество разработчиков — это процесс распознавания людей, которые занимаются вашим продуктом, и помогает им усилить вашу стратегию, а также достичь собственных целей. Если сообщество будет активно и нацелено на разработчиков (DevRel же), то эти самые девелоперы будут использовать ваш API, ваши инструменты, ваши сервисы — это ключевой момент программы связи с разработчиками. Тут есть тонкий нюанс в том, что все эти, сплотившиеся вокруг продукта, люди перейдут с этапа использования продукта на этап его разработки (доработки). А дополнительная поддержка и какие-то действия в эту сторону помогут разработчикам почувствовать себя комфортно при выборе продукта

Продукт

Команда разработчиков должна принимать непосредственное участи в доставке продукта для этих же самых разработчиков. Так как DevRel — это «голос девелопера» в компании, то вы должны представлять их интересы в обсуждениях продукта и гарантировать, что потребности разработчика будут услышаны. DevRel — это не только про внешние коммуникации, но и внутренние.

Обучение и поддержка

DevRel-менеджер должен быть ответственным не только за поддержку разработчиков, но и за их обучение. При чем это должно быть не только в рамках официальных каналах компании, не только с вашей командой. Необходимо предлагать поддержку разработчикам, которые еще не являются клиентами, и предоставлять учебные материалы, которые ваши авторы не будут освещать. Банально — отвечать на StackOverflow. Обучение и поддержка необходимы для того, чтобы разработчики могли продуктивно работать на общей платформе и, таким образом, они играют важную роль в продвижении разработчиков вниз по воронке.

Ошибки в Devrel: Как НЕ надо делать сообщество?

Как и в любой другой области, в DevRel часто совершаются ошибки. Направление стало набирать популярность в России относительно недавно и сильных специалистов на рынке не хватает. Попробуем отсечь сразу несколько банальных мыслей и приёмов, которые могут встретиться в DevRel. В особенности это касается именно в социальном направлении работы, которая включает в себя сбор и поддержку больших групп людей, управление сообществом — это не такая легкая работа, как может показаться на первый взгляд

Ошибка №1. Один канал для сообщества

Канал в телеграмме — это очень круто и современно, но использование только основного канала связи не гарантирует полный охват вашей потенциальной аудитории. Сообщество необходимо собирать в разных местах — Twitter или Reddit

Ошибка №2. Один старый разработчик лучше новых двух ботов

Крупное сообщество — это действительно хорошо. Но добавление в чат или на канал случайных людей — это плохая практика и говорящие цифры «Нас уже 100 000» не имеют никакого толку, если большая часть людей — это далекие от разработки и IT в целом участники. Смотреть на конкурентов и гнаться за их цифрами — тоже неоднозначная затея. Пусть лучше в вашем сообществе будет всего 500 участников и оно органично растет — тем лучше для сплоченности участников.

Ошибка № 3: Участие только разработчиков

Как ни странно это звучит, но такой нюанс, как привлечение . Очень круто, если SEO или любая другая команда проекта (фронтенд, бэкэнд, маркетинг, дизайн — любая сфера деятельности) смогла бы принимать периодическое участие в обсуждении и могли уделить некоторое время взаимодействию с сообществом, что сможет укрепить связь и поспособствует более качественной коммуникации внутри сообщества.

 

Рабочие нюансы

Как проводить продуктивные встречи? Ваш идеальный митап

Ключевой обязанностью DevRel-менеджера являются митапы, встречи с разработчиками с разработчиками и инженерами. Эти встречи не пустая формальность. Если вы сопровождаете какой-либо проект, то необходимо, как минимум, несколько раз встретиться с клиентами, продакт оунерами, программистами. Такая же судьба уготовлена вам, если вы ведете документацию проекта. Но почему, зачастую, эти встречи являются не чем иным, как этими самыми формальностями?

У вас или у того, кто собирает встречу должна быть цель

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

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

Желательно, чтобы был человек, который делал заметки. Необходимо записывать решения и действия, который были согласованы между участниками. По завершению копию документа можно раздать всем собравшимся для того, чтобы они позже обновили свою память.

Встреча 1 на 1 более продуктивна

Есть мнение, что диалог более полезен в плане продуктивности, так как некоторые люди могут быть довольно замкнутыми и не разговаривать во время встречи, даже если они могут внести ценную лепту в эту беседу.

Все документы, относящиеся по теме, лучше отправить всем заранее, а не представлять по время встречи — будет время их обдумать. Для обмена документацией и презентациями можно использовать slideshare.net

При планировании важен тайминг. Избегайте встреч до и после обеда — либо их нужно проводить рано утром, либо сильно после — еда, которую вы планируете съесть или которую только что употребили будет отвлекать или расслаблять.

 

Как правильно продвигать разработчиков приложений?

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

  • Создаём приложения для Айфона, Айпада и Андроида: игры, витрины, карты, системы мобильных продаж, ЦРМ и инструменты для внутреннего пользования.
  • Наша специальность — готовые продуктовые системы, которые не требуют вмешательства со стороны. Чтобы создавать такие системы, мы самостоятельно анализируем бизнес-процессы, предлагаем гипотезы, создаём прототипы и строим инфраструктуру. Предпочитаем проекты, в которых самостоятельно контролируем технологическую часть.
  • Мы создавали приложения для федеральных банков, мобильных операторов и торговых сетей. Умеем работать с корпорациями.
  • Мы фанаты разработки: не выпускаем продукт, пока он не станет пуленепробиваемым и быстрым. Чтобы не жертвовать качеством приложений, мы применяем метод гибкой функциональности.
  • Нам важно, чтобы наши приложения не были мертворожденными. Мы с радостью сделаем систему контроля качества на производстве, но вряд ли возьмёмся за имиджевое приложение «О компании». Чтобы сделать жизнеспособный продукт, мы слушаем пожелания клиента, проводим собеседования с будущими пользователями, проводим обучение и контролируем выгрузку приложения на устройства. Если нужно, мы обучаем сотрудников новому приложению и дорабатываем его после запуска.
  • Мы верим, что приложения для бизнеса ещё не показали свой потенциал. Если вы не знаете, чем мобильное приложение поможет вашей компании, напишите нам, будем рады предложить.

Как правильно продвигать само приложение?

Так как DevRel — это многогранная личность, то немного маркетинговых скиллов может пригодится в работе. Например, у вас есть продукт — мобильное приложение. Как правильно размещать его в магазинах AppStore или Google Play?

Рекомендуется делать больше скриншотов, сделать видеоролик о работе приложения — это будет эффективнее и доходчивее. В пример можно привести тот же самый AppStore. Как правило там важней скриншоты, а не текст. Описание сложно воспроизвести в голове, так как вы пишите о том, как вы видите продукт, а не так как видят его пользователи.

Нужно ли знание SEO?

Как такового SEO менеджеру DevRel знать не нужно — это не совсем его стезя, но будет полезно изучить некоторые понятия и инструменты, которые используются в этой сфере. Например:

1. Аутрич — это размещение вашей статьи со ссылкой на нужный вам проект на сайтах других авторов при их полном согласии и открытости к этому принято называть размещением гостевых постов.

2. Сабмиты (submits) — это размещение информации о вашем сайте со ссылкой на него на различных площадках, которые позволяют размещать пользовательскую информации (UGC)

3. Упоминание = ссылка (Link Reclamation) Метод с высокой отдачей на приложенные усилия, при условии, что у вас есть уже определенный информационный фон и о вашем бренде говорят. Что имеется ввиду? Отслеживаем упоминание бренда в сети. Есть как ручные способы, так и автоматический софт и сервисы. Связываемся с редакцией или автором материала. Просим, чтобы вместо упоминания — поставили ссылку. Profit!

Что посмотреть по теме?

В русскоязычном сегменте YouTube есть прекрасный канал на эту тему — DevRel Channel

Почему DevRel любят Хабр?

Многие задаются вопросом, почему не создать отдельный сайт, на котором повесить свой корпоративный блог или использовать хотя бы поддомен основного сайта? Ответ простой — Блог на Хабре дает резкий старт, вы сразу получаете релевантную аудиторию, ведь на нём уже давно живет целый оплот разработчиков. За многое время проект собрал вокруг себя сообщество программистов, которые будут читать про ваш продукт и оставлять комментарии (сообщество в Хабре не особо токсичное). В то время как на stand-alone блог нужно привлекать трафик, давать обширную рекламу и только после этого формировать сообщество. Это тот самый случай, когда изобретать велосипед не стоит

Есть ли пример хорошей айдентики в IT?

Примеры качественной айдентики для отечественных IT-проектов можно посмотреть в портфолио брендингового агенства Repina. В их блоге можно почитать много полезного про продуктовый дизайн и корпоративный брендинг в целом.

Click to comment

Leave a Reply

Ваш e-mail не будет опубликован.

Лучшие сервисы стриминга музыки в 2019 году

Сервисы

Wink Ростелеком: Samsung LG, Sony, Phillips, Android TV

Ростелеком

LG WEB OS: приложения, обновления, настройка, проблемы со звуком

Гаджеты

Ноутбуки Asus не видят жесткий диск. Автоматический вход в BIOS при старте

Гаджеты

.

Digital2.ru - тренды, IT, разработка, цифровая экономика

Connect
Подпишись на нас