В этой статье обсуждается экзотическая в наших широтах, но такая привлекательная, тема - продвижение open source продуктов - Data-Driven Open Source: Why You Should Care About Metrics часть 1 и часть 2

Ниже конспект для фанатов (если будете читать исходник, сразу переходите ко второй части)

На метрики забивают не только компании, но и [сюрприз? нет!] некоммерческие организации и объединения. В основном потому, что считают, что отношения не измерить [в любовь к продукту только верить, простите]. Автор уверен, что такой подход лишает их возможности принимать более осознанные решения.

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

Итак, компании, работающие с сообществами строят отношения и развивают здоровую атмосферу. Но разработчики приходят в сообщество не за этим. Они хотят решить свою проблему, научиться чему-то или на что-то повлиять. Логично, что в таком случае нужно улучшать опыт контрибьюторов (а про это прямо мало кто говорил автору как про свою цель).

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

Выделить вклад DevRel в описываемой ситуации непросто, так что многие идут по легкому пути и считают звезды на гитхабе и количество пользователей в слаке проекта, просмотры постов в блоге и т.п.. Но привязка DevRel к выручке может быть жизненно важна для функции в компании. Придется “выровняться” по бизнес-целям и понять, какие DevRel-инициативы необходимы, чтобы к ним приблизиться. Важно найти свои ключевые индикаторы и фокусироваться на них. Например, на превращение участников сообщества в своих амбассадоров или на конверсию из пользователей опенсорса в платящих клиентов.

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

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

Ну и это же опенсорс, напоминает автор, спросите у тех, кто проходил этот путь, и они поделятся.

[Чтобы не зацикливаться на контрибьютерах кода, могу поделиться еще парой интересных метрик из личного опыта. Например, можно считать “проникновение” технологий в конкретную отрасль по количеству контактов из нее или по количеству вакансий со знанием конкретной технологии или упоминанием её в стеке. Или можно примерно оценить охват в регионе по количеству профилей в LinkedIn, в которых люди указали, что владеют именно вашим инструментом в блоке “навыки”.] #метрики #opensource #конспект

В симпатичном мне блоге Avocado Bytes (да, снова намек на aDvocado и книгу Mary Thengvall) нашла статью Keeping Up to Date With News and Trends When Working in DevRel про систему, которую Daniel Bryant разработал для того, чтобы оставаться в курсе и обновлять знания в интересных областях. С практической стороны это история для дев. адвокатов, но теоретически можно переложить на любую область. Система дотошная, что хоть форточку открывай, то есть, прямо как я люблю.

Определите цель
- Скажите, пожалуйста, куда мне отсюда идти?
- Это во многом зависит от того, куда ты хочешь прийти,- ответил Кот.
- Да мне почти все равно,- начала Алиса.
- Тогда все равно, куда идти,- сказал Кот.
Льюис Кэрролл "Алиса в стране чудес" [это не я, это автор статьи цитирует]

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

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

[Заметила не совсем обычное применение твиттера: автор делится там публикациями на интересные темы не только, чтобы показать себя, но и чтобы набежали экспертные эксперты и их можно было бы спросить что-то еще по теме. Кажется, немного рискованным, если не можете пока отличить, кто комментатор-молодец, а кто мешки ворочает. Вариант тегнуть эксперта, про которого вы уже что-то знаете, намного интереснее, хотя тут есть риск быть навязчивым, чувство меры в помощь.]

Сформируйте систему самообучения
Даниель разбил действия на "циклы":

- ежемесячно: просмотр RSS и добавление в закладки интересного, видео докладов; минимум 1 час, чтобы убедиться, что информация организована. [последнее очень важно, особенно, если долго не было возможности заняться этим делом]
- еженедельно: чтение рассылок, просмотр важных сайтов/чатов сообществ, минимум 1 час на разбор интересного из закладок
- ежедневно: проверять соцсети, заходить на важные новостные сайты, 15 минут на просмотр открытых вкладок.

Под все эти действия он блокирует слоты в календаре. [Разумеется, другого и не ждала]

Следуйте этой системе (проще сказать, чем сделать)
Не ругайте себя, если отошли от рутины на неделю или даже месяц. Когда у вас горит большой проект, сохранить здоровье (и ментальное тоже) важнее. Потом нагоните. [Если все хорошо разложили по папкам в почте или папкам в телеграмме, или в какой-то инструмент вроде ноушен, будет проще]

