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

What to Do When Blog Authors Leave Your Company
Компании ведут блоги, в них пишут сотрудники, которые потом увольняются. Контент принадлежит компаниям, но это, считает автор, не повод быть грубыми. А то, как компания поступает с этими постами, характеризует именно что компанию. Итак, в порядке от худшего к лучшему:
1)Передать авторство реальному или выдуманному лицу (а так можно было? 0_0) - отстой, потому что договоренность была не на ghostwriting, а на создание материалов для компании
2)Удалить пост - и, если он был читаемым, то вы сам себе злобный буратино
3)Не делать ничего - да кому, какая разница, кто это написал, и что с ним сейчас, если пост полезный. Настоящие СМИ именно так и поступают, и почему бы компаниям идти другим путем.
4)Обновить био автора, чтобы отразить смену работы - респект, если у вас есть время следить за карьерой всех своих авторов. Если хотя бы поставите "работал в ..." в прошедшем времени, вы уже молодец. #инструменты #конспект

Как обычно, многое из технической документации годится и для авторов блогов и прочего контента для разработчиков. Конспект выступления на PyCon US 2022 “Как писать документацию, которая нравится разработчикам”

1)Сразу к делу - вычеркивайте лирику и начинайте с реальных проблема. Все равно все до этого момента проскролят;
2)Проматывание - это вообще нормальный способ чтения документации, сделайте так, чтобы скролилось удобно: заголовки, подзаголовки, названия библиотек жирным и т.п.
3)Проверяйте (и лучше в другом окружении, а не на себе), если документации нет, ее можно поискать в другом месте, если она с ошибками, вы крадете время у разработчиков;
4)Не рассказывайте, а показывайте, что делает ваш продукт
5)Инклюзивно и читабельно - избавляйтесь от оценочных словечек вроде “просто” - для кого-то предложенное может быть очень даже непросто. Используйте меньше академичных словечек и не забывайте, что не у всех такой же опыт, как у вас. “Пишите так, как говорят ваши пользователи”. Лучше не использовать локальных культурных отсылок, которые будут не знакомы пользователям вне вашего культурного контекста.
6)Меньше аббревиатур - их в IT столько, что уже некоторые имеют несколько значений
7)Не стесняйтесь приложить к документации глоссарий - как результат вышеперечисленного, уместно будет дать возможность проверить, что вы имеете в виду одно и то же, используя какие-то термины. #инструменты #конспект

Любопытное начало серии постов в блоге DEV.BIZ.OPS, которые открывает статья с провокационным заголовком: Developer Experience is Dead
Новые инструменты, как новые игрушки, - признается автор. Разбираться, строить, пробовать и составлять что-то новое из частей в природе разработчика (поэтому у многих есть коллекции лего). Теоретически, чем лучше инструменты, тем лучше результат, и вот все уже кинулись улучшать “опыт разработчика”. В 2021 на глобальном рынке инструментов для разработчиков было 1286 продуктов. И продаются они не сверху вниз, как было раньше, теперь решения все чаще даже в больших компаниях за теми, кто будет пользоваться покупкой в своей работе. Концепция более-менее устоялась и включает в себя:
- Опыт использования продукта (продуктивность, функциональность, UI/UX)
- Документация
- Онбординг - насколько легко начать использовать
- Поддержка
- Осведомленность - как узнают про инструмент (блоги, видео, гитхаб, вебинары и конференции)
- Сообщество
Все пункты важные, а все же то, как понимали DE уже не работает. Кривое управление командой не исправить идеальными инструментами, сколько бы на них не тратили бюджета. Нужны окружение, культура и процесс.
Продолжение во второй статье Enablers of Developer Flow, где Mark Birch делится опытом внедрения Stack Overflow Teams. Продукт любимый и популярный, вызвал большой энтузиам, но у некоторых не прижился и не из-за проблем самого инструмента, а из-за процессов вокруг разработки. Продуктивность, с точки зрения автора, это все, что “помогает коду возникнуть” и влияет на процесс - “активация” (Enablement) разработчика. На чем она основана:
- Развитие талантов
- Сотрудничество - как мы общаемся и вместе работаем
- Управление знаниями
- Планирование загрузки
- Показатели здоровья “активации” - как мы измеряем эффективность и продуктивность команд
- Культура - как мы встраиваем общие ценности и организационное видение.

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

