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

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

“В поисках данных или как посчитать всех разработчиков” 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

В 2016 году в России мы запустили национальную рабочую группу по стандартизации языка C++.
Для меня - это успешный проект в рамках программы развития российской экосистемы C++ и эффективный формат работы с международным и российским сообществом. Как менеджер проекта, в статье я делюсь подробностями создания рабочей группы от идеи до запуска. http://bit.ly/cppstdwg21

Если есть вопросы, задавайте их специальном чате в телеграм https://news.1rj.ru/str/MyDevRelChat

Python - лидирует, C++ в шестерке самых популярных языков. Интересно, что ждёт нас в будущем.
https://www.facebook.com/108525613197229/posts/419456495437471/

​​Дорогие читатели моего канала!
В уходящем году я начала писать о своем опыте в сфере developer relations. Благодарю вас за поддержку, вопросы и комментарии!
Не всё задуманное удалось подготовить и опубликовать. Так, из не освещенных тем оказались:
🔹история запуска ClickHouse в open-source и интервью с ключевым создателем и разработчиком Алексеем Миловидовым;
🔹первый митап ClickHouse заграницей: как я анализировала технологическую экосистему Берлина, искала профильные комьюнити, целевую аудиторию и т.д.;
🔹зачем крупные компании открывают региональные офисы разработки и как выстроить локальную технологическую экосистему вокруг офиса: здесь я хотела поделиться своей системой аналитики инфраструктуры и построения стратегии развития региональных экосистем;
🔹мой опыт организации международной конференции по Machine Learning в Берлине в 2015 году, где в том числе расскажу, как я лично отправила более 120 приглашений иностранным докладчикам, из которых в итоге приняли участие 40 выдающихся людей. А ещё о том, что такие мероприятия могут дать компании.
🔹мысли о влиянии devrel на найм: опыт большой, но не всем смогу, к сожалению, поделиться. Поэтому напишу в формате "мысли и идеи". Надеюсь порассуждать с вами вместе.
🔹обзор книг про devrel и другой профессиональной литературы из смежных областей, которая мне помогала в свое время расти как профессионалу.
🎄Желаю себе времени и вдохновения написать хорошие посты на вышеуказанные темы и не только. А ещё мечтаю познакомится с неравнодушным к этой теме пишущего редактором себе в помощь.
💫А вам желаю в новом году удовольствия от работы, энергетической отдачи от коммуникации с вашей целевой аудиторией и вдохновения от общения с коллегами!
До встречи в 2020! 😍

Положу сюда. Обязательно пригодится!✅ https://netology.ru/blog/prg-tg

Как вы думаете, что это?
Некоторое время моими заказчиками были руководители новых офисов разработки компании в регионах. Для некоторых городов стратегию развития экосистемы необходимо было разработать и реализовать полностью, а где-то я только консультировала по стратегии или участвовала в отдельных проектах.
Мне довелось работать с различными городами: Санкт-Петербург, Нижний Новгород, Новосибирск, Екатеринбург, Иннополис — каждый из них был уникален по своим характеристикам.
На картинке - лепестковая диаграмма, которую я строю, чтобы видеть, как обстоят дела с необходимыми мне ресурсами в конкретном регионе.

Анализировать инфраструктуру приходится не только для целей развития региональных офисов, но и для проведения активностей в любой новой локации.
Кто-то из devrel менеджеров может добавить другие шкалы-характеристики.

❓А какие бы вы добавили шкалы в эту диаграмму?
Подробнее в статье https://bit.ly/2SokTpP
Делиться своим мнением зову в параллельный чат https://news.1rj.ru/str/MyDevRelChat ❇️

Недавно в чате devrel зашла речь о текстовом контенте и почему статьи так важны.
Здесь же обсуждались подходы к мотивации разработчиков готовить тексты о своей работе.
Полезный пост-продолжение этой дискуссии подготовила Антонина Татчук в своем канале @Editors_cave. Если интересует, советую почитать.
От себя хочу добавить, что именно с текстов и стоит начинать деврел стратегию, а уже потом браться за доклады и иные активности. Как правило разработчики визуалы, текстовая подача первична: документация, статьи, код, переписка в профессиональных чатах с коллегами. Если что-то надо найти по теме, то сначала будут искать тексты и только потом смотреть видео докладов.

Вовсю идёт обсуждение удалённых форматов работы с аудиторией. Все пытаются перенести митапы в онлайн или как-то их адаптировать.
❌Но спикеры не верят, что их так будут внимательно слушать, что получат желаемую обратную связь, то есть отработают впустую и их труд будет обесценен.
🔓 И, кажется, решение лежит в том, чтобы абстрагироваться от митапов, перестать виснуть в привычном опыте и начать думать про совершенно иной тип контента.

Задача - максимально привязать каждого зрителя к монитору, сделать его частью происходящего.
⁉️Задумайтесь, нужно ли проводить конференции на несколько докладчиков?
❓Что удержит у монитора каждую минуту?
❓Как сэкономленные от офлайн мероприятия средства вложить в удержание внимания каждого отдельного участника у экрана?

✔️Игровые, соревновательные, образовательные форматы - решение в них.

В продолжение темы про мотивацию разработчиков писать статьи.
Немного из своего опыта.

У каждого своя мотивация. Пока её не откопаешь, дело не пойдет. И это применимо как к написанию статей, так и к выступлениям и любым другим активностям.
«Тщеславие - мой самый любимый из грехов!». Желание признания есть у каждого. И тем более у тех, кто рожден, чтобы изменить мир к лучшему (я о разработчиках).
Писать хотят все (ну, или почти все), но вопрос, почему не соглашаются?
Когда я прихожу к разработчикам, то пытаюсь определить, на какой степени опыта, осознанности и готовности находится человек, чтобы писать статьи. Для себя я их классифицирую на четыре категории:
1️⃣Опытный разработчик - опытный автор
2️⃣Опытный разработчик, но мало авторского опыта или его совсем нет
3️⃣Опытный разработчик, но категорически отказывается писать или ленивый
4️⃣Молодой специалист, совсем нет опыта в подготовке статей.

У каждого свои стоперы. С каждой категорией надо работать по-разному.

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

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

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

Как работаем
❇️Формулируем задачу, где его экспертиза необходима компании.
❇️Убеждаем, что подготовка для блога компании будет еще больше способствовать его продвижению.
❇️Помогаем определиться с темой или просим его самого обсудить тему с авторитетными для него людьми в компании.
❇️Выделяем время от основной загрузки для работы над статьей.
❇️При необходимости привлекаем его коллег для вычитки текста.