Профит
Следуя этому руководству вы сможете развить привычку учиться и накапливать знания. Автор приводит несколько примеров, почему это стоит сделать. Сам Даниель успел запрыгнуть в модную технологию; сделал классный контент, который привел к докладу, а из того выросла книга; самые популярные твиты были именно с обсуждением новостей технологий.

[Особенно хочется обратить внимание на два момента: 1)блокировать время в календаре 2)общение с людьми в отрасли - важная часть процесса.] #инструменты #конспект

Cо мной тут поделились статьей Eight years of organizing tech meetups (привет, Стэн!) и спросили, что я думаю. Я думаю, что это офигенная статья, в первую очередь, по форме. Интернет переполнен историями успеха. И если дочитать до конца, то и эта могла бы называться «Как я создал большое клевое сообщество на дискорде». Но 90% статьи занимает рассказ про то, как автор раз за разом пробовал что‑то оффлайн организовать и бросал.

И это делает статью намного полезнее! Во‑первых, понятно, что организовывать что‑либо это достаточно серьезная дополнительная нагрузка (автор пишет про это прямым текстом).

Во‑вторых, что «что‑нибудь поделать» — недостаточно хорошая причина для разработчиков, чтобы собраться и тем более продолжать собираться регулярно. Охотнее всего люди собираются для закрытия своих потребностей. Например, у автора замечательно сработала группа для совместного чтения и обсуждения книг и статей про распределенные системы. Люди хотели разобраться в теме и группа дала им такую возможность.

Этих двух мыслей вполне достаточно, чтобы всячески советовать читать статью по ссылке. Третьей причиной, пожалуй, может быть знакомство с форматом paper reading club, которые не так уж распространены у нас, а жаль. #инструменты

Зачем оценивать, на какой стадии зрелости DevRel-функция в компании или отдельном направлении? Например, чтобы “штаны не порвать”, широко шагая в своем планировании через ступеньку. В статье The Developer Relations Capability Maturity Model Jordan Violet сформулировал путь, который проходит DevRel, таким образом:

1)Неорганизованные усилия, большая вовлеченность конкретных людей, часто в свободное время: на этом этапе жизненно важно найти сторонников в менеджменте, которые могут сказать “да, мы будем заниматься DevRel” (то есть, поручиться перед остальным руководством, что в этом есть смысл для компании)
2)Простые, но достижимые цели, 1-3 человека в команде: выбираем легко достижимые цели, чтобы доказать свою полезность
3)Сформулированы цели и задачи DevRel program [интересно, что у нас кальки с этой концепции никто не использует], бизнес признает пользу от вас: на этом этапе обычно появляется возможность расширить команду, тут важно не забыть периодически синхронизироваться с целями компании
4)На этом уровне уже запущены все ключевые проекты, но они могут как работать, так и стухнуть: если вы добрались до этого уровня, значит, прошло определенное время, но это не повод почивать на лаврах [просто вы ближе к пенсии на несколько лет мухаха, от описания автора возникает ощущение легкой заболоченности, что же, возможно, что сотрудники уже устали гореть, и да, это момент, когда команда может поменяться]
5)Ценность отношений с разработчиками понятна, а усилия можно измерить [вообще там написано “измерить количественно”, но я бы сказала просто измерить]: пик развития. главное продолжать делать всякие новые вещи на этом вашем новом уровне.

В каждом пункте Джордан приводит примеры, как это было в его карьере. И мне кажется, путь не особенно ‘экзотический.

Я бы все-таки сказала, что это не лестница, а колесо, и внешние обстоятельства еще дадут вам пинка. Например, весь мир сядет дома и выйдет в онлайн, или поменяется рынок, на котором работает компания, сама компания изменится так, что поменяются бизнес-цели, или прорыв произойдет в технологии. И тогда, на этапе 6 вам снова придется пройти версию этапа 1, только старые достижения будут мешать сосредоточиться на новых вводных.

В общем, скорее пост — хороший повод для размышлений, но не прямо “бери и пользуйся”. #конспект

Решила обновить закреп и поняла, что с июля месяца списочек каналов успел немного вырасти, обновляю тут тоже:

