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)После обновления пропустите пост через весь цикл продвижения контента.

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

Analyzing GitHub's Podcast Advertisement. Автор поста услышал рекламу Гитхаба (прилагается в блоге, по сути традиционное для того же ютуба "спасибо за спонсорство компании Х, она делает то-то) в своем любимом подкасте Pivot и решил покрутить эту тему.

Целевая аудитория
Чтобы сделать хорошую рекламу/интеграцию/и т.п. нужно А) хорошо понимать свою аудиторию Б)понимать, какого действия от них хотим.
Итак, Гитхаб решил, что слушатели подкаста могут стать новыми пользователями. Pivot входит в топ-20 тех подкастов и одна из ведущих известная тех-журналистка. Хотя автор не считает его хардкорно-техническим [хоть кто-то еще употребляет это слово, меня вот всю дорогу англоязычные редакторы лупят по рукам] по сравнению с тем же Stack Overflow podcast.
Так что, с одной стороны, можно засчитать это промахом, а можно попыткой расширить аудиторию, выйдя за пределы круга разработчиков, среди которых Гитхаб и так очень популярен, к тех-менеджерам, например.

Текст объявления
Вместо developers использовано более общее определение software people [так что, скорее всего догадка про расширение аудитории верна].
[Далее на основе текста автор делает вывод, что обращаются в основном к американской аудитории; отдельно подчеркивают ценность для рабочих процессов и DevOps, а не только для разработки]
Интересно, что CTA (call to action) - посетить страницу с тарифными планами, а не отдельную посадочную, и не зарегистрироваться бесплатно, нет, речь о платных сервисах.

В общем, автор считает, что в основном, конструкция рабочая, и оценивает ее 7/10. "Баллы" сняты за 90 миллионов разработчиков" (это в лучшем случае все емейлы, а не активные пользователи) и использование главной страницы вместо специальной посадочной.

[Со своей стороны скажу, что специальные страницы/ссылки конечно хороши для подсчета эффективности,а также для отслеживания дальнейшей судьбы пользователя, но в случае с аудио, вероятно, такой ход оправдан. Чтобы кто-то набрал более сложный url, чем https://github.com, откуда легко перейти на тарифы, пришлось бы пообещать существенную для пользователя выгоду. В случае с корпоративными тарифами, не факт, что придумать такую удалось бы. И нет, скидка вряд ли сработала бы, потому что время человек потратил бы свое, а деньги сэкономил корпоративные] #конспект

тот приятный момент, когда конспект конференции уже кто-то сделал: #devrelconf

На прошедшей Highload у меня практически не получалось публиковать заметки с докладов. Но у мсебя на ноуте я их делал, и сейчас собрал отчет и опубликовал https://mtsepkov.org/Highload-2022b. В отчете не только Highload, но и DevRelConf, которая была сразу после Highload.

В подкасте "Тысяча фичей" разработчик делится негативным опытом участия в митапе. Кратенько вредные советы "Как сделать плохой митап":
1)не проверять оборудование перед началом трансляции - подождут;
2)предоставить аудиторию самим себе во время вынужденных пауз - нормально сидим, молчим;
3)отбор контента и прогоны не нужны, все же люди умные, если вы их позвали;
4)если собираться, то на весь день, минимум 8 докладов, минимум; усидчивость - достоинство для разработчика;
5)не соблюдать временные рамки докладов - пусть говорят, сколько хотят;
6)модерация и ведущий не нужны, пусть те, кто программу не запомнил, тренируют память;
7)и пусть еще хотя бы один докладчик с похмелья придет;
8)и прямую рекламу добавьте хотя бы в одном докладе.
Вуаля, вы ужасны! #инструменты #конспект

Дельная выжимка из выступления на митапе в Ереване (видео)

Главред блогов Хабра и Medium Яндекса поделился видением работы с площадками