Иллюстрация к ссылке к предыдущему конспекту

Community Metrics Matter by Eric Peterson

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

Одним из главных показателей автор считает NPS (Net promoter score). Это то самое “порекомендовали бы вы нашу компанию?” (годится и для работодателей, подробнее можно почитать тут).

C чего начать?

1. Member enrollment. На этом этапе мы получаем основную информацию о человеке и его интересах Можно периодически спрашивать, как у них дела.
2. Core offering participation. На этом этапе люди присоединяются к каким-то активностям в сообществе (например, посещают мероприятие). Здесь проверяем привлекательность “предложений” и путь в сообществе.
3. Partnership and affiliate offerings. На этом этапе мы пользуемся дополнительными партнерскими ресурсами (например, приглашаем спикеров из других сообществ). Здесь можно протестировать привлекательность контента и тем с небольшими затратами.
4. Member accomplishments. Те, кто достиг успеха с помощью сообщества/продукта могут вдохновить других и поощрить их достигнуть таких же результатов.
5. Platform and offering metrics. Измеряем все каналы, которыми пользуется сообщество - это ваша вовлеченность.

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

Послушала в понедельник вебинар Vanilla (делают софт для управления сообществами в том числе, с блекджеком и геймификацией) Developing Valuable Community-Based Advocacy Programs с Bill Johnston (ex Dell и Autodesk). Для понимания, надо сразу уточнить, что под “адвокатами” он имеет ввиду не сотрудников компании, а как раз участников сообщества, те самые 5% энтузиастов, на которых все держится. Джонстон проходится по истории вопроса (здравствуйте, Microsoft MVP), разбирает, что мотивирует энтузиастов и что демотивирует. Между прочим, среди демотиваторов по результатам опросов оказалась соревновательность. Вот так, каждый раз, когда маркетолог бездумно вводит геймификацию, где-то умирает единорог (неточная цитата). Прошлись по “привилегиям” (от виртуальных бейджей и реального мерча до закрытых мероприятий и доступа к менеджерам и продуктологам компании). Причем наравне с плюшками всегда нужно оговаривать правила (кто выбирает лучших и по каким критериям, нужно ли подтверждать статус и т.п.). Дальше там было инструментальное про то, как построить программу работы с энтузиастами. Самое интересное, традиционно “как измерить?”. Среди примеров мне понравились вот эти:
- “Покрытие” географическое или по отраслям
- Уровень “синьорности” участников
- Влияние программы на карьеру участников
- Как долго энтузиасты остаются в программе
Итого: смотреть тем, кто прямо сейчас озабочен вопросом, как привести в порядок работу с техническим сообществом; коротко, но при этом много хороших примеров. #communityrelations #конспект

Для разнообразия статья на русском: Как удержать разработчиков: оценка ситуации в сфере ИТ от JUG Ru Group. Российский деврел это на 95% история, связанная с рекрутингом и HR брендом, так что полезно знать, что происходит на рынке. И тут большинство людей из отрасли выглядят как та самая группа слепцов, ощупывающих слона и описывающих его по частям. У кого-то все вокруг уехали, у кого-то вернулись, у кого-то не собирались. Мой личный прогноз в данном случае "Никогда так не было, чтобы никак не было". Скорее всего, осенью будет видно, на каком мы нынче рынке. #тренды

Для интересующихся, сегодня и завтра https://deepdives.devrelcon.dev (бесплатно, на английском, начало в 16 по московскому времени). Первый день воркшопы и круглые столы, второй день - доклады. Я, как обычно, буду делать какие-то заметки на русском, но а)повешу их не сразу б)выберу доклады на свой вкус

А как будет "хабр" на заграничном? Где публиковать технические посты на английском

В статье Syndicating Developer Content как раз есть полезные советы и ссылочки.

Под синдикацией имеется в виду публикация на сторонних сайтах (по сравнению с разделом "блог" на сайте компании). Как делать это правильно:

1)Сначала публикуем на своем сайте
2) Через 2-10 дней Гугл поймет, кто тут оригинал и источник
3)Постим на сторонний сайт и указываем в параметрах canonical URL адрес статьи на вашем сайте. У продвинутых платформ это есть в настройках поста, для непродвинутых можно поставить ссылку в тексте. Если вы озабочены своим SEO, то нужны только продвинутые платформы [dzone и dev.to точно такое могут]
4)Продвигаем оба url

