Ксения Романова | DevRel и другие коммуникации в IT

В симпатичном мне блоге 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)общение с людьми в отрасли - важная часть процесса.] #инструменты #конспект

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

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

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

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

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

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

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

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

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

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

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

Подборка каналов про digital от комьюнити «Прости, что голосом»

DNative — блог Ткачука про SMM — актуальные новости из мира социальных сетей

Русский маркетинг — подборка новостей из мира маркетинга, не только диджитал

HotDigital — свежие мировые диджитал кейсы

seen — авторские подборки интересных кейсов

Кириллица.дизайн — всё про веб-дизайн с кириллицей

Полезный Парфун — кейсы и новости для маркетологов и топ-менеджеров от Алексея Парфуна

Кабачковая икра по акции — подборка кейсов

HR4PR — исследования и вакансии с уклоном в пиар

The Content is The Queen — канал консультанта Линор Горалик о контенте, стратегии и коммуникациях

Кинжал — про софтскилс, как жить эту жизнь и работать эту работу без насилия над собой (у них классные картинки!)

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

Продолжаем насматриваться, подборка каналов про DevRel уже была выше, а теперь подборка от друзей из сообщества Digital-специалистов. Всё проверено и точно поможет вкатиться в тему, если вам это интересно или требуется по работе.

Коммуникационная премия LOUD благополучно завершилась, выложили видео с презентациями проектов, но вряд ли кто-то осилит 7 с лишним часов. Что же, поскольку часть этих часов я провела в качестве члена жюри прямо в том самом зале, вот вам краткая и пристрастная подборка кейсов, которые могут кое-чему научить коммуникатора, например, если этот коммуникатор занимается Developer Relations. #loudaward

Google объявил, что скоро добавит в результаты поиска новый блок, составленный из мнений на пользовательских форумах и т.п. Называется “Перспективы”. Дескать, узнайте сразу от людей, которые понимают в Java или вязании крючком. Как именно будут отбираться и ранжироваться результаты, пока не известно.

Community-менеджеры и обрадовались, и напряглись сразу. CMX собрали подборку мнений. Аргументы “за” начинаются с того, что многие люди уже годами сразу начинают поиск с Reddit, потому что поисковик выдает оптимизированную ерунду (и наконец-то они это поняли). Есть некие оптимистичные надежды, что вот теперь все оценят, насколько важны настоящие отношения и кто в команде сидит на “золотой жиле” SEO.

Среди аргументов “против” то, что многие очень живые сообщества тусуются в дискорде и слаке, которые не индексируются поисковиками. И, главное, насколько пострадает то самое живое общение, когда компании примутся оптимизировать его плоды, вероятно, используя в качестве комментатора нейросети. [Главная проблема для читателя, это то, что ИИ не интеллект, а генеративная модель, которая выдает текст, а не мысль.] Нет уверенности, что поисковик распознает плоды труда своего искусственного родственника. И таким образом пользователю будет выдана чушь, а форумы будут покрыты этой самой чушью в три слоя.

Лично мне кажется, что стремление людей получить ответ на тот вопрос, который они задали, а не оптимизированный сиропчик от компаний про их продукты, недооценивают. Если Reddit “испортится”, будут начинать поиски с какой-то новой точки. Чтобы немного преисполнится реализма, достаточно зайти в комментарии в каком-нибудь крупном телеграмм-канале. Буквально на этой неделе пошло тестирование ботов, которые генерируют резюме по основному посту с добавлением “очень интересно” и подобных подходящих почти под любой случай довесков. Пользователей бесит. #тренды #communityrelations

Коммуникаторы: обсуждают, что некоторые шутки, которые были классными 5-6 лет назад, в 2023 уже слишком рискованные для репутации компании

Тем временем некоторые шутки: https://Fuckjava.com

ТГ-каналы про 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 и постят вакансии

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

Конечно, не конспект, но я не могу наслаждаться этим одна! На выставке “Египетские мотивы в истории Санкт-Петербурга” в Петропавловской крепости увидела афишу. Встречайте: неизвестный копирайтер нэпманского (потому что Царское село стало детским в 1918 году только) кинотеатра Казино. По-моему, его находки можно вставлять рэндомно в любой анонс, чтобы увеличить привлекательность мероприятия на 1000 пойнтов!

*Собств. исправное электрическое освещение
*Ввиду исключительного успеха и по желанию публики
*Участвуют тигры, змеи и свыше 10.000 человек артистов
*Всюду фурор! Всюду успех!
*Все Детское Село будет петь [подставить нужное]

Просто представьте это в описании своего митапа. Ну красота же!

Хочется мем из этого скриншота. Apache Spark сделали офигенную вещь, но комментарии про недостатки документации ("всегда такая фигня") немного портят момент. Документация - часть Developer Relations и первый пункт меню, который интересует разработчика на продуктовом сайте. PS и да, у меня явно сеть connections повышенной занудности

В процессе обсуждения перебрала свою PR-библиотечку, и нашла сборник эссе Михаила Умарова “PR в реальном времени. Тренды. Кейсы. Правила” 2016 года (на фото в центре). В основном работает до сих пор. Особенное внимание обратила на главу “Как измерить результаты PR”. Пожалуй, уроки пиарщиков и деврелам подойдут. Сделала конспект (чего не сделаешь, чтобы убрать книгу обратно в шкаф уже). #PR #метрики #книги

Они еще и квиз сделали по мотивам исследования. Так что если лень читать, начать можно с него: https://commonroomresearch.typeform.com/devrelroles2023 Меня разоблачилиопределили довольно точно

A review of DevRel job titles and career progression