ТГ-каналы про Developer Relations и коммуникации в IT:

Говорите громче! - канал Жени Голевой про работу деврелом, публичные выступления, обратную связь и обучение взрослых

My DevRel - канал Натальи Макаровой про работу в DevRel

не доводи спикера - канал Адель Макашовой про работу со спикерами и не только

Логово редактора - канал Тони Татчук про контент-маркетинг в технологической сфере.

что-то на техпиарном - канал Алины Боровицкой про осознанный SMM, техпиар и софт-скиллы <3

Geek Relations - коммуникации и образование в ИТ. DevRel. TechComm. Knowledge management. ITHR. Немного BigData и AI.

DevRel Склад - канал Ксении Романовой с краткими конспектами и комментариями по материалам о Developer Relation и Community Management (в основном зарубежным)

23derevo - канал Лёши Федорова из JUG Ru Group о работе над IT-конференциями (самый движ происходит в чате канала)

Это работа для DevRel’a - канал @svetlanada с вакансиями для DevRel-менеджеров, Tech PR, редактуров технических текстов и IT HR

Деврел-бюро - канал, где Алексей Долгушев и Мишаня Сторожилов иногда рассказывают про DevRel и постят вакансии

Про DevRel - канал Анастасии Аткиной, CEO, Hack Agency Russia. Анастасия пишет про DevRel с агентской стороны

IT-brand rules - канал про IT-HR-бренд от команды исследования IT-брендов Хабра и Экопси

Технотекст - канал от команды Хабра о том, как писать и редактировать технические статьи (прежде всего на Хабр)

В англоязычном DevRel-сообществе весь сентябрь расходится ссылка на статью Jeremy Meiss Moving Developer Relations Forward в пяти частях. Там все, как я люблю: с особым маркетинговым цинизмом и волнением за профессию. Почитаем и мы.

Часть 1 — Moving Developer Relations Forward
Последние лет пять (может быть и дольше, но все что было до ковида сейчас кажется несколько туманным) активно обсуждают, что DevRel это вам не: продажи/маркетинг/пони и радуги/ваш вариант. И это обсуждение ведет профессию в никуда. Просто потому, что определение через “не” никак не помогает сформулировать то, что настолько сильно варьируется от компании к компании.

Часть 2 — The foundations of Developer Relations
Джереми вспоминает, что вообще-то DevRel существует уже лет 30, правда начинает не с Apple, как многие из нас привыкли, а с Netscape. Долго ли коротко ли, а DevRel — это организационная функция.

Часть 3 - Asking the right questions for DevRel impact
Здесь автор напоминает нам о прекрасной книге Первые 90 дней (Майкл Уоткинс, издательство МИФ) и собственном посте о том, как преуспеть на новом месте. Но также и дает вопросы, которые стоит задать ДО того, как принимать офер:

1)Как компания зарабатывает и где теряет деньги?
2)К какому отделу относится DevRel-команда?
3)Какие крупные цели у отдела и всей компании на этот квартал/год?
4)Откуда эти цели берутся и кто присматривает за их реализацией?
5)Что от нового специалиста ожидают в ближайшие 30/60/90 дней?
6)Зачем им тут вообще DevRel?

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

Продолжение следует

Принесла вам ложку дегтя в видосике Why I Left Developer Relations. Ali Diamond 5 лет работала в DevRel, а потом вернулась на позицию software developer и счастлива. Давайте посмотрим, что ей не нравилось в профессии:

1)Мало писала код [Есть у нас тут пиарщики, которые тоскуют по пресс‑релизам?]

2)Компании сами не знают, чего хотят: заводят функцию из прихоти, предлагают одному человеку делать работу отдела, а с отделами тоже есть подвох, но о нем дальше [Для маркетолога вообще ничего нового, к сожалению]

3)Инфлюенсеры: круто, когда рынок знает человека, но создание контента только часть работы, которую нужно делать. В результате часто случается взаимное разочарование [Это почти что пункт два, когда от самого факта найма ожидают, что всё заколосится. Справедливо также в отношении некоторых других позиций в компании или целых модных направлений, вот, например, с облаками такое было когда‑то]

4)Невозможность отделить личное от рабочего в онлайне: как будто бы ты всегда выражаешь позицию компании или сообщества, никаких легкомысленных и рискованных шутеек [Мне это всегда казалось частью того, за что компания тебя «покупает»]

