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

и комплекс активностей, направленных на развитие ИТ-комьюнити. А еще это технический специалист и..." прочее-прочее. Не знаю кто как, а я занимаюсь по сути маркетинговыми коммуникациями. Мои заказчики и целевая аудитория - технари. А цели могут быть совершенно разные: продвижение технологий и API, создание и поддержка комьюнити, развитие технологической экосистемы в регионе (например, под новый офис), employer brand, внутреннее обучение и мотивация разработчиков и т.д.
Я как никто другой знаю, что разработчики ненавидят, когда их «маркетят», потому что зрят в корень. Они про контент и качество, а не про форму. И инструменты работы с этой аудиторией очень ограничены. Тем не менее в работе лежат маркетинговые принципы сегментации, позиционирования, продвижения и т.п.

Developers Hate Marketing - 👍онлайн книга про построение developer relations для API и его продвижения. Это прекрасное пособие, которое позволяет взглянуть на коммуникации с разработчиками для любых целей. Рассматриваются и мотивация, и каналы, и форматы.
https://pages.apigee.com/global-ebook-developers-hate-marketing-confirmation-ty.html

“Немного о принципах коммуникации с аудиторией разработчиков, которые я всегда держу в уме.” by Natalia Makarova https://link.medium.com/FeyKsu5m2V

Кейс из практики построения региональной технологической экосистемы для офиса разработки. “Формат мероприятия под задачу.” by Natalia Makarova https://link.medium.com/eFrqPo6zaW

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

Anna Graham Keller. Доклад про внутреннюю армию https://devrel.net/dev-rel/building-internal-army
Зацепила мысль:
"Devrel-у или техническому адвокату нужен тоже адвокат, защитник, представитель интересов и транслятор" .
Другими словами, как я интерпретирую для себя, нужны те, кто будет помогать защищать и поддерживать идеи, разделять интересы, верить, что это нужно. Желательно чтобы это были и топы, и обычные  разработчики.

Масштабируемость!
Вот что не даёт мне покоя после просмотра этого доклада. Как разрабатывать проекты и программы с учётом этой характеристики? И возможно ли это вообще, учитывая специфику тех задач, с которыми мы работаем?
Мы тратим много сил и ресурсов, а ведь наверняка можно иначе и эффективнее. Правда, поменять нужно не только свою работу, но и видение и подходы компании в целом.
https://youtu.be/y2GKAjMpO5s

В своих проектах я использую такой инструмент, как привоз "звёзд" - гуру или даже просто известных специалистов в своей области. Такой приём я могла бы посоветовать не только крупным компаниям, но даже совсем небольшим, если есть бюджет.
Это даёт возможность заявить, что компания работает в определённой сфере, вкладывается в индустрию, создаёт условия не только своим, но и внешним специалистам встречаться и профессионально общаться с мировыми гуру в своей области.
Подробнее о возможностях, примерах и особенностях работы пишу здесь “Встречи со звёздами” by Natalia Makarova https://link.medium.com/beGC9HKiFW

​​КАК ОРГАНИЗОВАТЬ СООБЩЕСТВО
Очень хороший курс о комьюнити органайзинге, который помог мне структурировать знания и ответил на открытые вопросы.
Для меня лично было полезно:
- структурировать знания о построении сообщества и разработке стратегии;
- как построить команду, которая будет мотивирована активно участвовать в жизни сообщества и вкладываться своими временем и ресурсами;
- как делегировать и работать с волонтерами;
- поучиться писать вдохновляющие истории, чтобы мотивировать людей.

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

Поэтому положу ссылку сюда https://vector.education/course/11

О, эти исследования! Сколько головоломок мне пришлось решить о том, как определить ёмкость рынка разработчиков той или иной специализации, сделать разбивку по их уровню, выяснить каналы взаимодействия с конкретной целевой аудиторией и т.д. Но при этом осталось ощущение, что есть более простые пути анализа и оценки, которые я не вижу. Интересно ли, чтобы я написала о своих копаниях?

А вот и этот самый рассказ про поиск данных о целевой аудитории.
Я постаралась вспомнить и описать всё. Но, если у вас все же есть вопросы к посту или по мобильщикам, то с радостью отвечу. А ещё буду рада идеям и даже критике 😇

“В поисках данных или как посчитать всех разработчиков” by Natalia Makarova https://link.medium.com/TjZPrCfPdX

