MyDevRel

📌осознает, что писать важно 📌писать хочет 📌либо имеет очень маленький опыт, либо не самый удачный 📌не умеет генерировать темы или, наоборот, идей для тем слишком много, сложно на чём-то остановиться/не уверен в себе или не знает, с какой темы лучше начать 📌статьи могут не быть осознанным приоритетом 📌следит за чужими публикациями 📌комментирует других 📌если совсем нет опыта, но мечтает засветиться на Хабре/другом профессиональном ресурсе 📌готов начать писать. Стоперы ⚠️тяжело даётся форма и оформление ⚠️нет понимания, о чём можно написать ⚠️«синдром самозванца» ⚠️может прятаться за формулировками: «это не работает», «кому это нужно?», «если писать, то писать о чём-то очень важном, а так не хочу», «а что, если не получится» и т.д. Как работаем ❇️Учим технологии избавления от «синдрома самозванца» ❇️Просим озвучить темы, на которые готов писать. ❇️Привлекаем его руководителя и команду, либо собираем виртуальную команду для обсуждения и выбора темы и помощи в подготовке плана и кейсов. ❇️Делаем подборки образцовых статей для анализа их успеха. ❇️Если есть необходимость и возможности, заручаемся помощью профессионального редактора и дизайнера. ❇️Обсуждаем целевую аудиторию, ценность статьи для ЦА, пользу и ценность для компании и команды. ❇️Определяем сроки, выделяем время, поощряем и подбадриваем сами и устами его руководителя и коллег. ❇️К вычитке привлекаем все заинтересованные стороны внутри компании. Если есть что добавить, рада обсудить в чате https://t.me/MyDevRelChat

Продолжаем... 👽Опытный разработчик, но мало авторского опыта или его совсем нет

Например, опытные авторы. Если интересно услышать про опыт работы с другими категориями, нажмите нужную кнопку внизу под постом. Опытный разработчик - опытный автор: 📌знает, что писать необходимо для продвижения себя внутри компании и вовне, для саморазвития, для бренда компании; 📌любит делиться профессиональным опытом через статьи; 📌уже написал несколько или много статей; 📌постоянно думает о том, о чём ещё можно написать; 📌следит за чужими публикациями; 📌комментирует других; 📌готов поделиться знаниями и опытом с начинающими; коллегами по написанию статей и т.д. Стоперы Как правило такие авторы быстро соглашаются на написание статей, однако могут ссылаться на недостаток времени или неуверенность в теме. Как работаем ❇️Формулируем задачу, где его экспертиза необходима компании. ❇️Убеждаем, что подготовка для блога компании будет еще больше способствовать его продвижению. ❇️Помогаем определиться с темой или просим его самого обсудить тему с авторитетными для него людьми в компании. ❇️Выделяем время от основной загрузки для работы над статьей. ❇️При необходимости привлекаем его коллег для вычитки текста.

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

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

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

Как вы думаете, что это? Некоторое время моими заказчиками были руководители новых офисов разработки компании в регионах. Для некоторых городов стратегию развития экосистемы необходимо было разработать и реализовать полностью, а где-то я только консультировала по стратегии или участвовала в отдельных проектах. Мне довелось работать с различными городами: Санкт-Петербург, Нижний Новгород, Новосибирск, Екатеринбург, Иннополис — каждый из них был уникален по своим характеристикам. На картинке - лепестковая диаграмма, которую я строю, чтобы видеть, как обстоят дела с необходимыми мне ресурсами в конкретном регионе. Анализировать инфраструктуру приходится не только для целей развития региональных офисов, но и для проведения активностей в любой новой локации. Кто-то из devrel менеджеров может добавить другие шкалы-характеристики. ❓А какие бы вы добавили шкалы в эту диаграмму? Подробнее в статье https://bit.ly/2SokTpP Делиться своим мнением зову в параллельный чат https://t.me/MyDevRelChat ❇️

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

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

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

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

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

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

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

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

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

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

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

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

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