Рекомендованные сайты [комментарии мои]
Блоги на medium [как по мне их рекомендательная система слишком странная и без продвижения статью мало кто увидит]
dev.to [вроде неплохой технический ресурс, но надо приноровиться к формату]
Hashnode [не пробовала пока]
Cross Post App - приложение для автоматического распостинга на все три предыдущие площадки
dzone - для материалов про DevOps и backend [мой фаворит - лонгриды и почти хабр, много просмотров]
Hacker Noon - сайт с редакцией и строгим отбором постов, которые должны соответствовать требованиям [не пробовала]
The New Stack - тут тоже есть редакция, которая строго отбирает материал и принимает только оригинальные посты (то есть, про правила в начале забыли, если хотим сюда), уверяют, что их читатели CTO и всякие архитекторы [тоже не пробовала, надо будет рассмотреть]
Free Code Camp - снова всё круто и сурово, даже с рекомендациями по стилю, ориентировано на тех, кто учит и учится, много how to [тоже новое для меня]

Вот сколько всего полезного сразу. #инструменты #конспект

Developer Relations Career Insights From 7 Industry Leaders

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

1)Во многих компаниях это все еще один человек, который делает всё, но в последние несколько лет начали появляться специализации и вообще стало можно говорить о каком-то "карьерном пути" [то есть, мы идем почти в ногу]

2)Откуда приходят: от разработки до маркетинга и продаж [как уже выяснили в свое время, ситуация на русском рынке, где DevRel завязан на рекрутинг и HR-бренд, уникальна, если сравнивать с Европой и Америкой]

3)Дипломов нигде не выдают, но есть набор навыков, которые пригодятся специалисту с любым опытом: эмпатия, коммуникация, умение переключаться между задачами, обучаемость [никаких возражений]

4)Самое сложное в профессии: всё то, что называют среди плюсов(много разных задач, все постоянно меняется, много общения), а еще сложность демонстрации результатов бизнесу [место для срача по поводу метрик]

5)Как начать: все больше специалистов нужно на рынке [в начале 2021 так и у нас было, про 2022 будет понятнее к осени]. Главный совет начинающим: начните. Не дожидаясь изменения названия должности, напишите пост в блог, поучаствуйте в организации митапа и т.п. [Ну прямо с языка сняли! Лучший совет, я проверяла.]

#карьера #конспект

или вот еще пример правил от сообщества женщин-предпринимателей с объяснением, как и почему это работает #communityrelations

Community Guidelines: How to Write and Enforce Them
By Alex Angel, Alexandra Bowen, and Pam Magwaza

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

1)Мало просто иметь правила, им надо следовать и про них надо напоминать
2)Это ваша карта поведения в сообществе, они отражают ценности и показывают внешним людям, какую культуру вы построили внутри
3)Вот тут, если вы не понимаете, какие у сообщества цели, то будет трудно (миссия! миссия!)
4)Когда создаете правила, думайте не только о нарушителях, но и о тех, кто ведет себя именно так, как вам хотелось бы, чтобы поступало больше людей
5)Пишите проще, чтобы вас наверняка правильно поняли (и чем менее однородно сообщество, тем это важнее). И будьте краткими.
6)Не забудьте заранее пройтись по всем стейкхолдерам (знай и люби своих стейкхолдеров, да)
7)Правила должно быть легко найти, просто следовать и трудно игнорировать (почти готовый статус вконтакте)
8)Вы должны четко понимать, что будете делать, если правила нарушены
9)Чтобы правила менялись вместе с сообществом, не забывайте их иногда просматривать (хоть бы на ту же актуальность ссылок и инструментов)

От себя в качестве примера могу привести Apache Software Foundation Code of Conduct (чем удобны большие объединения, все инструменты тебе дают уже готовыми) #communityrelations #конспект

По ходу деврельских завтраков пособирали, что кто делает для Developer Relations и для HR-бренда. Что же дают наблюдения с расстояния примерно месяца? А то, что лучше всего работают а)прозрачность принимаемых решений и доступность первых лиц б)МНОГО РАБОТЫ. Второй пункт делает психотерапию по скайпу и сеансы дыхания как стоячих. #этосновабылопыт