​​Рассматривая аналитический отчет о devrel State of Developer Relations 2019 от компании Hoopy (большинство из вас, уверена, получают от них регулярную рассылку), мое внимание обратили на себя некоторые пункты.
Что меня удивило:
✅ Если раньше devrel службы были прерогативой технологических компаний, то теперь выделяется и растет доля компаний других профилей (финансы, телеком, бытовая техника и т.д.). Эта тенденция есть и в России, судя по чату DevRel.
✅ Была уверена, что службы devrel локализованы в технологических департаментах. А оказывается, большинство все же в маркетинге или автономны, подчиняясь CEO. Так или иначе разработчики рассматриваются как основная целевая аудитория для продажи технологического продукта или работы с ним.
✅ Нигде в отчете не идет речи о HR брендинговых целях. Таким образом, в мире devrel - это про взаимодействие с разработчиками для развития, продвижения и продажи тех.решений. Это наводит меня на мысль, что Employer brand все же дело департаментов HR.
✅ Любопытно, что наиболее популярный канал взаимодействия - ивенты и конференции, но при этом, самым эффективным назван контент-маркетинг :)
✅ А вот среди названных вызовов и сложностей я сталкивалась почти со всеми: от того, как увеличить комьюнити и базы до доказывания внутри, что мы являем реальную ценность и влияем на бизнес.

А вы уже читали эту брошюру https://bit.ly/2KvDYnK? Какие выводы для себя сделали?

⁉️Как вы относитесь к участию в конференциях со стендом?
Лично у меня очень противоречивое отношение.
Конференции - неотъемлемая часть работы devrel менеджера, но, если с эффективностью докладов более или менее понятно, то со стендами всегда возникают сложности. Такое участие очень затратно: приобретение спонсорского пакета, места под стенд, производство стенда, подготовка раздаточных материалов и разработка контента для вовлечения аудитории, обучение сотрудников, оплата участия и командировок и т.д. - набегает очень солидная сумма и комплекс затрачиваемых ресурсов. А в результате бывает сложно оправдать эффективность даже для себя. Особенно, когда речь идет о маркетинговых целях.
❇️Слагаю пост на эту тему, но хочется узнать еще мнения и вопросы. Пока в посте будет:
- цели компаний и цели конференций
- на что обращаю внимание при выборе конференций
- стенды по типу контента
- метрики эффективности

Вопросы и мнения пишите в личку @NataMakarova. Спасибо!

❓Нужен ли деврелу технический бэкграунд?
Моё мнение, все зависит от задач, которые стоят перед специалистом.
Developer Relations стОит рассматривать как общее направление работы с технологической аудиторией. А далее идёт разделение на адвокатов, евангелистов, технических писателей, менеджеров комьюнити/ивентов/программ/
проектов и др.
Таким образом, если это про организацию процессов взаимодействия с технической аудиторий, как то:
- разработка стратегии продвижения;
- организация митатов, конференций;
- создание сообществ;
- подготовка спикеров к выступлениям;
- построение каналов коммуникации;
- организация участия компании с докладами, стендами и др.активностями во внешних конференциях и т.д., то технические скилы совсем не обязательны. Это скорее полезное дополнение. Здесь важнее уметь задавать правильные вопросы правильным специалистам, заручиться поддержкой сильных специалистов продвигаемых технологий, видеть харизму в потенциальных спикерах, вдохновлять, анализировать, сегментировать, писать, поддерживать коммуникации. А умение программировать может быть плюсом, но никак не обязательным условием.
Но знание технологий определённо необходимо, если задача подразумевает непосредственное взаимодействие с целевой аудиторией. Адвокаты и евангелисты должны хорошо знать технологию, которую представляют, уметь отвечать на все вопросы относительно особенностей продукта и его разработки. Как правило, разработчики больше доверяют именно тем, кто непосредственно создаёт продукт и знает все детально.

"Люди всякие нужны, люди всякие важны..."
Я считаю, что тот, кто создаёт технологию на уровне кода, не должен отвлекаться на организационные вопросы. Достаточно с него того, что он готовит контент, представляет его в статье или в документации, дежурит в канале поддержки, развививает свои навыки докладчика. В то время как на менеджерах лежит ответственность за поиск целевой аудитории и то, как до неё достучаться, за создание каналов взаимодействия, за решение организационных вопросов, за создание положительного микроклимата для всех участников процесса.
❓А у вас есть тех.знания и скилы?

