DevRel skladно говорит

Принесла вам ложку дегтя в видосике 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, но и если интересно делать вещи определенного масштаба или в конкретной области. Обычно те же разработчики, что у нас, что на Западе кочуют годами между пятью‑десятью банками или телекомами. Чтобы сделать шаг в сторону, нужна изрядная смелость]

Продолжаем читать статью Jeremy Meiss Moving Developer Relations Forward в пяти частях, части 1-3 в предыдущем посте. Часть 4 - Developer Relations and the customer journey В этой части автор напоминает нам, что DevRel — это центр затрат, а не генерации прибыли. Так что именно он в начале списка “на чем бы можно было сэкономить в эти непростые времена”. И свою полезность лучше доказывать раньше, чем дело дойдет до этого самого списка. Вот зачем мы задавали вопросы? А вот зачем: 1)Показали себя широко в компании и завели полезные связи; 2)Выяснили потребности и восприятие DevRel до того, как расхождения могли бы вызвать проблемы; 3)Узнали про цели и KPI и кто как отчитывается. Это помогает занять свое место в организации и обосновать ценность. И место это нужно искать внутри Developer Journey (Пути разработчика). В смысле, узнайте, как его видят в компании сейчас (искать надо где-то между маркетингом и продуктами обычно), найдите там свои активности и перестройте отчетность. Каждый пункт подробно развернут. Рекомендую читать целиком, там всё нужное, включая DevRel Qualified Leads мои любименькие. Это, конечно, про классический DevRel, но и на HR-бренд можно переложить, просто карта нужна другая - employee journey map. Часть 5 — Positioning DevRel as a resource within your company Раз вы про отношения с важной целевой аудиторией, значит, — делает вывод автор, — будьте ресурсом для всех, кому он нужен. Даже, — смело замахивается он, — для рекрутинга! Например, продажам нужны вебинары и воркшопы — отлично, DevRel может помочь. Маркетингу нужны истории успешного использования продукта? [о да! моя любимая история: и вот два инженера из компании *** нахваливают продукт на нашей онлайн-конференции, а только представьте, куда бы послал нас их маркетинг, если бы мы попытались согласовать кейс обычным путем…]. А также можно использовать связи специалиста по DevRel с коллегами или разработчиками из других компаний для каких-то совместных активностей. В общем, мы не продажи и маркетинг, но мы — чертовски полезный ресурс. В бизнесе ты или делаешь штуки, или продаешь штуки. Выстраивать свои цели нужно соответственно (или ты без работы). Если никто не пользуется продуктом, — ты без работы. Пришло время относиться к этому по-взрослому [to grow the fuck up, чтобы быть точными] и показывать бизнесу свою ценность там, где она есть, не дожидаясь вопросов “Так что вы делаете?” и “А какой от вас ROI?”. А кто будет делать вид, что далек от бизнеса, добьется своего, и уже бизнес дистанцируется от DevRel-команды. Ну как вам, откликается? 🔥 если да.

В англоязычном 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? Далее автор приводит очень разумные вопросы, которые следует задать маркетингу, продажам, продактам и другим командам. Вот этот раздел стоит прочитать целиком, если вы планируете сменить работу. Продолжение следует

ТГ-каналы про 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-функция в компании или отдельном направлении? Например, чтобы “штаны не порвать”, широко шагая в своем планировании через ступеньку. В статье The Developer Relations Capability Maturity Model Jordan Violet сформулировал путь, который проходит DevRel, таким образом: 1)Неорганизованные усилия, большая вовлеченность конкретных людей, часто в свободное время: на этом этапе жизненно важно найти сторонников в менеджменте, которые могут сказать “да, мы будем заниматься DevRel” (то есть, поручиться перед остальным руководством, что в этом есть смысл для компании) 2)Простые, но достижимые цели, 1-3 человека в команде: выбираем легко достижимые цели, чтобы доказать свою полезность 3)Сформулированы цели и задачи DevRel program [интересно, что у нас кальки с этой концепции никто не использует], бизнес признает пользу от вас: на этом этапе обычно появляется возможность расширить команду, тут важно не забыть периодически синхронизироваться с целями компании 4)На этом уровне уже запущены все ключевые проекты, но они могут как работать, так и стухнуть: если вы добрались до этого уровня, значит, прошло определенное время, но это не повод почивать на лаврах [просто вы ближе к пенсии на несколько лет мухаха, от описания автора возникает ощущение легкой заболоченности, что же, возможно, что сотрудники уже устали гореть, и да, это момент, когда команда может поменяться] 5)Ценность отношений с разработчиками понятна, а усилия можно измерить [вообще там написано “измерить количественно”, но я бы сказала просто измерить]: пик развития. главное продолжать делать всякие новые вещи на этом вашем новом уровне. В каждом пункте Джордан приводит примеры, как это было в его карьере. И мне кажется, путь не особенно ‘экзотический. Я бы все-таки сказала, что это не лестница, а колесо, и внешние обстоятельства еще дадут вам пинка. Например, весь мир сядет дома и выйдет в онлайн, или поменяется рынок, на котором работает компания, сама компания изменится так, что поменяются бизнес-цели, или прорыв произойдет в технологии. И тогда, на этапе 6 вам снова придется пройти версию этапа 1, только старые достижения будут мешать сосредоточиться на новых вводных. В общем, скорее пост — хороший повод для размышлений, но не прямо “бери и пользуйся”.

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

