Developer Relations *

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

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

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

Привет, Хабр. Я работаю в Контуре ведущим разработчиком. 2 года назад я решил создать удобный, понятный и даже финансово приятный способ периодично благодарить своих коллег из разработки. И чтоб благодарили меня.

Что из этого вышло – читайте в статье.

Публичное выступление на митапе или конференции — не только возможность поделиться своими идеями и опытом, но и шанс заявить о себе. Но многие не знают, как подступиться к этой задаче. В статье опишем семь простых шагов, которые помогут вам подготовиться к выступлению и не закончить его с мыслями «больше никогда». В основе текста — советы консультанта IT-конференций Романа Поборчего, который подготовил к выступлениям уже более 2 000 разработчиков и инженеров.

Пока переносила видеозаписи докладов из архива в VK (ниже будет полный список докладов со ссылками на каждый), было время вспомнить, как всё началось. 12 декабря 2019 года прошел первый DevRel‑завтрак в Петербурге. Уже после карантина начали собираться москвичи* (подозреваю, что у нас единственное сообщество в порядке СПб‑Мск). На наших встречах познакомились многие люди, советовали друг другу подрядчиков (а также гостиницы и резиновые сапоги), кто‑то нашел работу и сотрудников, появились совместные проекты. Все это время мы встречались без регистрации, регламента, докладов и слайдов. Казалось, что от этого все успевают устать на работе. Но осенью 2022 года наш кружок все‑таки созрел для того, чтобы делиться опытом со сцены**. 16 сентября 2022 года мы встретились в Failover баре (тогда еще на Васильевском острове). И тем же вечером собрался за одним столом почти целиком программный комитет обновленного DevRel Conf, который и прошел уже 26 ноября 2022, но это совсем другая история***. Прием докладов на DevRel Conf 2024, кстати, открыт до 15 октября.

Нельзя сказать, что митап прямо‑таки региональный. У нас выступали спикеры из Москвы, Екатеринбурга и Казани. Большое спасибо Олегу, который приютил наш митап в Failover баре и поддерживает трансляции, а также всем добровольным помощникам, которые брали на себя промо и дизайн — от логотипа и обложек видео до создания карточной игры для вечеринки (было и такое).

Мы остаемся очень открытыми: к нам запросто может заглянуть на огонек дружественное сообщество разработчиков или придут в гости пиарщики, может приехать звезда и собрать сеньоров, а могут прийти wannabe деврелы (или все вместе).**** Приспособиться к аудитории помогает формат: не больше 20 минут на доклад и 15 минут на обсуждение.

Привет! Я Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure. В ИТ‑индустрии за 17 лет успел поадминистрировать, поразрабатывать и поруководить. Работал на многих позициях в разных компаниях — аутсорсных и продуктовых.

Я был тем, кого онбордят, кто онбордит, кто придумывает, как онбордить, и несёт ответственность за производительность команд и онбординга в том числе.

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

Делимся своим подходом к разработке матриц компетенций. Статья сможет помочь тимлидам, руководителям ИТ-компаний и HR понять, как разработать и использовать матрицу компетенций, если у вас большое технологическое разнообразие в компании.

Привет! На связи снова стрим Люди+. И мы продолжаем рассказывать про то, как составлять матрицы компетенций. Это вторая часть статьи, в которой поговорим про этапы работы над матрицами, их наполнением, поделимся примерами удачных и не очень описаний навыков. В первой части (ССЫЛКА) мы рассказали что такое матрица компетенций и зачем она нужна, а также про наш меню-подход и почему мы к нему пришли.

Представим ситуацию: вас позвали на подкаст. Вы обсудили материал с ведущим, подготовили тему, пришли и вам буквально не дали сказать и пары слов.

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

Привет, Хабр! Обман в играх — частая практика, и ничего плохого в ней нет. Именно уловки создателей игр обеспечивают интерес, острые эмоции и желание дойти до конца. Продюсер игр приоткроет нам завесу тайны: как нам обманывают и зачем это нужно, а, главное, почему от этого все участники процесса остаются в выигрыше.