Недавно я писала про свои поиски количества разработчиков в России (кто не читал, ищите ссылку в ленте) и о сложностях поиска статистики по рынку специалистов IT в разрезе стран, языков и технологий. В дополнение к этому посту для себя и для тех, кто также считает это важным, кидаю ссылку на самую последнюю аналитику (май 2019).
Удивило, что по этим данным Франция - третья страна по численности разработчиков в Европе, а в России их только 368К. Хочется верить, что чуть больше 💪.
Отчет несколько ориентирован на рекламу рынка специалистов и разработки в Украине. Но, в целом, аналитика хорошая.
Спасибо @meowsphere за ссылку! 🎈
https://www.daxx.com/blog/development-trends/number-software-developers-world

Перепробовав всевозможные подходы к принятию решения об участии в конференциях, я все равно продолжаю собирать примеры и опыт коллег.
Например, в этой статье https://bit.ly/2ZwX7Ku речь идет об оценке по некоторым формальным критериям с использованием весов: целевая аудитория, место мероприятия и стенда, отношение стоимости спонсорства к количеству участников, участие сотрудника компании в числе организаторов и т.д.
Что-то подобное нам с коллегами тоже приходилось делать. Этот подход я считаю слишком формальным. Однако, если нужно принимать решение для формирования и оправдания бюджета перед руководством, то вполне подойдет.
На практике же приходится более подробно погружаться в каждую метрику. Если целевая аудитория, то запрашиваю у организаторов статистику с разбивкой по специализации, опыту, компаниям, городам и другим параметрам. Если стоимость участия, то складываю все расходы (от стоимости спонсорского пакета до стоимости изготовления стенда, раздатки, командировочных). Кроме этого оцениваем вместе с разработчиками уровень докладов как прошедших конференций, так и заявленных в предстоящем году.

ClickHouse — один из самых успешных российских open-source проектов последних лет. Мне повезло работать с командой разработки ClickHouse в контексте продвижения технологии с самого начала. Но прежде мне нужно было подробно изучить такое явление как open-source и его место в IT культуре. Об этом, к счастью, много информации в сети. Однако, пришлось столкнуться с нюансами, о которых мало где написано. Немного об этом опыте в моей заметке http://bit.ly/ClickHouseDevRel

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

Как-то раз я провела внутри компании мини исследование-опрос разработчиков, на что они обращают внимание, что выглядит убедительным, что мотивирует перейти по ссылке.

Коллеги набрасывали различные фотографии, картинки, иллюстрации и делились мнением.

Пользуйтесь, если нужно!
Основные выводы, которые я сделала, такие:
1. КДПВ в большинстве сами по себе не привлекают внимание, если только они не несут какой-то смысловой нагрузки. То есть какой бы прикольной или абстрактной ни была картинка, она будет восприниматься как лишняя и отвлекающая внимание.
2. Картинка должна нести смысловую нагрузку и в ней уже должен быть зашит контент: вызов, ребус, формула, ситуация и т.д.
Интересно, что такие картинки не воспринимаются как КДПВ, а читаются как часть контента или сам контент.
3. Даже картинка с юмором должна быть частью контента и подчёркивать текстовый контент.

А вот немного из того, что разработчики буквально мне писали:
💡На хабре была замечательная задача: на картинке давался URL по которому возвращается длинная строчка символов и небольшая инструкция по тому, как интерпретатор эти символы должен трактовать. В итоге, если человек правильно писал небольшую программку-интерпретатор и запускал её на строчке символов, то выводился текст вида "Приходите к нам на собеседование, <контакты>". Задача отлично заходила, потому что писалась минут за 10 и было интересно, что же там произойдёт в конце.
✔️Порой привлекают картинки из старых хороших фильмов.
✔️PixelArt нынче в моде. Можно логитипы/аттрибуты компании в него сконвертировать, народ оценит.
✔️ Непривычные картинки, побуждающие разобраться, что это такое и как это сделано. https://twitter.com/adereth/status/924409121033428992
✔️Здесь немного http://bit.ly/hereispicture
✔️«Разработчики ленивые, никто не полезет искать правильные картинки. Те, кто полезет - нерепрезентативны. Мне даже лень это в таске написать.» 🙄😂
✔️Речь именно про графический контент? Я с удовольствием читаю ленты, где его вообще нет, просто сниппет текста/кода и все.

Регистрироваться или нет?! ⚠️
Насколько подробной должна быть регистрационная анкета на мероприятие для разработчиков. Есть мнение, что технари не любят заполнять анкеты. Это связано как с осознанием ценности персональных даных, так и в целом нежеланием, чтобы их «посчитали».
Вопрос остается холиварным как для участников, так и для организаторов.
Мое мнение - должна быть длинной настолько, насколько можем себе позволить в том или ином случае.
http://bit.ly/2msIsRV
А обсуждаем здесь https://news.1rj.ru/str/MyDevRelChat