Несколько ключевых пунктов (как говорится, повторение – мать учения!)
🔸До нескольких часов может разработчик потратить на чтение документации для решения своей задачи или посетив конференцию. На Хабре же разработчик может задержать свое внимание достаточно долго, есть статья будет ему полезна.
🔸 Три фактора, влияющих на читаемость статьи: цельность, польза и история, в которой не надо бояться рассказывать о своих ошибках и признавать их.
🔸 Успешным пост можно считать тот, который стремится к рейтингу 100.
🔸 opensource – повышает рейтинг статьи и автора.
🔸 Medium – полезный ресурс для выхода на международную аудиторию, но и в России его тоже читают.
🔸 Medium еще более жесток к авторам в требованиях пользы.

Видео доклада здесь https://www.youtube.com/watch?v=dzo8aX_3CWM

Мне бы хотелось еще информации о том, как статьи продвигаются.

Если какую-то метрику можно "нагнать", именно это кто-нибудь и сделает. Tracking the Fake GitHub Star Black Market with Dagster, dbt and BigQuery рассказывает про то, как разоблачить накликанные звездочки на GitHub. Ну и про то, как их покупают тоже. Даже сделали контрольную закупку и специального спам-эксперта привлекли.
Фальшивки определяли по профилям, поставившим звезду:

- неактивные аккаунты с незаполненным профилем - тут ясно;
- аккаунты активные, но активные подозрительно регулярно, причем ходят толпой с такими же и лайкают одни проекты;
- аккаунты не очень подозрительные, но лайкнули много подозрительных репозиториев

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

В подкасте { между скобок } вышло интервью с человеком, который успел поработать и с технопиар, и с техпиар (если вы понимаете :))) - Михаилом Клюевым.
Весь подкаст интересный, но я хочу отдельно вытащить один кусочек сюда: https://youtu.be/3BEbs4C4So8?t=2102 Потому что это ППКС (олды тут? Подпишусь Под Каждым Словом на старо-жежешном). И говорить об этом нужно чаще: сначала создаем условия, потом уже хотим что-то от разработчиков. Здесь я бы даже “сервис” объединила с “социальной мотивацией”. Вместе это и есть DevRel-культура, о которой мы часто говорим. Суть организационной (и DevRel-) культуры именно в том, чтобы упростить людям желаемые действия (и усложнить нежелательные, конечно).

…Ну если есть какой-то блокер, нужно сначала понять причину. Когда мы поняли причину, мы эти блокеры снимаем. …там [в Avito] мы делали по сути внутренний сервис для разработчиков, который им помогает заниматься публичными выступлениями. Ключевая задача этого сервиса прежде всего снять геморрой с разработчика… Например, я сам плохо пишу. Мне нужна помощь специалиста по буквам и значит знакам препинания. У нас есть такой специалист. Напиши черновик, мы отдадим его редактору. Редактор превратит это в красивый текст, ты потом его проверишь, мы это опубликуем. Нету времени у тебя писать черновик, приди к нам. Мы тебе зададим вопросы и расшифруем. Или нужно тебе помочь: ты не знаешь как подготовиться к выступлению. Окей. У нас есть специалисты которые помогали другим людям проводить выступления ты с ними поработаешь и сможешь выступить. Тебе нужны картинки? Вот есть у нас человек, который делает картинки, и так далее и тому подобное…

Второй уровень [мотивации] - это общественное, точнее, она называется Social motivation, общественная мотивация. Это про то, что если человек этим занимается в компании, его компания должна поддерживать. Не должно быть ситуации, когда человек поехал выступать, вернулся в команду и там на делике не или на виклике ему говорят: Слушай, ну там пока ты выступал, мы закрывали задачи, значит ты там не доработал”. Вот такого быть не должно. Все должны понимать на всех уровнях, что это тоже работа. Это просто может быть не основная работа, шапочка, которую человек одел и пошел помогать компании, и у него должна быть поддержка коллег. #конспект