5)DevRel очень сложно измерить: а в бизнесе сейчас постоянно нужно доказывать, что команда необходима [Вам больше пункт 2 или 5 нравится? Всё такое вкусное! Вот тут как раз у PR и маркетинга есть чему поучиться и собранные на коленке велосипеды могут быть опасны для карьеры]

6)Никто не знает идеальной стратегии: очень все неоднозначно и зависит от конкретной компании и ситуации [Попейте чайку с маркетингом вашим, там уже давно придумали, как вертеться. Или не вашим, если ваш не вертится]

7)Нас увольняют первыми: Али за пять лет трижды увольняли при реструктуризации [Хотелось бы сказать, что пункты 5 и 6 могут вас подстраховать, но нет, иногда это решение никак не связано с продуктивностью, просто отказываются от того, без чего все еще можно функционировать. DevRel — функция для сытых.]

8)Техническая роль, с которой обращаются как с не технической [Это больше про «их нравы», когда DevRel вокруг продукта и надо уметь код прочитать, написать, и сделать яркую демку]

9)Люди: отрасль маленькая, зато эго у людей огого, и это приводит к конфликтам [В начале видео Али говорит: «Считается, что в DevRel (США, как я понимаю) 800 человек, ну теперь 799». Мы когда‑то по чатам на глазок насчитывали 400 человек в России. Наверное, кто‑то кого‑то бесит, отчего нет, но прямо скандалов пока не припомню.]

10)Очень ограниченные карьерные возможности: чтобы найти хорошую компанию, вменяемый менеджмент, где нужны твои навыки, да за них еще и могут достойно заплатить, нужно действительно постараться. Разработчику для этого нужно просто открыть резюме и вариантов будет намного, намного больше. [Абсолютно справедливо и для России, особенно для начальных и синьор+ позиций. Пожалуй, не только для DevRel, но и если интересно делать вещи определенного масштаба или в конкретной области. Обычно те же разработчики, что у нас, что на Западе, кочуют годами между пятью‑десятью банками или телекомами. Чтобы сделать шаг в сторону, нужна изрядная смелость] #професияdevrel #карьера #конспект

Вообще-то это канал с конспектами, но не могу не заметить, что у нас произошла рекурсия: DevRel на сцене Highload++ 😁

Кажется, пришло время обновить закреп (конечно, дело к ночи, надо написать несколько текстов к DevRel Conf, пора!)

Этот канал ‒ обязательство! Обязательство регулярно разгребать завалы полезных материалов по Developer Relations и писать хотя бы коротенькие аннотации и мысли по поводу.

Кто читает? @ks_romanova ‒ организатор DevRel-завтраков и митапа в Петербурге.

На какие темы читаю? #communityrelations #карьера #тренды #этосновабылопыт #инструменты #метрики #PR #opensource Иногда пишу от себя под тегом #блог

Несколько интересных постов и конспектов, которые стоит просмотреть:
3 новинки и 2 "старинки" с книжной полки
А что есть вместо хабра в глобальном интернете
Метрики сообщества, которые имеет смысл замерять
Как писать документацию, которая нравится разработчикам
Как нанять(ся) на работу DevRel-специалиста
Краткая и пристрастная подборка кейсов PR-премии Loud 2023
Развивая Developer Relations. Конспект в двух частях для популярной статьи в пяти частях ‒ часть 1, часть 2
Подборка докладов с DevRel Conf 2023
Сообщества вокруг технологии: почему быть бесплатным недостаточно


Подборка каналов про DevRel
Подборка каналов про Digital
Подборка каналов про комьюнити-менеджмент

Уже завтра седьмая, а для этого состава ПК - вторая, DevRel Сonf. Было сложно выбрать из такого количества заявок (аж 43!). Были и споры, и попытки утрамбовать поплотнее (в результате у нас набралось довольно много 15-минуток), пришлось и отказаться от некоторых хороших докладов (ждите анонсы следующего DevRel-митапа). Так что программа выстраданная и, как просили в прошлом году, очень практичная, ну прямо бери и делай (а в некоторых случаях, не делай). Единственное, пожалуй, исключение, рассказ про IT-каток и IT-пикник. Ну просто мы никак не могли пройти мимо настолько большого для отрасли события. Думаю, даже если ваш бюджет не похож на бюджет Тинькофф, все равно интересно, зачем они это сделали.