В симпатичном мне блоге 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, в которых люди указали, что владеют именно вашим инструментом в блоке “навыки”.]

Подборка каналов про digital от комьюнити «Прости, что голосом» DNative — блог Ткачука про SMM — актуальные новости из мира социальных сетей Русский маркетинг — подборка новостей из мира маркетинга, не только диджитал HotDigital — свежие мировые диджитал кейсы seen — авторские подборки интересных кейсов Кириллица.дизайн — всё про веб-дизайн с кириллицей Полезный Парфун — кейсы и новости для маркетологов и топ-менеджеров от Алексея Парфуна Кабачковая икра по акции — подборка кейсов HR4PR — исследования и вакансии с уклоном в пиар The Content is The Queen — канал консультанта Линор Горалик о контенте, стратегии и коммуникациях Кинжал — про софтскилс, как жить эту жизнь и работать эту работу без насилия над собой (у них классные картинки!) Жукова, ты опять про работу... — менеджер по развитию бренда работодателя в диджитал агентстве рассказывает, как строить карьеру, пока читаешь книжки и нетворкаешь с классными ребятами

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

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

Google объявил, что скоро добавит в результаты поиска новый блок, составленный из мнений на пользовательских форумах и т.п. Называется “Перспективы”. Дескать, узнайте сразу от людей, которые понимают в Java или вязании крючком. Как именно будут отбираться и ранжироваться результаты, пока не известно. Community-менеджеры и обрадовались, и напряглись сразу. CMX собрали подборку мнений. Аргументы “за” начинаются с того, что многие люди уже годами сразу начинают поиск с Reddit, потому что поисковик выдает оптимизированную ерунду (и наконец-то они это поняли). Есть некие оптимистичные надежды, что вот теперь все оценят, насколько важны настоящие отношения и кто в команде сидит на “золотой жиле” SEO. Среди аргументов “против” то, что многие очень живые сообщества тусуются в дискорде и слаке, которые не индексируются поисковиками. И, главное, насколько пострадает то самое живое общение, когда компании примутся оптимизировать его плоды, вероятно, используя в качестве комментатора нейросети. [Главная проблема для читателя, это то, что ИИ не интеллект, а генеративная модель, которая выдает текст, а не мысль.] Нет уверенности, что поисковик распознает плоды труда своего искусственного родственника. И таким образом пользователю будет выдана чушь, а форумы будут покрыты этой самой чушью в три слоя. Лично мне кажется, что стремление людей получить ответ на тот вопрос, который они задали, а не оптимизированный сиропчик от компаний про их продукты, недооценивают. Если Reddit “испортится”, будут начинать поиски с какой-то новой точки. Чтобы немного преисполнится реализма, достаточно зайти в комментарии в каком-нибудь крупном телеграмм-канале. Буквально на этой неделе пошло тестирование ботов, которые генерируют резюме по основному посту с добавлением “очень интересно” и подобных подходящих почти под любой случай довесков. Пользователей бесит. #community

Коммуникаторы: обсуждают, что некоторые шутки, которые были классными 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”. Пожалуй, уроки пиарщиков и деврелам подойдут. Сделала конспект (чего не сделаешь, чтобы убрать книгу обратно в шкаф уже).