и другие реалистичные обещания

Еще немного прогнозов: Developer-Led Landscape: Some 2022 Predictions от Tyler Jewell. Посмотрим, что порешает рыночек по мнению инвестора. #тренды
1)Будет меньше компаний, ориентированных на разработчиков, чем в 2021. На рынке идет волна укрупнений и пока что в выигрыше огромные платформы, а не Web3 и децентрализация (см прошлый пост про тренды)
2)Из-за этой же централизации инвесторы недосчитаются прибылей и будут покупать меньше компаний
3)ML для решения задач разработки станет немного популярнее, но все же не мейнстримом
И хотелось бы упростить написание кода, но будет масса вопросов по вменяемости результата, копирайту, лицензированию и безопасности, так что все подряд штуки вроде GitHub Copilot использовать не будут.
4)“supply chain security” взлетит быстрее Кубера
5)А вот аджайл пойдет на спад
20 лет на него молились, но удаленка показывает, что эмпатия и SRE дают лучший результат (вот тут хотелось бы ссылок на источники, но нет)
6)Управление данными станет новой категорией на рынке
ПО стало таким сложным, что человеку нелегко разобраться, появятся интеллектуалные системы, которые будут уведомлять заинтересованных об изменениях системы и давать подсказки.
7)Современный PaaS будет не так крут, как ожидалось. Произойдет некоторое удовлетворение потребности и кривая роста выйдет на плато.
8)Цены на газ для майнинга могут замедлить распространение блокчейна и Web3 #конспект

Колонка "Three themes for DevRel in 2022" от Мэтью Ревелла, основателя DevRelCon. Мэтью выбрал три тренда и пригласил трех специалистов поделиться мнением. Выжимка:
1)Офлайн вернется, но и онлайн никуда не денется: люди скучают по живому общению, осталось перепридумать его, чтобы не растерять плюсы, которые наконец научились получать из онлайна (спасибо, кэп)
2)Внутри профессии будет расти специализация
3)Web 3 компании и прочий блокчейн пришли как работодатели, но придут и в инструменты (а вот это самая свежая и пока еще не особо прозвучавшая в русском сообществе тема) #тренды #конспект

Вебинар "How to Steward Your Career in Community" от Кэрри Мелиссы Джонс (автор книги про сообщества брендов)

Самым полезным оказалось коротенькое вступление от Кэрри Мелиссы: достаточно редко ищут на стартовые позиции, это "узкое место" в профессии - людям трудно начать - поэтому, если у вас есть возможность стать ментором, сделайте это.
Работает ли это у нас? Кажется, что прямо сейчас, когда команды растут, как раз есть шанс у тех, кто хочет начать работу в деврел.

Дальше идет пример, как искала работу гостья (ну это больше про их рынок) и советы от карьерного консультанта (про поиск работы в принципе для тех, кто делает это нечасто).

#communityrelations #карьера #конспект

3 новинки и 2 "старинки" с книжной полки https://medium.com/@ks_romanova/5-%D0%BA%D0%BD%D0%B8%D0%B3-%D0%BF%D1%80%D0%BE-%D0%B4%D0%B5%D0%B2%D1%80%D0%B5%D0%BB-developer-relations-8b48a8e986d6 #книги

Ксения Романова | DevRel и другие коммуникации в IT pinned «Всем стоять! Это обязательство! Обязательство регулярно разгребать завалы полезных материалов по Developer Relations и писать хотя бы коротенькие аннотации и мысли по поводу. Аннотированные материалы в основном будут на английском. Кто читает? @ks_romanova…»

Всем стоять! Это обязательство! Обязательство регулярно разгребать завалы полезных материалов по Developer Relations и писать хотя бы коротенькие аннотации и мысли по поводу. Аннотированные материалы в основном будут на английском. Кто читает? @ks_romanova - организатор DevRel-завтраков и митапа в Петербурге Можно делиться своими полезными запасами, и их прочитаем. Ещё можно делиться своими аннотациями полезных статей/видео/материалов и мыслями по поводу. Мыслями обязательно, потому что склад ссылок у меня (и у всех коллег) уже есть.