Начнем в 12:30, так чтобы до оффлайна доехали пассажиры Сапсана, а москвичи нормально выспались. Программа и регистрация на онлайн (да, места на оффлайн уже нет): https://devrelconf.ru/ #devrelconf

Опубликованы видео докладов DevRel Conf #7, которая прошла 9 декабря.

Концепция у ПК была такая: даешь ссылку на плейлист и джун экономит дни (которые пришлось бы провести за сбором опыта старших коллег по чатам и подкастам), а синьор ставит на скорость Х1,5 и оперативно сверяется с лучшими примерами индустрии. В 2022 году девиз был «Власть, бюджеты и хэдкаунт», а в этом — «Бери и делай».

Поделюсь моим личным зрительским топом. Он целиком состоит из докладов про то, как оно там в 2023 году:

Алина Боровицкая (канал что-то на техпиарном) «Дистрибуция контента, и за что они с нами так» — тут поменялось примерно всё за последние года полтора.

Антон Черноусов (подкаст The Art Of Programming и другие) «Давай запустим подкаст... или нет» — доклад с актуальной статистикой и о том, как подходить к подкасту, когда их уже только ленивый не делает (или делает, но лениво)

Алина Каширская «Осторожно, тонкий лед: от IT‑катка до IT‑пикника» — о событиях года (в моем понимании). Раньше такого не было, а в этом году Тинькофф сделали. Странно было бы не обсудить на конференции 2023.

Полный плейлист конференции

#инструменты #devrelconf

А вот на этом месте Алина Боровицкая рассказывает самую главную вещь про весь-весь маркетинг и коммуникации. Не благодарите:

В 2023 глобальные технические компании уволили 262 735 человек. Есть даже специальный сайт, который считает это по официальным заявлениям. Цифра за 2024 год, возможно, будет больше, потому что только в январе это уже 34 250 увольнений. Не все увольнения окончательные (кого‑то взяли обратно на худших условиях, например), но тенденция нервная. Увольняют и DevRel‑специалистов (увы, это функция для сытых времен). Что заставляет некоторых давать довольно мрачные прогнозы. Мы все ещё говорим об американском и глобальном рынке, напомню, но, знаете ли, memento mori.

В моем любимом блоге Avocado bytes Daniel Bryant делится своим взглядом с посте The Death of DevRel (Again?) and the Rise of Product Advocate and Community Roles.

Во время пандемии и сразу после нее, — пишет Даниэль, — всем пришлось обходиться без конференций и бустанул контент для разработчиков, dev‑адвокаты были нарасхват, целью многих DevRel‑команд был рост (не считаясь с расходами). А вот в 2022 компании начали экономить и сменили девиз на «делать больше малыми средствами». Кое‑где попросту избавились от DevRel‑команд или больше части сотрудников. Основная причина — до этого слишком много специалистов наняли в расчете на продолжающийся рост [та же штука, что и с разработчиками, что закономерно]. А вторая причина, как легко догадаться, — отсутствие четкой связи между работой команды и бизнес‑результатами [место для напоминания про серию постов Moving Developer Relations Forward].

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

Знакомимся с новым термином: технический SDR (sales development representatives). Продажники недостаточно технические ребята, чтобы разработчики хотели говорить с ними про инструменты разработки [именно их обычно продвигают при помощи Developer Relations на западе], а DevRel‑специалисты недостаточно ориентированы на продажи. Во имя прибыли компаниям ничего не остается, как сблизить эти две функции. Широкие брендовые жесты хороши для крупняка [что не всегда означает, что и там эти деньги предпочтут потратить с более понятной отдачей].

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

[Так называемого «продуктового DevRel» у нас не так много, так что не у всех есть отдел продаж, куда можно сходить. Но вот если он существует, крайне рекомендую. Часто там люди более мотивированы, чем в маркетинге, и готовы экспериментировать с инструментами. DevRel? Почему бы и нет, если это поможет собрать лидов или продвинуть их по воронке. Во всех остальных случаях полезно подумать, что делает нашу функцию не предметом роскоши, на котором легко в случае чего сэкономить, а неотъемлемой и понятной частью чего‑то важного для компании.] #конспект