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

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

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 #конспект

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

Developer Relations Career Insights From 7 Industry Leaders

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

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

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

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

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

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

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

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

В статье 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 [тоже новое для меня]

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

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

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

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

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 #метрики #конспект

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

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

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

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

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

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

Michael Hall "Stop Measuring Community Engagement"

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

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

[Было бы чуточку более убедительно с примерами правильных метрик, мне кажется, но есть, о чем подумать, например, есть ли среди того, что вы измеряете, хоть что-то про ваши ценности.]
#communityrelations #метрики #конспект

Важная закладка:

1. Как придумать тему технического доклада
2. Как сделать интересный технический доклад

Две статьи, написанные программистом для программистов, где собраны полезные советы для начинающих докладчиков. Можно читать самим или переслать тем, кому сейчас актуально.

Принесла вам в клювике конспект: https://medium.com/@ks_romanova/%D0%B1%D1%8B%D1%81%D1%82%D1%80%D0%BE%D0%B7%D0%B0%D0%BC%D0%B5%D1%82%D0%BA%D0%B8-%D1%81-devrelx-summit-2022-b574db50d3b2

Refresh Blog Posts The Right Way – 3 Technical Case Studies by Karl Hughes
https://draft.dev/learn/refreshing-blog-posts

Недавно на нашем складе была заметка про устаревшие посты (точнее, авторов, которые уже покинули компанию), продолжим тему. Итак, освежаем старые посты.

Зачем?
1) Это легкий способ улучшить свой результат в выдаче гугла. Небось не думали про SEO, когда писали посты, вот теперь можно пройтись, сделать всё по красоте и сразу будет заметен эффект (сами-то посты уже давно тут и вызывают доверие у гугла).
2) Техническая информация со временем устаревает. Хотя, если у вас много тьюториалов, тут, конечно, не набегаешься [но можно проверить, какие самые посещаемые и обновить только их, и да, дальше это есть]

Примеры из жизни:
1)выходим из гугл пенальти: удаляем некачественный контент, сомнительные ссылки, обновляем устаревшие посты. Вот как это сработало https://alphainvestors.com/case-study/reviving-a-penalized-site-to-6400-visits-per-month-case-study/

2)оптимизируем ключевые слова: смотрим, куда "приземляются" посетители, приводим эти посты в порядок с точки зрения SEO и делаем еще похожих, чтобы поисковики убедились, какой вы надежный источник по теме.
Как было сделано: https://www.pkwydigital.com/case-study-update-old-blog-posts/

Пять способов освежить посты:
1)Убрать лишнее (короткие посты, посты на темы, на которые вы больше не планируете писать, посты, которые неинтересны вашей аудитории, посты, которые устарели технологически). Так у вас остается больше качественного с точки зрения гугла контента;
2)Смерджить похожее (так контент становится более уникальным и получает больше внимания);
3)Обновить старые посты, которые все еще получают много трафика (скриншоты и видео с правильными alt, технические детали, которые устарели, мета-описание и ключевые слова);
4)Линькуйте между собой популярные посты [вот прямо остановитесь и перечитайте совет еще раз, легкий способ получить больше читателей, которым чуть ли не каждый второй блог пренебрегает];
5)После обновления пропустите пост через весь цикл продвижения контента.

Ну и результаты со скринами из гугл-аналитики к статье прилагаются. Это как раз третий кейс из заголовка. #инструменты #конспект