Hoopy (DevRel-консультанты и организаторы DevRel Con) выложили результаты исследования на предмет того, какими должностями наделяют ответственных за DevRel. Начнем с теории. В списке основных "ролей" кроме дев-адвокатов и ожидаемого управления сообществами появилось что-то новенькое: Developer Educator. Не волнуйтесь, это знакомая песня на новый лад (и, возможно, ее исполняете именно вы).

Адвокатов поделили на несколько видов:
- outreach-focused (по-старому это "евангелисты")
- product-focused (больше про обратную связь с пользователями продукта для разработчиков, создание или инициация создания удобных доп инструментов и т.п.)
- internal (развитие инженерной культуры внутри, внутренние сообщества, коммуникация между командами и т.п.)

Пока ярче всех сияют outreach-focused адвокаты, менеджеры по развитию сообществ возделывают почву, на которой расцветает developer program (то, что и зачем будут делать с разработчиками в принципе).

До недавнего времени контент для разработчиков чаще всего создавали техписы и тренеры, а дев адвокаты заполняли пробелы менее формальным контентом. Developer educator беспощадно рвет со своим прошлым и в то же время трепещущей рукой сбрасывает таинственный покров будущего разрабатывает learning journeys (как customer, только learning), не чуждаясь новых форматов и педагогических приемчиков.

Для каждого вида специалистов есть примерный список обязанностей (основных и тоже встречающихся), требования и даже обозначено место на "радаре DevRel": Адвокатство, Маркетинг, Сообщество и Успех пользователя (Enablement). Ну и пару страничек посвятили карьерной лестнице.

Кроме трех основных типов должностей в классификацию вошли:
- менеджер программы (как менеджер проекта, только программы)
- операционный менеджер (ежедневная поддержка деятельности DevRel-команды)
- Developer experience engineer (как будто бы выделенная в отдельную роль часть работы дев-адвоката, если пользовательский опыт критически важен для коммерческого продукта)
- Developer success engineer (как техпод, только еще лучше, потому что активно ищет, как бы сделать жизнь инженера-пользователя лучше)

С одной стороны, старая работа - новые названия. С другой стороны, такие переименования и пересборка "шляп" на отделе (даже если головных уборов по-прежнему больше, чем голов) отражают приоритеты компаний и следить за ними поэтому полезно. #тренды #карьера

Наконец дописала рекап нашего стрима про резюме, собеседования и все такое на джуновые и мидл позиции в DevRel. Получила за это время несколько отзывов, судя по ним, вопросы мы выбрали правильные и ответили на них достаточно развернуто. Намного больше люблю оффлайн, но чтобы собрать таких экспертов, можно и стрим. Теперь со вкусом букв: https://habr.com/ru/articles/738334/ #карьера

Кажется, собирается новый книжный пост. В прошлый раз были книги на английском, теперь фиг знает, как их купить, зато вот эти относительно свежие (третья, про hr brand, только что вышла). #книги

Посмотрела запись онлайна с Настей Кабищевой, где она рассказала, как начала делать DevRel для армянского банка, где проект, несмотря на удачные первые шаги, поставили на паузу: https://www.youtube.com/watch?v=wJlRaVnV3Zs

Выделила несколько особенно интересных мне “граблей”, на которые может наступить даже самый синьорный синьор, потому что “дело не в тебе, username”.

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

Решение сверху есть, а понимания нет. Так появляются странные метрики (ни с одной из которых запрашивающие не знают, что делать) и бесконечные отговорки на среднем уровне. Мне очень понравилось, как Настя вела от “хорошо бы” к конкретике через серии встреч, итоги каждой из которой четко фиксировались.

Нет понимания, но есть страхи. Многим бы хотелось, чтобы люди на работе работали без всякого вот этого там межличностного. Но так не бывает. Сверху сказали, что мы делаем что-то непонятное, появляется новый важный человек со своими идеями, обсуждает их с твоим руководством… а не подрывает ли это твою репутацию и власть, директор по маркетингу или HRBP? Кое-кто может подумать, что да. И начнет саботировать реализацию задуманного. Тут всегда многое зависит от личностей людей, с которыми нужно договариваться, и нет 100% гарантии, что договориться получится. Хороший пример из записи: как Настя разбирала возражения, пытаясь узнать, откуда (пред)убеждение появилось.

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

DevRel-бюджет не был заложен в текущий год. И этот пункт тоже про работу с людьми. Можно поискать, вписывается ли трата в маркетинг, HR, обучение или нужно согласовывать ее отдельно (и через кого это будет проще сделать). Очень хороший пример в стриме про согласование DevOps Conf и участия в Highload++ Armenia

Актуально для работы в “странах релокации”: для работы с HR-брендом может понадобиться знание местного языка, а для работы с сообществом - местного и английского. И на этом моменте часть спикеров или стендистов (например, владеющие только русским и английским) может просто отвалиться.

Очень полезный стрим, есть, над чем подумать. #конспект #карьера

Если вам захотелось тут же отпраздновать "день DevRel", то я уже погуглила. И испытала смешанные чувства:

День программиста празднуют 13 сентября, а что делать, если вы хотите отдельно закатить вечеринку в честь фронтенда и отдельно в честь "дата сатанистов"? У Data science уже три года как есть свой праздник - четвертая пятница апреля (в 2023 выходит 28 апреля, еще успеваете), а у фронтендеров нет. Подсказка в статье Codenrock: 7 мая, которое называют «Днем CSS» (Cascading Style Sheets) или 10 ноября. Этот день совпадает с датой создания проекта jQuery, который является одним из наиболее популярных JavaScript-фреймворков для разработки фронтенда. Сохраняем в закладки, еще пригодится: https://codenrock.com/blog/professionalnye-prazdniki-v-it/ #инструменты