Всем привет! Мы продолжаем расширять географию нашего исследования, чтобы углублять собственное понимание индустрии и помогать большему количеству соискателей и компаний. Сегодня расскажем о своих планах на рынок Беларуси и как вы можете помочь.

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

Речь сегодня пойдет о трёх форматах профессиональных IT‑комьюнити с историями их реализации из собственной практики DevRel.

Привет, меня зовут Наталия Макарова. Уже более 12 лет я работаю в области коммуникации с разработчиками (Developer Relations) и являюсь сооснователем и менеджером национальной рабочей группы по стандартизации языка C++. Взаимодействие и дружба с сообществами является одной из непосредственных и любимых задач. В настоящее время помогаю компаниям разрабатывать стратегии DevRel‑программ и веду свой телеграм‑канал MyDevRel.

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

Разработчики определённо имеют большой вес в компаниях, а значит, выстраивание продуктивных отношений с ними является важным приоритетом для ИТ-компаний. Однако отношения между DevRel-специалистами и более традиционными командами, такими как маркетинг, разработка, продукт и продажи, до сих пор чётко не определены.

Жёсткий график командировок и внешний характер их роли могут может привести к тому, что члены DevRel-команды почувствуют себя изолированными от других команд; но наиболее эффективные организации всё-таки стремятся создать прочные связи между DevRel и всеми остальными командами.

Всем привет! На Хабре есть множество статей про выгорание и его признаки, есть целые исследования IT на эту тему.

Повторяться не очень хочется и базу выдавать я не стану, ведь ее можно зайти почитать на википедии.

О чем же эта статья? Наверное, о том, как научиться любить…любить свою работу.

Вы можете сказать мне, что легко говорить, когда ты devrel – ходишь на конфы, участвуешь и организуешь веселые активности, но тут я возражу.

Что же такое devrel. На 40% ты комьюнити-менеджер, на 30% ивентщик, на 20% адвокат бренда и на 10% коуч. И вот бинго для скорого выгорания готово.

Привет! Стрим Люди+ снова на связи. Сегодня хотим поговорить о таком подходе, как DevRel-As-A-Service (далее – DAAS), и о том, как команда деврелов Росбанка трансформировала работу с ИТ-командами, ИТ-специалистами и гильдиями. Статья будет полезна начинающим и опытным деврелам, а также всем тем, кто планирует применять у себя DAAS подход.

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

Это будет короткий рассказ о том, что даже в банке можно реализовать классные и нестандартные внешние активности. Скажу больше, это мероприятие изменило в целом мой подход к организации событий.

Привет, хаброжители! Принесли вам четыре логические задачки, которые решали участники ИТ-конференций на стенде РСХБ.цифра. Для их решения необязательно иметь за плечами многолетний опыт в ИТ или быть Senior+ в своей области — достаточно знать математику на базовом уровне. От вас решение — от нас подарки первым, кто дал правильный ответ.

Всем привет! Я Анжелика, работаю ведущим инженером в РСХБ‑Интех. В последнее время все чаще задумываюсь про медийность и важность ее развития для ИТ‑специалистов. Поговорим про это в сегодняшнем материале.

Работа в крупных компаниях — это не только ДМС и корпоративный мерч. Это большой поток информации, связанный и не очень с дизайном.

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

Помимо информации вам нужен большой инструментарий: Figma, Framer, Miro, а ещё дизайн-система.

Я лид дизайн-системы. В статье расскажу, как мы наладили диалог с дизайнерами в 100 продуктовых командах. Читайте, если вы уже заняты в продукте, или хотите работать в корпорации и не знаете, чего ждать. Также будет интересно всем, кто хоть раз пытался собрать комьюнити или встречу более чем на три участника.

Пришло время переосмыслить «местоположение» отдела по взаимодействию с разработчиками (DevRel) в структуре организации.

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

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

Возможно, потому что деврела не существует. Ты бьёшься об стену, дописываешь к деврелу “-менеджер” или “-специалист”, а люди всё равно говорят, что ты деврел.

А возможно, потому что эта сфера (а значит и твоя работа) только оформляется и облекается в слова, поэтому количество людей понимающих зачем ты существуешь и что делаешь — катастрофически мало.

Об этом и статья.