Вчера прошла встреча всех заинтересованных в Saint HighLoad++ с презентацией «конференций развития». Вот summary того, что говорили представители «Онтико» и ПК:
1) Знания стали commodity, их целый Инет с GPT в придачу. НО: по-прежнему есть запрос на решение конкретных проблем в конкретной ИТ-компании.
2) Контекст вышел на первое место, решать приходится контекстозависимые задачи («а у меня при этом маленький бюджет, строгие требования к безопасности и 20-летнее legacy»).
3) Кризис и 4-я промышленная революция (ИИ) диктуют условия. Важно не просто «сделать как-то», а сделать больше, дешевле и быстрее.
4) Концепция «конференций развития» должна ответить на эти вызовы (1-3). Больше форматов, стабильнее контакт с аудиторией, больше практики и нетворкинга должны привести к тому, что люди будут видеть ценность в обновлённых конференциях, ходить на них и если не приносить оттуда гарантированные решения (этого никто не обещает), то хотя бы нащупывать правильный подход к снаряду.
5) Участник получает на старте некий персонализированный трек развития, куда ему сходить. Доклады, МК, TED Talks, фейл-митапы - подразумевается, что пройдя по треку, он исследует индустрию, пообщается с комьюнити и сумеет по-новому взглянуть на проблему, с которой пришёл.
6) Ориентация на практику: знания, если была хоть какая-то практика их применения, усваиваются лучше. На конференционные мастер-классы у «Онтико» в прошлом был ажиотажный спрос, поэтому интерактивных форматов на конференциях теперь будет больше (>10 разных разностей, включая Case Clinic, Case Practicum и т.д.).
7) Применение решения в проде теперь не обязательное условие принятия доклада. Подходы тоже считаются годным материалом (при условии, что спикер сделал homework и протестировал их достаточно, и может подать результаты этого тестирования в доступной и увлекательной форме).
8) У мастер-классов и других интерактивных форматов теперь будет приоритет при отборе в программу. Интерактив будут брать в первую очередь, традиционный лекционный формат во вторую и тоже докручивать до «докладов 2.0», вписывающихся в концепцию.
9) У smalltech-компаний появилось право голоса в ПК, будут отбирать доклады не только требующие гигантских ресурсов и прорывные для отрасли, но и решения для общих болей, хорошие добротные best practices, которые можно будет применить у себя не гигантам.
10) Воспроизводимость и практическая польза в противовес «а мы сделали космолёт для всего большого WB/Yandex/Сбера» должны стать новой нормой. Не ярмарка тщеславия вида «посмотреть как у больших и вздохнуть от отсутствия ресурсов», а «пойти и применить в своём не очень-то highload’ном хозяйстве».
Будем думать, как скорректировать заявки с учётом новых реалий. Вызов, но интересно)
1) Знания стали commodity, их целый Инет с GPT в придачу. НО: по-прежнему есть запрос на решение конкретных проблем в конкретной ИТ-компании.
2) Контекст вышел на первое место, решать приходится контекстозависимые задачи («а у меня при этом маленький бюджет, строгие требования к безопасности и 20-летнее legacy»).
3) Кризис и 4-я промышленная революция (ИИ) диктуют условия. Важно не просто «сделать как-то», а сделать больше, дешевле и быстрее.
4) Концепция «конференций развития» должна ответить на эти вызовы (1-3). Больше форматов, стабильнее контакт с аудиторией, больше практики и нетворкинга должны привести к тому, что люди будут видеть ценность в обновлённых конференциях, ходить на них и если не приносить оттуда гарантированные решения (этого никто не обещает), то хотя бы нащупывать правильный подход к снаряду.
5) Участник получает на старте некий персонализированный трек развития, куда ему сходить. Доклады, МК, TED Talks, фейл-митапы - подразумевается, что пройдя по треку, он исследует индустрию, пообщается с комьюнити и сумеет по-новому взглянуть на проблему, с которой пришёл.
6) Ориентация на практику: знания, если была хоть какая-то практика их применения, усваиваются лучше. На конференционные мастер-классы у «Онтико» в прошлом был ажиотажный спрос, поэтому интерактивных форматов на конференциях теперь будет больше (>10 разных разностей, включая Case Clinic, Case Practicum и т.д.).
7) Применение решения в проде теперь не обязательное условие принятия доклада. Подходы тоже считаются годным материалом (при условии, что спикер сделал homework и протестировал их достаточно, и может подать результаты этого тестирования в доступной и увлекательной форме).
8) У мастер-классов и других интерактивных форматов теперь будет приоритет при отборе в программу. Интерактив будут брать в первую очередь, традиционный лекционный формат во вторую и тоже докручивать до «докладов 2.0», вписывающихся в концепцию.
9) У smalltech-компаний появилось право голоса в ПК, будут отбирать доклады не только требующие гигантских ресурсов и прорывные для отрасли, но и решения для общих болей, хорошие добротные best practices, которые можно будет применить у себя не гигантам.
10) Воспроизводимость и практическая польза в противовес «а мы сделали космолёт для всего большого WB/Yandex/Сбера» должны стать новой нормой. Не ярмарка тщеславия вида «посмотреть как у больших и вздохнуть от отсутствия ресурсов», а «пойти и применить в своём не очень-то highload’ном хозяйстве».
Будем думать, как скорректировать заявки с учётом новых реалий. Вызов, но интересно)
❤3
KPI vs душевность в DevRel
В ноябре 2025-го мы с DevRel NN делали круглый стол про профессию DevRel глазами разных спецов.
(Конспект — в чатике сообщества.)
Там прозвучала ценная мысль:
И в этом противоречие.
Деньги тебе платят за выполнение целевых показателей.
А где тогда «душа» — и как всё это совместить?
Как с этим живут в bigtech
В больших компаниях ответ обычно один — верные ожидания на старте.
Знакомство проходит сердечно, но на нём DevRel показывает ссылку на wiki и task tracker, где есть
📍 согласованные с руководством приоритеты;
📍 SLA для разных типов инициатив;
📍 текущий бэклог.
Для “вотпрямщас” болей оcтаётся emergency-кнопка.
Кто что получает:
DevRel — шанс не выгореть и немного сократить поток входящих (личка всё равно будет полной).
Разработчик — чёткие правила игры, формочки под описание инициатив и понятное «время на подождать».
Когда команд десятки, а людей — тысячи, иначе не выжить.
Но и здесь можно (и нужно) закладывать душевность:
в формулировки форм, в тон FAQ, в каждый личный контакт — делать его приятным и по-хорошему запоминающимся.
Если компания небольшая
Здесь на немногих активных «звёздах» всё держится, и их надо сохранять всеми силами.
Поэтому 1-1 созвон и «покрутить идею» часто лучшая реакция на их предложение.
Частые эффекты от 1-1:
📍из «болевого» фидбека вырастает более гуманный процесс;
📍у «бесполезной» активности вдруг находится бизнес-измерение.
Если инициатива есть, но поддержки нет — человек уйдёт туда, где она появится.
Поэтому сперва стоит поискать бизнес-выгоду и поддержать.
Отказ без попытки найти решение точно не гуд.
Про боли и откровенность
В bigtech обычно есть:
📍понятные политики и гайдлайны
📍маршруты эскалации от тимлида и HR BP до C-level,
📍анонимные ящики для жалоб и предложений (моё любимое!).
В компаниях поменьше часто всё держится на глазомере деврела - его такте, выдержке и умении не навредить.
Что стоит помнить:
📍эскалация — про помощь, а не про доносы;
📍лучше прийти к руководству с возможным решением,
чем просто «настучать», что имярек X в отделе тимлида Y недоволен Z.
Эффект "душевности"
Душевность - это безопасная среда, в которой расцветают инициативы (выгоду от неё всерьёз считают разные State of Workplace Empathy и другие исследования).
А для деврела «лишняя» эмпатия, очередное above and beyond в личной коммуникации порой оборачиваются рекомендацией на новое место или проект. Ну, и карма хорошая)
Так что остаёмся душевными, где бы мы ни были.
Всё не зря.
А душных и так хватает 🙂
В ноябре 2025-го мы с DevRel NN делали круглый стол про профессию DevRel глазами разных спецов.
(Конспект — в чатике сообщества.)
Там прозвучала ценная мысль:
Разработчику плевать на твои KPI.
Он ищет эмпатии и поддержки.
«Правильный DevRel» — это внимание к его инициативам и болям.
И в этом противоречие.
Деньги тебе платят за выполнение целевых показателей.
А где тогда «душа» — и как всё это совместить?
Как с этим живут в bigtech
В больших компаниях ответ обычно один — верные ожидания на старте.
Знакомство проходит сердечно, но на нём DevRel показывает ссылку на wiki и task tracker, где есть
📍 согласованные с руководством приоритеты;
📍 SLA для разных типов инициатив;
📍 текущий бэклог.
Для “вотпрямщас” болей оcтаётся emergency-кнопка.
Кто что получает:
DevRel — шанс не выгореть и немного сократить поток входящих (личка всё равно будет полной).
Разработчик — чёткие правила игры, формочки под описание инициатив и понятное «время на подождать».
Когда команд десятки, а людей — тысячи, иначе не выжить.
Но и здесь можно (и нужно) закладывать душевность:
в формулировки форм, в тон FAQ, в каждый личный контакт — делать его приятным и по-хорошему запоминающимся.
Если компания небольшая
Здесь на немногих активных «звёздах» всё держится, и их надо сохранять всеми силами.
Поэтому 1-1 созвон и «покрутить идею» часто лучшая реакция на их предложение.
Частые эффекты от 1-1:
📍из «болевого» фидбека вырастает более гуманный процесс;
📍у «бесполезной» активности вдруг находится бизнес-измерение.
Если инициатива есть, но поддержки нет — человек уйдёт туда, где она появится.
Поэтому сперва стоит поискать бизнес-выгоду и поддержать.
Отказ без попытки найти решение точно не гуд.
Про боли и откровенность
В bigtech обычно есть:
📍понятные политики и гайдлайны
📍маршруты эскалации от тимлида и HR BP до C-level,
📍анонимные ящики для жалоб и предложений (моё любимое!).
В компаниях поменьше часто всё держится на глазомере деврела - его такте, выдержке и умении не навредить.
Что стоит помнить:
📍эскалация — про помощь, а не про доносы;
📍лучше прийти к руководству с возможным решением,
чем просто «настучать», что имярек X в отделе тимлида Y недоволен Z.
Эффект "душевности"
Душевность - это безопасная среда, в которой расцветают инициативы (выгоду от неё всерьёз считают разные State of Workplace Empathy и другие исследования).
А для деврела «лишняя» эмпатия, очередное above and beyond в личной коммуникации порой оборачиваются рекомендацией на новое место или проект. Ну, и карма хорошая)
Так что остаёмся душевными, где бы мы ни были.
Всё не зря.
А душных и так хватает 🙂
Telegram
Anastasia Rostova in DevRel NN
А кто не успел лично побывать на нашем круглом столе, тем достаётся #конспект.
@efeiya_grassie рассказала про содержимое DevRel-курсов, которое до некоторой степени отражает реальную сумму знаний профессии. Помимо «трёх китов» DevRel (сообщество, контент…
@efeiya_grassie рассказала про содержимое DevRel-курсов, которое до некоторой степени отражает реальную сумму знаний профессии. Помимо «трёх китов» DevRel (сообщество, контент…
❤4
Анонс: DevRel-митап № 2 в Нижнем Новгороде с сообществом smalltech
Начинаем потихоньку выполнять обещания декабря. На неделе с 16 по 20 марта планируем провести offline митап с «true деврелами»™ из столиц. Митап организуют сообщество smalltech DevRel (деврелы из небольших организаций) и сообщество DevRel NN.
Почему smalltech?
Часто небольшие компании базируются именно в регионах. Проблемы столичных smalltech и региональных специалистов с DevRel-функцией примерно одинаковы - и тем, и другим надо достигать амбициозных целей с минимальными затратами, делать «дёшево и сердито», чтобы все стейкхолдеры остались довольны. Так что в этот раз говорим не про ресурсы и масштабы bigtech-компаний, а про то, что нам легко внедрить своими силами, но при этом красиво и достойно.
Что обсудим?
Полезные кейсы и доступные / бесплатные инструменты, которые прямо завтра можно применить у себя. Обязательно подискутируем про ИИ в DevRel, как и планировали в прошлом году.
Кто спикеры и про что доклады?
Дина Измайлова, DevRel DatsTeam
Тема: "DatsTechTV: платформа для бесплатной записи и профессионального монтажа видео докладов"
Марина Степанова, DevRel ГНИВЦ
Тема: "Презентации для спикеров: быстрая ИИ-сборка визуальных материалов в конференционном качестве"
Анна Кононова, DevRel Петрович-ТЕХ
Тема: "Подручный критик: продуктивный брейншторм и вычитка технического контента с обученным промптом-инженером"
Когда откроется регистрация:
Регистрацию сделаем сразу после утверждения даты площадкой, новость появится в этом канале, в чате DevRel NN, каналах спикеров и в чате smalltech - где-то да увидите анонс со ссылкой!
Начинаем потихоньку выполнять обещания декабря. На неделе с 16 по 20 марта планируем провести offline митап с «true деврелами»™ из столиц. Митап организуют сообщество smalltech DevRel (деврелы из небольших организаций) и сообщество DevRel NN.
Почему smalltech?
Часто небольшие компании базируются именно в регионах. Проблемы столичных smalltech и региональных специалистов с DevRel-функцией примерно одинаковы - и тем, и другим надо достигать амбициозных целей с минимальными затратами, делать «дёшево и сердито», чтобы все стейкхолдеры остались довольны. Так что в этот раз говорим не про ресурсы и масштабы bigtech-компаний, а про то, что нам легко внедрить своими силами, но при этом красиво и достойно.
Что обсудим?
Полезные кейсы и доступные / бесплатные инструменты, которые прямо завтра можно применить у себя. Обязательно подискутируем про ИИ в DevRel, как и планировали в прошлом году.
Кто спикеры и про что доклады?
Дина Измайлова, DevRel DatsTeam
Тема: "DatsTechTV: платформа для бесплатной записи и профессионального монтажа видео докладов"
Марина Степанова, DevRel ГНИВЦ
Тема: "Презентации для спикеров: быстрая ИИ-сборка визуальных материалов в конференционном качестве"
Анна Кононова, DevRel Петрович-ТЕХ
Тема: "Подручный критик: продуктивный брейншторм и вычитка технического контента с обученным промптом-инженером"
Когда откроется регистрация:
Регистрацию сделаем сразу после утверждения даты площадкой, новость появится в этом канале, в чате DevRel NN, каналах спикеров и в чате smalltech - где-то да увидите анонс со ссылкой!
Огонь
Smalltech DevRel — Галерея активных сообществ.
Smalltech - все в ИТ, кто не bigtech. А нас, между тем, 200к компаний на Россию!
Создаем инфополе для причастных, обмениваемся опытом выживания и решений. Делаем смоллтех привлекательным для наших разработчиков и продвигаем бренды наших компаний совместными…
Создаем инфополе для причастных, обмениваемся опытом выживания и решений. Делаем смоллтех привлекательным для наших разработчиков и продвигаем бренды наших компаний совместными…
🔥2🤔1
Community-движ: как его делать и не выгореть
Разные community-ивенты я собирала ещё тогда, когда и слов-то таких не знала. Полжизни, с 2006 года, провожу встречи поэтических клубов в Нижнем - сначала был «Феникс», теперь вот DRC NN с прикольными концертами за кофе (заходите!). Когда в 2024 году мы с Ксюшей Романовой и Никитой Соболевым провели первый в городе DevRel-завтрак, было очевидно, что инициативу надо продолжать. Поначалу я была в панике: это ж регулярно! Это ж каждый месяц!
Сейчас DevRel-ужинам в НиНо уже полтора года, и у нас даже есть планы на будущее.
Что помогает и мотивирует собирать регулярные движухи?
Принцип «по мере сил». Всё же community-движ по собственной инициативе - это своего рода стартап в свободное от работы время. Стараюсь делать столько, сколько в радость и с пониманием своих ограничений и текущих обстоятельств. Пусть немного, но регулярно.
Готовность к критике. Альтернативные мнения разного качества будут всегда. К каким-то надо прислушаться, кому-то предложить сотрудничество, у кого-то перенять опыт. Но также будут и просто люди, которым хочется уровень сервиса выше при нуле вложений. В таких случаях помогает мой давний опыт в саппорте онлайн-игры в соцсетях: понять и простить)
Открытость к инициативам. Нижегородские ужины не сразу стали тематическими - опытным путём мы выяснили, что беседы на профессиональные темы интереснее простых посиделок. Та же история со сменой ресторанов - сообщество решило, что так прикольнее - ну, окей)
Желание чему-то научиться. Очень крутая мотивация собирать митапы -- это собственное стремление к знаниям. Особенно когда спрашивают, о чём бы рассказать, и ты имеешь шанс сделать программу интересной не только для сообщества, но и для себя любимой.
Безопасное окружение. Очень круто тестировать новые идеи в среде, где можно мгновенно получить обратную связь - часто бывает, что сначала спросить дешевле, чем набивать собственные шишки на том, что коллеги уже успели побороть.
Социальная жизнь. Выйти в люди, оторвавшись, наконец, от монитора - приятная роскошь для удалёнщика с ограниченным кругом общения. Да и не удалёнщикам выход из привычного колеса «работа-дом» не помешает.
Скорее всего, я что-то забыла — буду рада, если вы добавите своих мотиваций в комментах)
Разные community-ивенты я собирала ещё тогда, когда и слов-то таких не знала. Полжизни, с 2006 года, провожу встречи поэтических клубов в Нижнем - сначала был «Феникс», теперь вот DRC NN с прикольными концертами за кофе (заходите!). Когда в 2024 году мы с Ксюшей Романовой и Никитой Соболевым провели первый в городе DevRel-завтрак, было очевидно, что инициативу надо продолжать. Поначалу я была в панике: это ж регулярно! Это ж каждый месяц!
Сейчас DevRel-ужинам в НиНо уже полтора года, и у нас даже есть планы на будущее.
Что помогает и мотивирует собирать регулярные движухи?
Принцип «по мере сил». Всё же community-движ по собственной инициативе - это своего рода стартап в свободное от работы время. Стараюсь делать столько, сколько в радость и с пониманием своих ограничений и текущих обстоятельств. Пусть немного, но регулярно.
Готовность к критике. Альтернативные мнения разного качества будут всегда. К каким-то надо прислушаться, кому-то предложить сотрудничество, у кого-то перенять опыт. Но также будут и просто люди, которым хочется уровень сервиса выше при нуле вложений. В таких случаях помогает мой давний опыт в саппорте онлайн-игры в соцсетях: понять и простить)
Открытость к инициативам. Нижегородские ужины не сразу стали тематическими - опытным путём мы выяснили, что беседы на профессиональные темы интереснее простых посиделок. Та же история со сменой ресторанов - сообщество решило, что так прикольнее - ну, окей)
Желание чему-то научиться. Очень крутая мотивация собирать митапы -- это собственное стремление к знаниям. Особенно когда спрашивают, о чём бы рассказать, и ты имеешь шанс сделать программу интересной не только для сообщества, но и для себя любимой.
Безопасное окружение. Очень круто тестировать новые идеи в среде, где можно мгновенно получить обратную связь - часто бывает, что сначала спросить дешевле, чем набивать собственные шишки на том, что коллеги уже успели побороть.
Социальная жизнь. Выйти в люди, оторвавшись, наконец, от монитора - приятная роскошь для удалёнщика с ограниченным кругом общения. Да и не удалёнщикам выход из привычного колеса «работа-дом» не помешает.
Скорее всего, я что-то забыла — буду рада, если вы добавите своих мотиваций в комментах)
💯2❤1
События первого квартала 2026 в DevRel NN
В декабре прошлого года мы наметили несколько направлений, по которым в 2026-м хотелось бы провести тематические ужины сообщества.
(Кто не знает, у нас в Нижнем DevRel-ужины проходят интересно: лидер темы набрасывает некоторые пойнты, которые все потом обсуждают с ним и между собой - если хотите, можете залидировать тему, написав мне в личку на @efeiya_grassie.)
Итак, вот то, что мы хотели затронуть в дискуссиях этого года:
📍DevRel в эпоху hiring freeze: работа на удержание
📍Продуктовый DevRel «на подхвате» у продаж
📍ИИ-инструменты на службе DevRel: да и нет
📍Работа с молодёжью: юные падаваны в эпоху ИИ
Собственно, таков был наш план. А что у нас с фактом?
Первые 2 темы пока ждут своих героев, а вот 2 последних мы как раз планируем подробно обсудить в феврале и марте!
📅 25 февраля ужин будет посвящён "новой волне" приходящих в ИТ падаванов, тому, как с ними работать и как их понимать.
📅 20 марта 2 доклада из 3х на нашем митапе со Smalltech-сообществом будут про ИИ-инструменты в DevRel!
Предвкушаю интересные обсуждения, регистрация - совсем скоро в чатике DevRel NN!
В декабре прошлого года мы наметили несколько направлений, по которым в 2026-м хотелось бы провести тематические ужины сообщества.
(Кто не знает, у нас в Нижнем DevRel-ужины проходят интересно: лидер темы набрасывает некоторые пойнты, которые все потом обсуждают с ним и между собой - если хотите, можете залидировать тему, написав мне в личку на @efeiya_grassie.)
Итак, вот то, что мы хотели затронуть в дискуссиях этого года:
📍DevRel в эпоху hiring freeze: работа на удержание
📍Продуктовый DevRel «на подхвате» у продаж
📍ИИ-инструменты на службе DevRel: да и нет
📍Работа с молодёжью: юные падаваны в эпоху ИИ
Собственно, таков был наш план. А что у нас с фактом?
Первые 2 темы пока ждут своих героев, а вот 2 последних мы как раз планируем подробно обсудить в феврале и марте!
📅 25 февраля ужин будет посвящён "новой волне" приходящих в ИТ падаванов, тому, как с ними работать и как их понимать.
📅 20 марта 2 доклада из 3х на нашем митапе со Smalltech-сообществом будут про ИИ-инструменты в DevRel!
Предвкушаю интересные обсуждения, регистрация - совсем скоро в чатике DevRel NN!
Telegram
DevRel NN
Чат DevRel-специалистов для обмена опытом, поиска площадок для митапов и докладчиков. Правила чата: https://t.me/devrel_nn/1281
🔥2❤1
Почему разработчик не хочет публичности?
Мы в современном контентоцентричном мире как-то привыкли, что «светиться» больше и чаще - это плюс. Хотя публичность для многих людей непривычна и некомфортна. А если на работе приоритетная коммуникация - «человек-машина»? Тогда «выход из тени» 100% будет стрессом. Почему «опубликуйте лучше от компании» и «пусть лучше тимлид выступит» до сих пор актуальны?
Нелюбовь к хайпу
Разработчик может оценивать свою работу критично и сверхкритично. С его точки зрения сервис, о котором его просят рассказать, ещё «сырой» и будет готов только через N итераций. Это часто входит в противоречие с маркетинговой стратегией компании - бывает важно заявить о начале разработки или новой фиче раньше конкурентов, чтобы «застолбить место» и закрепить лидерство за собой. С позиции разработчика это «опять наобещаем лишнего, а потом в мыле будем допиливать». Не хочется быть «обещатором» и получать косые взгляды от команды.
Боязнь критики
Обратная связь далеко не всегда бывает позитивной. Комменты на Хабре и вопросы после выступления на конференции - отдельный стоппер для авторов и спикеров. При этом негатив от явного неадеквата легче отфильтровать и забыть. А вот обоснованное указание на пробел в знаниях может заставить специалиста надолго усомниться в собственной экспертности. Грустно, когда первая попытка поделиться опытом оказывается и последней.
Риски безопасности
Любой вынос внутренней «кухни» вовне потенциально опасен. И недосогласованный кейс, и не замазанный кусок конфиденциальных данных на слайдах, и случайная «оговорочка по Фрейду», и старое ПО с известной уязвимостью - всё это потенциальные убытки или ущерб репутации. Авторам статей несколько проще - текст до выхода и после вычитывают много раз. Слайды тоже проверяют. А вот отвечать на вопросы надо сразу «набело», поэтому докладов многие избегают.
Психологический дискомфорт
Оказаться перед толпой скептически настроенных людей, среди которых точно есть конкуренты и специалисты с большей экспертизой - испытание на прочность. Страх публичных выступлений имеет древние корни. Наши далёкие предки тоже дрожали, если им почему-то приходилось противопоставить себя племени: изгнание означало смерть. Следуя этой аналогии, стать докладчиком - значит пройти путь от рядового члена племени до вождя или шамана. Кто-то сознательно отказывается от этой роли.
...продолжение следует...
Мы в современном контентоцентричном мире как-то привыкли, что «светиться» больше и чаще - это плюс. Хотя публичность для многих людей непривычна и некомфортна. А если на работе приоритетная коммуникация - «человек-машина»? Тогда «выход из тени» 100% будет стрессом. Почему «опубликуйте лучше от компании» и «пусть лучше тимлид выступит» до сих пор актуальны?
Нелюбовь к хайпу
Разработчик может оценивать свою работу критично и сверхкритично. С его точки зрения сервис, о котором его просят рассказать, ещё «сырой» и будет готов только через N итераций. Это часто входит в противоречие с маркетинговой стратегией компании - бывает важно заявить о начале разработки или новой фиче раньше конкурентов, чтобы «застолбить место» и закрепить лидерство за собой. С позиции разработчика это «опять наобещаем лишнего, а потом в мыле будем допиливать». Не хочется быть «обещатором» и получать косые взгляды от команды.
Что делать: реализовать (и отстоять перед руководством) версию статьи или доклада с верно заданными ожиданиями. Не выпускать промо-тексты без технического ревью - ведь спросить технарей о корректности формулировок обходится дешевле, чем терять клиентов или кадры.
Боязнь критики
Обратная связь далеко не всегда бывает позитивной. Комменты на Хабре и вопросы после выступления на конференции - отдельный стоппер для авторов и спикеров. При этом негатив от явного неадеквата легче отфильтровать и забыть. А вот обоснованное указание на пробел в знаниях может заставить специалиста надолго усомниться в собственной экспертности. Грустно, когда первая попытка поделиться опытом оказывается и последней.
Что делать: до выпуска материала отдавать его на вычитку экспертам, чтобы отловить большую часть каверзных вопросов и противоречий внутри. Аналогично с докладами - не пренебрегать внутренними прогонами, несмотря на всеобщую занятость. Постараться внедрить в компании общую культуру принятия (и формулирования) обратной связи. Разъяснить, что критика работы не равна критике личности и что уточнение или недопонимание не равно критике. Ну, и провести встречу со спикером/автором по обратной связи, чтобы понять его настроение - классика.
Риски безопасности
Любой вынос внутренней «кухни» вовне потенциально опасен. И недосогласованный кейс, и не замазанный кусок конфиденциальных данных на слайдах, и случайная «оговорочка по Фрейду», и старое ПО с известной уязвимостью - всё это потенциальные убытки или ущерб репутации. Авторам статей несколько проще - текст до выхода и после вычитывают много раз. Слайды тоже проверяют. А вот отвечать на вопросы надо сразу «набело», поэтому докладов многие избегают.
Что делать: иметь в компании простой и понятный чек-лист для сведений, которые точно конфиденциальны. Организовать flow согласований (тех.ревью, PR, в отдельных сложных случаях - безопасники). Тренировать ответы на вопросы с коллегами и ИИ, иметь готовые «ответы-заглушки» для ситуаций, когда дело касается NDA.
Психологический дискомфорт
Оказаться перед толпой скептически настроенных людей, среди которых точно есть конкуренты и специалисты с большей экспертизой - испытание на прочность. Страх публичных выступлений имеет древние корни. Наши далёкие предки тоже дрожали, если им почему-то приходилось противопоставить себя племени: изгнание означало смерть. Следуя этой аналогии, стать докладчиком - значит пройти путь от рядового члена племени до вождя или шамана. Кто-то сознательно отказывается от этой роли.
Что делать: понимать, что «продать» идею публичности можно не всем и не сразу. Начинать с форматов, где «племя» виртуально и обратная связь асинхронна, закрепляя каждый успешный шаг. Много и часто хвалить за маленькие победы. Обязательно рассказывать об успешных примерах коллег. Согласовать систему мотивации. И, самое главное, договориться оставить в покое тех, кто прекрасен в разработке, но скорее уволится из компании, чем пойдёт на сцену.
...продолжение следует...
❤2
Отсутствие «крутых» задач
Часто специалист считает, что не делает ничего особенного - о чём, мол, я могу рассказать или написать, если я просто баги чиню или сутками в legacy ковыряюсь. Мол, вот если бы я язык программирования новый придумал, тогда да. А так рассказывать вроде бы нечего, да и у ИИшки спросить можно.
Вкус к публичности приходит с первыми успехами.
Но на пути к ним нужно много поддержки, и это забота DevRel.
Часто специалист считает, что не делает ничего особенного - о чём, мол, я могу рассказать или написать, если я просто баги чиню или сутками в legacy ковыряюсь. Мол, вот если бы я язык программирования новый придумал, тогда да. А так рассказывать вроде бы нечего, да и у ИИшки спросить можно.
Что делать: показать на примерах, что тема необязательно должна сотрясать устои - годная методика починки багов или совладания с legacy тоже пригодится. Набор хороших промптов для правильной модели может вирусно разойтись по сообществу, если решает распространённую боль. И вообще, есть фреймворки поиска тем вроде этого прекрасного слайда от Романа Поборчего.
Вкус к публичности приходит с первыми успехами.
Но на пути к ним нужно много поддержки, и это забота DevRel.
👌1
Январская встреча DevRel NN: составная занятость, коммунизм и холивар
На прошлой встрече DevRel NN было жарко - буквально столкнулись капитализм и коммунизм! Мы обсуждали тему частичной занятости в ИТ - лидер темы в этот раз предложила дискуссионный посыл: при современном уровне технологий человек может работать четверть своего времени на жизнеобеспечение и ещё 70-75% времени быть занятым в работе на благо общества. Примеры социальных проектов: сокращение очередей в поликлиниках, школьные классы по 15 человек вместо текущих 30, участие в исследованиях для увеличения продолжительности жизни и т.п.
Ещё пойнты от лидера темы: в будущем ручным останется только 25% труда, остальное возьмут на себя роботы. День человека будущего может выглядеть как 2 часа на заводе, где без него не обойтись, и 6 часов общественно полезных работ, которые при этом ему самому в кайф.
Что мешает утопии
Утопический посыл «зашёл» далеко не всем. Непонятно, что делать с инерцией компаний, которые по-прежнему хотят себе специалиста на full-time, и нежеланием большинства людей отказываться от личного благосостояния ради прогресса общества.
По сути, обсуждалась попытка изменить привычный уклад с приоритетом частного над общим на обратный, где общественное благо выше личного. На вопрос, что главнее - нематериальные ценности или материальные, нет однозначного ответа. На самоорганизацию большинства надеяться пока не приходится, но кто знает, что нас ждёт в отдалённом светлом будущем?
Волонтёрство и фриланс как компромисс
Звучали тезисы о том, что некоторые крупные корпорации до кризиса поощряли волонтёрские проекты для сотрудников и даже выделяли для этого специальные оплачиваемые выходные (лучший отдых, как мы помним, это смена деятельности). Пожалуй, в таком формате труд на благо общества возможен и не будет сопровождаться чувством вины за потерю дохода перед семьёй.
Ещё один формат деятельности, совместимый с волонтёрством и долгосрочными социальными проектами - фриланс. Уже сейчас многие совмещают «работу на хлеб» с неоплачиваемым, но интересным трудом.
Сколько лет графику «с 9 до 18, 5/7»
Вместе мы вспомнили, что даже нынешняя «пятидневка» с восьмичасовым рабочим днём - сравнительно недавнее завоевание (в России 8-часовой рабочий день ввели в 1917-м, а второй выходной окончательно добавили в 1968-м).
4-дневная рабочая неделя: «за» и «против»
Большинство согласилось, что новшества вроде «четырёхдневки» массово вводятся на уровне государства - сейчас её вводить компаниям никто не запрещает, но и урезать зарплату пропорционально они тоже не забывают. (Часто это происходит на автопроизводствах в связи с колебаниями спроса - чтобы не увольнять людей и потом не нанимать их обратно, автопроизводители в РФ довольно часто прибегают к «четырёхдневке»).
Пример Исландии, которая на госуровне перешла на «четырёхдневку» с сохранением оплаты, продолжает будоражить умы - для работников плюсы очевидны, компании тоже вроде бы постепенно привыкают. Преимущества (меньше отгулов, больничных, выгорания) перевешивают, но в некоторых случаях минусов от того, что на половину недели трудовая жизнь замрёт, может быть больше (простейший пример - профессии с вахтами и дежурствами в коммунальных службах).
Дополнительные темы
Говорили о гастарбайтерах в ИТ и тенденции работодателей нанимать там, где дешевле, о том, как США «вырубили» японское «экономическое чудо», когда товары из страны восходящего солнца стали составлять конкуренцию американским, и даже вспомнили об эффективности первых пятилеток в СССР.
Выводы
Человек по-прежнему ищет баланса между свободным временем (но «жить не на что») и финансовой свободой (но «жить некогда»). Идеальная история - «и деньги, и время», и на этой идее давно построили бизнес лотереи 😊
На прошлой встрече DevRel NN было жарко - буквально столкнулись капитализм и коммунизм! Мы обсуждали тему частичной занятости в ИТ - лидер темы в этот раз предложила дискуссионный посыл: при современном уровне технологий человек может работать четверть своего времени на жизнеобеспечение и ещё 70-75% времени быть занятым в работе на благо общества. Примеры социальных проектов: сокращение очередей в поликлиниках, школьные классы по 15 человек вместо текущих 30, участие в исследованиях для увеличения продолжительности жизни и т.п.
Ещё пойнты от лидера темы: в будущем ручным останется только 25% труда, остальное возьмут на себя роботы. День человека будущего может выглядеть как 2 часа на заводе, где без него не обойтись, и 6 часов общественно полезных работ, которые при этом ему самому в кайф.
Что мешает утопии
Утопический посыл «зашёл» далеко не всем. Непонятно, что делать с инерцией компаний, которые по-прежнему хотят себе специалиста на full-time, и нежеланием большинства людей отказываться от личного благосостояния ради прогресса общества.
По сути, обсуждалась попытка изменить привычный уклад с приоритетом частного над общим на обратный, где общественное благо выше личного. На вопрос, что главнее - нематериальные ценности или материальные, нет однозначного ответа. На самоорганизацию большинства надеяться пока не приходится, но кто знает, что нас ждёт в отдалённом светлом будущем?
Волонтёрство и фриланс как компромисс
Звучали тезисы о том, что некоторые крупные корпорации до кризиса поощряли волонтёрские проекты для сотрудников и даже выделяли для этого специальные оплачиваемые выходные (лучший отдых, как мы помним, это смена деятельности). Пожалуй, в таком формате труд на благо общества возможен и не будет сопровождаться чувством вины за потерю дохода перед семьёй.
Ещё один формат деятельности, совместимый с волонтёрством и долгосрочными социальными проектами - фриланс. Уже сейчас многие совмещают «работу на хлеб» с неоплачиваемым, но интересным трудом.
Сколько лет графику «с 9 до 18, 5/7»
Вместе мы вспомнили, что даже нынешняя «пятидневка» с восьмичасовым рабочим днём - сравнительно недавнее завоевание (в России 8-часовой рабочий день ввели в 1917-м, а второй выходной окончательно добавили в 1968-м).
4-дневная рабочая неделя: «за» и «против»
Большинство согласилось, что новшества вроде «четырёхдневки» массово вводятся на уровне государства - сейчас её вводить компаниям никто не запрещает, но и урезать зарплату пропорционально они тоже не забывают. (Часто это происходит на автопроизводствах в связи с колебаниями спроса - чтобы не увольнять людей и потом не нанимать их обратно, автопроизводители в РФ довольно часто прибегают к «четырёхдневке»).
Пример Исландии, которая на госуровне перешла на «четырёхдневку» с сохранением оплаты, продолжает будоражить умы - для работников плюсы очевидны, компании тоже вроде бы постепенно привыкают. Преимущества (меньше отгулов, больничных, выгорания) перевешивают, но в некоторых случаях минусов от того, что на половину недели трудовая жизнь замрёт, может быть больше (простейший пример - профессии с вахтами и дежурствами в коммунальных службах).
Дополнительные темы
Говорили о гастарбайтерах в ИТ и тенденции работодателей нанимать там, где дешевле, о том, как США «вырубили» японское «экономическое чудо», когда товары из страны восходящего солнца стали составлять конкуренцию американским, и даже вспомнили об эффективности первых пятилеток в СССР.
Выводы
Человек по-прежнему ищет баланса между свободным временем (но «жить не на что») и финансовой свободой (но «жить некогда»). Идеальная история - «и деньги, и время», и на этой идее давно построили бизнес лотереи 😊
Telegram
DevRel NN
Чат DevRel-специалистов для обмена опытом, поиска площадок для митапов и докладчиков. Правила чата: https://t.me/devrel_nn/1281
❤4👏2👍1🤔1
Пишем тезисы, которые ПК хотя бы читают😅
Недавно словила интересный инсайт во время подготовки к докладу. Технарь с минимальным опытом выступлений готовил заявку на отраслевую техническую конференцию. И...звучал как маркетолог! Вместо «мяса» -рыба видение и миссия компании. Было ясно, что его тезисы завернут, не дочитав.
Товарищ объяснял, ради чего всё делается, не говоря, на чём оно делается. Почему? Потому же, почему начинающий поэт всегда подражает школьной программе, а начинающий HR пишет про динамично развивающуюся компанию с молодым дружным коллективом. Стереотип подсказал, что внешние коммуникации - это маркетинг, а средний маркетинг выглядит как «мы инновационный стартап, несущий пользу миру». Заявка вполне укладывалась в этот шаблон.
Как боролись? Сели вместе выгружать знания, дрейфуя в сторону устройства системы, а не её конечных целей. Привлекли к оценке черновика Senior инженера, который посмотрел на текст критически, глазами ПК, выкрутив настройки строгости на максимум. Дал фидбек. «Всё фигня, переделать» тоже прозвучало. Переделали и подались, преодолев первый кругада отбора, на котором доклад идёт в «не нужно» без разговоров - его взялись всерьёз оценивать и «тащить».
Заявка в одном абзаце содержала описание проблемы, горячо проклинаемой инженерами в данной области, её идеальное «вкусное» решение, несколько метрик, которые удалось улучшить с его помощью и пару технологий, на которых оно построено.
Как причёсываете тезисы от маркетинга, коллеги?
Недавно словила интересный инсайт во время подготовки к докладу. Технарь с минимальным опытом выступлений готовил заявку на отраслевую техническую конференцию. И...звучал как маркетолог! Вместо «мяса» -
Товарищ объяснял, ради чего всё делается, не говоря, на чём оно делается. Почему? Потому же, почему начинающий поэт всегда подражает школьной программе, а начинающий HR пишет про динамично развивающуюся компанию с молодым дружным коллективом. Стереотип подсказал, что внешние коммуникации - это маркетинг, а средний маркетинг выглядит как «мы инновационный стартап, несущий пользу миру». Заявка вполне укладывалась в этот шаблон.
Как боролись? Сели вместе выгружать знания, дрейфуя в сторону устройства системы, а не её конечных целей. Привлекли к оценке черновика Senior инженера, который посмотрел на текст критически, глазами ПК, выкрутив настройки строгости на максимум. Дал фидбек. «Всё фигня, переделать» тоже прозвучало. Переделали и подались, преодолев первый круг
Заявка в одном абзаце содержала описание проблемы, горячо проклинаемой инженерами в данной области, её идеальное «вкусное» решение, несколько метрик, которые удалось улучшить с его помощью и пару технологий, на которых оно построено.
Как причёсываете тезисы от маркетинга, коллеги?
❤1🔥1
DevRel на подряде pinned «Всем привет, меня зовут Настя. В ИТ-коммуникациях, DevRel и технопиаре я с 2012 года. Много занималась продвижением СУБД-компаний (ex-Postgres Professional и др.). Живу в Нижнем Новгороде, устраиваю регулярные встречи сообщества DevRel NN. Резюме/список…»
DevRel-митап в Нижнем уже в следующую пятницу!
Кто не помнит, 20 марта мы делаем второй открытый деврельский митап в НиНо. Обсуждаем промпт для критики техноконтента с Аней Кононовой (экс-Петрович-Тех), ИИ-решения для подготовки презентаций с Мариной Степановой (ГНИВЦ) и делаем мастер-класс по публичным выступлениям с Диной Измайловой (DatsTeam). Подробные тезисы на Хабре, регистрация на Networkly и через IT52.
Присоединяться всё ещё можно и нужно, тем более что многие инструменты легко использовать и людям из смежных с DevRel областей — HR, PR, комьюнити-менеджмент, маркетинг, внутриком точно смогут почерпнуть для себя много полезного. Очень рекомендую сходить и разработчикам, желающим поработать над личным брендом (в нынешнем высококонкурентном рынке оно совсем не лишне).
Повторяю явки-пароли: 20 марта, 19:00, ИТ-лекторий «Горький-Тех». Регистрация тут (список пойдёт на охрану). С собой блокнот-ручку, улыбку и желание общаться с клёвыми людьми!👋
Кто не помнит, 20 марта мы делаем второй открытый деврельский митап в НиНо. Обсуждаем промпт для критики техноконтента с Аней Кононовой (экс-Петрович-Тех), ИИ-решения для подготовки презентаций с Мариной Степановой (ГНИВЦ) и делаем мастер-класс по публичным выступлениям с Диной Измайловой (DatsTeam). Подробные тезисы на Хабре, регистрация на Networkly и через IT52.
Присоединяться всё ещё можно и нужно, тем более что многие инструменты легко использовать и людям из смежных с DevRel областей — HR, PR, комьюнити-менеджмент, маркетинг, внутриком точно смогут почерпнуть для себя много полезного. Очень рекомендую сходить и разработчикам, желающим поработать над личным брендом (в нынешнем высококонкурентном рынке оно совсем не лишне).
Повторяю явки-пароли: 20 марта, 19:00, ИТ-лекторий «Горький-Тех». Регистрация тут (список пойдёт на охрану). С собой блокнот-ручку, улыбку и желание общаться с клёвыми людьми!👋
networkly.app
DevRel-митап № 2 в Нижнем Новгороде с сообществом Smalltech
❤3🔥1
Конспект встречи DevRel NN о новом поколении в ИТ
Рынок труда в ИТ в 2026-м больше не благоприятствует кандидатам. В текущих условиях даже опытным специалистам трудно найти работу - им отказывают с формулировкой «извини, но мы нашли дешевле». Поиск работы растягивается на месяцы. Особенно трудно искать позиции для начала карьеры - их немного, и конкурс на них огромен. Также в ходе оптимизаций недавно устроившийся джун - первый кандидат на сокращение.
Звериный оскал кризиса
Высказывалось мнение о том, что младший специалист в ИТ - вымирающий вид: стажёра сложно менторить, много времени тратится на коммуникацию. С ИИ-ассистентом при плотной работе можно за 2 месяца закрыть роадмап на 3 года, потому что программист в день пишет не более 500 строк кода, а нейронки увеличивают это количество сразу x10. Рынок постепенно перестраивается под модель «1 Senior с продуктовым видением + несколько джунов ИИ-агентов». При нынешних темпах развития технологий скоро не нужны будут даже мидлы. Уже сейчас многие сидят на debugging-задачах, пока ИИ пишет прототипы фич.
Откуда возьмутся завтрашние и послезавтрашние «боги целеполагания», пока не ясно. Текущий кризис обещает затянуться - уже сейчас 90% кандидатов на рынке называют причиной поиска работы сокращения на прежнем месте. Даже на вакансии без указания зарплаты приходит по 300 откликов в день.
Верны ли стереотипы о зумерах на работе?
Проведённое лидером темы Александрой Мураткиной исследование демонстрирует, что распространённые мемы о зумерах далеки от абсолютной истины. Отдельные дикие истории, разошедшиеся по Интернету, не репрезентативны. Зумеры просто «слышнее» предыдущих поколений - именно они рассказывают о трудностях на работе часто и публично.
Зумеры попали в высококонкурентный рынок, поэтому согласны задержаться на работе или договориться с работодателем на взаимовыгодную сделку (среди респондентов-зумеров такую готовность выразили 80%, это лишь чуть ниже, чем у миллениалов и иксов - 83% и 84% соответственно). Важно понимать, что приоритеты, границы и отношение к работе у человека в течение жизни меняются: кто-то торопится накопить на путешествие мечты, а кто-то опасается навредить здоровью из-за постоянных переработок.
Микроменеджмент больше раздражает миллениалов (30%), чем зумеров (22%) - вероятно, потому что миллениалы чаще с ним сталкивались чисто статистически: они уже давно на рынке труда, у них больше опыта. Распространение популярной психологии в последние годы помогает людям независимо от поколения распознавать, когда атмосфера на работе становится нездоровой, и принимать какие-то меры.
Стереотип о том, что зумеры любят поддерживающий фидбек, отчасти верен, но... кто же его не любит? Среди респондентов исследования нашего лидера темы его бы предпочли 56% зумеров, 57% миллениалов и 67% иксов - старшим поколениям он даже более важен и нужен!
Ещё одно распространённое мнение гласит, что зумеры предпочитают разбор тет-а-тет. На самом деле, его предпочли бы 65% зумеров, 67% миллениалов и 67% иксов - публичная критика в принципе не эффективна, в отличие от публичной похвалы.
Что думают о зумерах работодатели?
Среди сильных сторон нового поколения - высокая мотивация (27%), быстрота в освоении нового (26%) и нестандартное мышление (28%). В качестве минусов называют недостаточную самостоятельность (25%), быструю потерю интереса к рутине (25%) и конфликты поколений (23%).
Продолжение следует...
Рынок труда в ИТ в 2026-м больше не благоприятствует кандидатам. В текущих условиях даже опытным специалистам трудно найти работу - им отказывают с формулировкой «извини, но мы нашли дешевле». Поиск работы растягивается на месяцы. Особенно трудно искать позиции для начала карьеры - их немного, и конкурс на них огромен. Также в ходе оптимизаций недавно устроившийся джун - первый кандидат на сокращение.
Звериный оскал кризиса
Высказывалось мнение о том, что младший специалист в ИТ - вымирающий вид: стажёра сложно менторить, много времени тратится на коммуникацию. С ИИ-ассистентом при плотной работе можно за 2 месяца закрыть роадмап на 3 года, потому что программист в день пишет не более 500 строк кода, а нейронки увеличивают это количество сразу x10. Рынок постепенно перестраивается под модель «1 Senior с продуктовым видением + несколько джунов ИИ-агентов». При нынешних темпах развития технологий скоро не нужны будут даже мидлы. Уже сейчас многие сидят на debugging-задачах, пока ИИ пишет прототипы фич.
Откуда возьмутся завтрашние и послезавтрашние «боги целеполагания», пока не ясно. Текущий кризис обещает затянуться - уже сейчас 90% кандидатов на рынке называют причиной поиска работы сокращения на прежнем месте. Даже на вакансии без указания зарплаты приходит по 300 откликов в день.
Верны ли стереотипы о зумерах на работе?
Проведённое лидером темы Александрой Мураткиной исследование демонстрирует, что распространённые мемы о зумерах далеки от абсолютной истины. Отдельные дикие истории, разошедшиеся по Интернету, не репрезентативны. Зумеры просто «слышнее» предыдущих поколений - именно они рассказывают о трудностях на работе часто и публично.
Зумеры попали в высококонкурентный рынок, поэтому согласны задержаться на работе или договориться с работодателем на взаимовыгодную сделку (среди респондентов-зумеров такую готовность выразили 80%, это лишь чуть ниже, чем у миллениалов и иксов - 83% и 84% соответственно). Важно понимать, что приоритеты, границы и отношение к работе у человека в течение жизни меняются: кто-то торопится накопить на путешествие мечты, а кто-то опасается навредить здоровью из-за постоянных переработок.
Микроменеджмент больше раздражает миллениалов (30%), чем зумеров (22%) - вероятно, потому что миллениалы чаще с ним сталкивались чисто статистически: они уже давно на рынке труда, у них больше опыта. Распространение популярной психологии в последние годы помогает людям независимо от поколения распознавать, когда атмосфера на работе становится нездоровой, и принимать какие-то меры.
Стереотип о том, что зумеры любят поддерживающий фидбек, отчасти верен, но... кто же его не любит? Среди респондентов исследования нашего лидера темы его бы предпочли 56% зумеров, 57% миллениалов и 67% иксов - старшим поколениям он даже более важен и нужен!
Ещё одно распространённое мнение гласит, что зумеры предпочитают разбор тет-а-тет. На самом деле, его предпочли бы 65% зумеров, 67% миллениалов и 67% иксов - публичная критика в принципе не эффективна, в отличие от публичной похвалы.
Что думают о зумерах работодатели?
Среди сильных сторон нового поколения - высокая мотивация (27%), быстрота в освоении нового (26%) и нестандартное мышление (28%). В качестве минусов называют недостаточную самостоятельность (25%), быструю потерю интереса к рутине (25%) и конфликты поколений (23%).
Продолжение следует...
❤1
Один из стереотипов относительно зумеров - необязательность и нелояльность. «Ушёл на обед и не вернулся» - предельное выражение этого якобы тренда. Правда ли это? На самом деле, зумеры действительно чаще других поколений меняют работу - 24% зумеров считают, что увольняться и искать новые возможности раз в 1-2 года нормально. (Для сравнения: среди миллениалов такое мнение разделяют только 10%, а иксы совсем не считают это хорошей идеей). 47% зумеров-респондентов исследования планируют уволиться в 2026 году.
Это означает, что у работодателей, желающих работать с молодёжью, уже нет долгого срока на адаптацию новичка - трек развития должен укладываться максимум в 6 месяцев, потому что уже через 2 года сотрудник уйдёт куда-то ещё. Долгие испытатательные сроки стоит сократить.
Что говорят наставники о молодёжи?
20% считают, что зумеры хуже социализированы и не готовы работать в команде, ещё 19% жалуются на завышенные ожидания нового поколения, сформированные соцсетями инфлюэнсеров. Реальность оказывается несколько более прозаичной и суровой: на работе надо работать.
Задать верные ожидания помогают preonboarding-практики, когда ещё до принятия на себя обязательств будущий кандидат может прийти в компанию и почувствовать её «вайб».
В дополнение к руководителю у новичка должен быть напарник-бадди, которому он не подчиняется напрямую и который сможет быстро включить его в процессы.
В целом, у каждого поколения свои особенности, и зумеров можно мотивировать геймификацией, гибким графиком, а также принадлежностью к смыслу работы, который им импонирует.
Постскриптум: что ещё успели обсудить
Скорость восприятия увеличивается последние несколько поколений. Чем старше человек, тем более «медленным» он выглядит в глазах молодёжи. За последние 10 лет количество информации выросло в 1000 раз, и увеличилась её доступность.
Доступность готовых советов и генераций в Интернете отучает нас принимать самостоятельные решения. Хотя прозвучало мнение о том, что это произойдёт только с более пассивной частью населения - книги, ТВ и компьютеры не сделали всех поголовно тупыми - избыточное доверие к нейрослопу испытывают далеко не все.
Интересно, что зумеры больше ищут контактов с миллениалами и иксами, чем наоборот - более старшие и опытные сотрудники меньше хотят общаться с зумерами, что не мешало бы делать в рамках сокращения разрыва между поколениями и установления доброжелательной атмосферы в команде.
Достойная фантастического рассказа или антиутопии идея управления лояльностью через дофаминовый след также прозвучала на встрече. Мол, неважно что человек говорит о компании, важно, как он при этом реагирует - но тут мы уходим в проблему ложных срабатываний и индивидуальные особенности отдельных людей. А вообще любопытно, хоть и чуть жутко!
Больше интересного - на встречах DevRel NN и на будущем митапе сообщества 20 марта!
Это означает, что у работодателей, желающих работать с молодёжью, уже нет долгого срока на адаптацию новичка - трек развития должен укладываться максимум в 6 месяцев, потому что уже через 2 года сотрудник уйдёт куда-то ещё. Долгие испытатательные сроки стоит сократить.
Что говорят наставники о молодёжи?
20% считают, что зумеры хуже социализированы и не готовы работать в команде, ещё 19% жалуются на завышенные ожидания нового поколения, сформированные соцсетями инфлюэнсеров. Реальность оказывается несколько более прозаичной и суровой: на работе надо работать.
Задать верные ожидания помогают preonboarding-практики, когда ещё до принятия на себя обязательств будущий кандидат может прийти в компанию и почувствовать её «вайб».
В дополнение к руководителю у новичка должен быть напарник-бадди, которому он не подчиняется напрямую и который сможет быстро включить его в процессы.
В целом, у каждого поколения свои особенности, и зумеров можно мотивировать геймификацией, гибким графиком, а также принадлежностью к смыслу работы, который им импонирует.
Постскриптум: что ещё успели обсудить
Скорость восприятия увеличивается последние несколько поколений. Чем старше человек, тем более «медленным» он выглядит в глазах молодёжи. За последние 10 лет количество информации выросло в 1000 раз, и увеличилась её доступность.
Доступность готовых советов и генераций в Интернете отучает нас принимать самостоятельные решения. Хотя прозвучало мнение о том, что это произойдёт только с более пассивной частью населения - книги, ТВ и компьютеры не сделали всех поголовно тупыми - избыточное доверие к нейрослопу испытывают далеко не все.
Интересно, что зумеры больше ищут контактов с миллениалами и иксами, чем наоборот - более старшие и опытные сотрудники меньше хотят общаться с зумерами, что не мешало бы делать в рамках сокращения разрыва между поколениями и установления доброжелательной атмосферы в команде.
Достойная фантастического рассказа или антиутопии идея управления лояльностью через дофаминовый след также прозвучала на встрече. Мол, неважно что человек говорит о компании, важно, как он при этом реагирует - но тут мы уходим в проблему ложных срабатываний и индивидуальные особенности отдельных людей. А вообще любопытно, хоть и чуть жутко!
Больше интересного - на встречах DevRel NN и на будущем митапе сообщества 20 марта!
networkly.app
DevRel-митап № 2 в Нижнем Новгороде с сообществом Smalltech
👍1
Организаторские выводы из вчерашнего DevRel-митапа в Нижнем Новгороде
Вчера у нас всё прошло круто, со стандартной доходимостью бесплатных ивентов (50-60%), в тайминге, с клёвыми вопросами, инсайтами, но всегда есть что улучшить. Пишу этот пост-ретро главным образом затем, чтоб мне самой учесть некоторые из этих моментов в будущей подготовке к DevRel-секции на нижегородской конференции сообществ ITGorky. Ура-отчёт с фоточками и материалами события тоже будет, но чуть позже.
Рассылки с напоминаниями до сих пор необходимы. Несмотря на то, что большинство сервисов регистрации сегодня шлют автоматические напоминалки, их часто игнорируют. Стоит отправлять личное письмо для тех, кто зарегистрировался в первых рядах пару месяцев назад и уже успел об этом позабыть.
События в офлайне часто конкурируют с совсем неожиданными вещами (в онлайне тоже, и там их даже больше, т.к. скипнуть контакт проще). В этот раз наш офлайн конкурировал с начавшейся эпидемией гриппа вследствие авитаминоза, которая выбила из наших рядов нескольких активных участников комьюнити. И это только те, кто смог/захотел отписаться. Из очевидного мы конкурировали с вечером пятницы, весной, хорошей погодой и близкими выходными. Про пятницу и весну мы знали, но работающим иногородним докладчикам этот день, очевидно, удобнее.
Готовые слайды не всегда равны на 200% готовому докладу. Время на прогон в конце квартала найти почти невозможно, приоритет комьюнити-задач относительно обязательных рабочих, очевидно, ниже. Прогонов всегда хочется ещё больше - но даже мою пятиминутку оттарабанить в тишине несколько раз надо ещё постараться. Где найти свободные полчаса×4, я не представляю совсем. (По моим наблюдениям, доклад бывает прекрасен где-то после 4-5 полноценных прогонов). Будем к этому стремиться в будущем.
Интерактивы с участием Инета в наше неспокойное время проводить трудно. Кажется, всё надо максимально упрощать и сводить к офлайну, где только можно. Бумажные резервные тесты были кстати, но с обработкой результатов нам, избалованным автоподсчётом в формах, уже пришлось туго. Верните мой 2019й, короче.
Пора заводить резервные платформы (ещё позавчера, да). Кто не знал, уже есть ВК-паблик DevRel MSK-SPB-NN для анонсов. Телегу стали активно блочить как раз накануне нашего события, полагаю, это частично повлияло на доходимость, и даже часть оргвопросов пришлось решать тупо по телефону.
В целом, это просто моё ворчание человека, который пережил более 120 ивентов в разном качестве. Я придираюсь, но без этой рефлексии в другой раз я сделаю те же ошибки, поэтому пусть оно будет)
Вчера у нас всё прошло круто, со стандартной доходимостью бесплатных ивентов (50-60%), в тайминге, с клёвыми вопросами, инсайтами, но всегда есть что улучшить. Пишу этот пост-ретро главным образом затем, чтоб мне самой учесть некоторые из этих моментов в будущей подготовке к DevRel-секции на нижегородской конференции сообществ ITGorky. Ура-отчёт с фоточками и материалами события тоже будет, но чуть позже.
Рассылки с напоминаниями до сих пор необходимы. Несмотря на то, что большинство сервисов регистрации сегодня шлют автоматические напоминалки, их часто игнорируют. Стоит отправлять личное письмо для тех, кто зарегистрировался в первых рядах пару месяцев назад и уже успел об этом позабыть.
События в офлайне часто конкурируют с совсем неожиданными вещами (в онлайне тоже, и там их даже больше, т.к. скипнуть контакт проще). В этот раз наш офлайн конкурировал с начавшейся эпидемией гриппа вследствие авитаминоза, которая выбила из наших рядов нескольких активных участников комьюнити. И это только те, кто смог/захотел отписаться. Из очевидного мы конкурировали с вечером пятницы, весной, хорошей погодой и близкими выходными. Про пятницу и весну мы знали, но работающим иногородним докладчикам этот день, очевидно, удобнее.
Готовые слайды не всегда равны на 200% готовому докладу. Время на прогон в конце квартала найти почти невозможно, приоритет комьюнити-задач относительно обязательных рабочих, очевидно, ниже. Прогонов всегда хочется ещё больше - но даже мою пятиминутку оттарабанить в тишине несколько раз надо ещё постараться. Где найти свободные полчаса×4, я не представляю совсем. (По моим наблюдениям, доклад бывает прекрасен где-то после 4-5 полноценных прогонов). Будем к этому стремиться в будущем.
Интерактивы с участием Инета в наше неспокойное время проводить трудно. Кажется, всё надо максимально упрощать и сводить к офлайну, где только можно. Бумажные резервные тесты были кстати, но с обработкой результатов нам, избалованным автоподсчётом в формах, уже пришлось туго. Верните мой 2019й, короче.
Пора заводить резервные платформы (ещё позавчера, да). Кто не знал, уже есть ВК-паблик DevRel MSK-SPB-NN для анонсов. Телегу стали активно блочить как раз накануне нашего события, полагаю, это частично повлияло на доходимость, и даже часть оргвопросов пришлось решать тупо по телефону.
В целом, это просто моё ворчание человека, который пережил более 120 ивентов в разном качестве. Я придираюсь, но без этой рефлексии в другой раз я сделаю те же ошибки, поэтому пусть оно будет)
❤2
Материалы с мартовского митапа и... апрельский DevRel-ужин!
Народная примета: если у организаторов и спикеров митапа после него отпуск, материалы могут чуть задержаться. Обещанного, однако, ждать три года не придётся. Видео c нижегородского DevRel-митапа 20 марта нарезаны, а слайды загружены в облако. Если вы были на митапе, восстановите в памяти лучшие моменты. Если не были, ознакомитесь с полезным контентом про ИИ-инструменты и публичные выступления.
Доклад “Подручный критик: продуктивный брейншторм и вычитка технического контента с обученным промптом-инженером” (Анна Кононова, Мастерская IT, Смоллтех-сообщество)
📽️ Видео
🖼️ Слайды
Почему стоит посмотреть: чтобы получить доступ к промпту-критику, созданному на основе интервью и фидбека реальных инженеров-скептиков
Доклад “Презентации для спикеров: быстрая ИИ-сборка визуальных материалов в конференционном качестве” (Марина Степанова, ГНИВЦ)
📽️ Видео
🖼️ Слайды
Почему стоит посмотреть: чтобы узнать, как правильно и быстро готовить презентации для отчётов и услышать байки (мне особо зашло, что ИИ путает DevRel и DevOps!)
Мастер-класс “Почему эксперты молчат — и как начать выступать без боли с ДатсТехТВ (DatsTechTV)” (Дина Измайлова, DatsTeam)
📽️ Видео
🖼️ Слайды
Почему стоит посмотреть: чтобы нагенерить тем для будущих выступлений на годы вперёд и определить, какой вы древнегреческий бог-спикер!
🙏🙏🙏Благодарю Смоллтех-сообщество за успешный опыт коллаборации, крутых спикеров и интересные доклады - возвращайтесь к нам с новым ламповым оффлайн-митапом!
Ближайшее событие в Нижнем - следующий ужин сообщества DevRel NN, тема - работа в турбулентные времена, сбор 15 апреля в 19:30 в кафе «О’суси» (пл.Минина и Пожарского, 2).
Народная примета: если у организаторов и спикеров митапа после него отпуск, материалы могут чуть задержаться. Обещанного, однако, ждать три года не придётся. Видео c нижегородского DevRel-митапа 20 марта нарезаны, а слайды загружены в облако. Если вы были на митапе, восстановите в памяти лучшие моменты. Если не были, ознакомитесь с полезным контентом про ИИ-инструменты и публичные выступления.
Доклад “Подручный критик: продуктивный брейншторм и вычитка технического контента с обученным промптом-инженером” (Анна Кононова, Мастерская IT, Смоллтех-сообщество)
📽️ Видео
🖼️ Слайды
Почему стоит посмотреть: чтобы получить доступ к промпту-критику, созданному на основе интервью и фидбека реальных инженеров-скептиков
Доклад “Презентации для спикеров: быстрая ИИ-сборка визуальных материалов в конференционном качестве” (Марина Степанова, ГНИВЦ)
📽️ Видео
🖼️ Слайды
Почему стоит посмотреть: чтобы узнать, как правильно и быстро готовить презентации для отчётов и услышать байки (мне особо зашло, что ИИ путает DevRel и DevOps!)
Мастер-класс “Почему эксперты молчат — и как начать выступать без боли с ДатсТехТВ (DatsTechTV)” (Дина Измайлова, DatsTeam)
📽️ Видео
🖼️ Слайды
Почему стоит посмотреть: чтобы нагенерить тем для будущих выступлений на годы вперёд и определить, какой вы древнегреческий бог-спикер!
🙏🙏🙏Благодарю Смоллтех-сообщество за успешный опыт коллаборации, крутых спикеров и интересные доклады - возвращайтесь к нам с новым ламповым оффлайн-митапом!
Ближайшее событие в Нижнем - следующий ужин сообщества DevRel NN, тема - работа в турбулентные времена, сбор 15 апреля в 19:30 в кафе «О’суси» (пл.Минина и Пожарского, 2).
❤1🔥1
Нужны ли будут DevRel-специалисты послезавтра?
Берусь за достаточно холиварную тему, к которой хотелось бы получить комментарии более умных и компетентных людей, чем я. Логика очень простая: DevRel живёт там, где нужна коммуникация с техническими специалистами (стереотипное мнение: технари заточены под взаимодействие «человек-машина» и интровертны, затем и нужен суперкоммуникатор рядом). И всё было логично, пока в систему не добавился новый элемент - ИИ.
DevRel в эпоху ИИ: сомнения в целесообразности
1) Насколько сейчас нужен DevRel как переводчик с узкопрофильного «программистского» на общепонятный бизнесовый или научно-популярный? Есть же ИИ, который уже сейчас помогает поверхностно ухватить суть любого технического мессиджа. ИИ запросто объяснит «как для чайника» - зачем теперь мы?
2) Как изменится профессия DevRel послезавтра, если машина понимает речь, и управляет ей больше не гик-интроверт, а вполне компанейский и умеющий выражать мысли архитектор систем? Он сам классно пишет промпты / инструкции для агентов - соберёт и что-нибудь для сообщества на их основе, не? Зачем ему DevRel?
Очевидно, что теперь что-то здорово изменится, и очень круто будет послушать, что именно и как.
Примерно такой вопрос заброшен на DevRel-супервизию (она уже завтра, приходите!), и крутой доклад с обстоятельным ответом на него мы ждём в середине октября на DevRel-секции конференции нижегородских сообществ ITGorky!
Берусь за достаточно холиварную тему, к которой хотелось бы получить комментарии более умных и компетентных людей, чем я. Логика очень простая: DevRel живёт там, где нужна коммуникация с техническими специалистами (стереотипное мнение: технари заточены под взаимодействие «человек-машина» и интровертны, затем и нужен суперкоммуникатор рядом). И всё было логично, пока в систему не добавился новый элемент - ИИ.
DevRel в эпоху ИИ: сомнения в целесообразности
1) Насколько сейчас нужен DevRel как переводчик с узкопрофильного «программистского» на общепонятный бизнесовый или научно-популярный? Есть же ИИ, который уже сейчас помогает поверхностно ухватить суть любого технического мессиджа. ИИ запросто объяснит «как для чайника» - зачем теперь мы?
2) Как изменится профессия DevRel послезавтра, если машина понимает речь, и управляет ей больше не гик-интроверт, а вполне компанейский и умеющий выражать мысли архитектор систем? Он сам классно пишет промпты / инструкции для агентов - соберёт и что-нибудь для сообщества на их основе, не? Зачем ему DevRel?
Очевидно, что теперь что-то здорово изменится, и очень круто будет послушать, что именно и как.
Примерно такой вопрос заброшен на DevRel-супервизию (она уже завтра, приходите!), и крутой доклад с обстоятельным ответом на него мы ждём в середине октября на DevRel-секции конференции нижегородских сообществ ITGorky!
networkly.app
"Деврел-супервизия": круглый стол
❤2
Где, как и зачем учиться на DevRel-специалиста?
Как многие в «большом» DevRel-комьюнити уже знают, нижегородские профи с DevRel-функцией из DevRel NN собираются ужинать не просто так, а по поводу (пробовали собираться без него, но это никому не зашло). А ещё мыгорьковчане гурманы и каждый раз ужинаем в новом ресторане (скоро соберём таблицу рекомендаций и стоп-лист, LOL!). И, разумеется, всегда рады иногородним гостям - ужины публикуются на IT52 и Networkly.
Тема ближайшего майского ужина в Нижнем - профильное «деврельское» образование. Повод для этого простой - сразу двум нижегородкам (мне и Алёне) удалось пройти DevRel-курсы от OTUS, и пока свежи итоговые впечатления, хочется поделиться ими с заинтересованными коллегами. Разумеется, поговорим о «санитарном минимуме» требований к профессии сегодня (и вчера -- я это ещё помню!), о том, стоит ли специально учиться на DevRel, кому это подойдёт и как изменятся курсы послезавтра (будут спойлерыс поправкой на кризис и ИИ , ага). Ну, и попробуем сопоставить то, чему учили на курсах, с реальными вакансиями в DevRel, HR-бренде и ИТ-коммуникациях.
Надеемся сделать будущий разговор честным и интересным, упомянуть другие ценные источники знаний и книги, и послушать самые разные точки зрения, включая классическую «что такое этот ваш DevRel вообще». Регистрация на ужин пока открыта, места ещё есть. По традиции, после появится конспект основных тезисов встречи, но всегда лучше пообщаться лично. Ждём всех!
Как многие в «большом» DevRel-комьюнити уже знают, нижегородские профи с DevRel-функцией из DevRel NN собираются ужинать не просто так, а по поводу (пробовали собираться без него, но это никому не зашло). А ещё мы
Тема ближайшего майского ужина в Нижнем - профильное «деврельское» образование. Повод для этого простой - сразу двум нижегородкам (мне и Алёне) удалось пройти DevRel-курсы от OTUS, и пока свежи итоговые впечатления, хочется поделиться ими с заинтересованными коллегами. Разумеется, поговорим о «санитарном минимуме» требований к профессии сегодня (и вчера -- я это ещё помню!), о том, стоит ли специально учиться на DevRel, кому это подойдёт и как изменятся курсы послезавтра (будут спойлеры
Надеемся сделать будущий разговор честным и интересным, упомянуть другие ценные источники знаний и книги, и послушать самые разные точки зрения, включая классическую «что такое этот ваш DevRel вообще». Регистрация на ужин пока открыта, места ещё есть. По традиции, после появится конспект основных тезисов встречи, но всегда лучше пообщаться лично. Ждём всех!
❤1
Работа DevRel в турбулентные времена (по следам апрельского ужина в Нижнем)
Отклонения от «среднего по больнице» всегда возможны, но игнорить тренды - непозволительная роскошь. На апрельском ужине-нытинге в Нижнем Новгороде обсудили кризисные изменения в работе DevRel и HR. Ниже обработанные выжимки из моих записей со встречи, с которыми вполне можно поспорить в комментариях)
Акцент на внутренний DevRel. Внешние сообщества разработчиков сейчас развивают только те, кто умеет выстраивать в них воронку продаж. Поскольку найм - это теперь «что-то на богатом», компании перестают поддерживать и заводить внешние сообщества разработчиков, которые раньше были их «наймовыми полянами». Независимым ИТ-сообществам выживать стало сложнее - спонсоры теперь более прижимисты.
Хороводить теперь надо внутренние сообщества по технологиям - это способ улучшить коммуникации между командами, который в долгосрочной перспективе даёт выгоду - люди начинают чаще идти друг к другу за советами, выступать с инициативами, если они уже знакомы по сообществу. Появляется больше прозрачности в том, кто за что отвечает, и больше сведений о том, что пилят в соседних командах. Выше шансы на удержание - вместо ухода из компании человек может рассмотреть переход в другую команду или проект с похожим стеком, если он о них знает.
Отдельная интересная проблема - модерация таких сообществ: многие подвергают самоцензуре то, что пишут в рабочих каналах, но встречается и обратная крайность - главную движуху даже во внутреннем в сообществе могут захватить токсичные ребята, которые неважно себя контролируют. Поддержание пульса сообщества при сохранении здоровой атмосферы = задачка со звёздочкой, нужен баланс между духотой и драйвом. Технический лид чата необязательно должен быть лидом команды - в идеале это должен быть тот, кому эта деятельность по душе.
Внутренние мероприятия для обмена знаниями. Акцент на внутренние митапы, разного рода Tech Talks для межкомандного взаимодействия и повышения осведомлённости о важных разработках тоже стал повсеместным. Целей обычно две - поднять моральный дух, лишний раз собрать ключевых людей вместе и спросить, как у них дела, и заодно обеспечить полезную для компании циркуляцию знаний. Метрики эффективности Tech Talks похожи на метрики внешних ивентов, но в случае с внутренней аудиторией больше вариантов спросить обратную связь - не только догнать коротким опросом, но и в неформальной обстановке уточнить, как оно вообще и не фигню ли мы делаем.
ИИ-зация процесса разработки. Наряду с кризисом, обсуждалось проникновение ИИ в практику разработки ПО. Любопытно, что сопротивление внедрению ИИ в процессы порой демонстрируют и сами разработчики, всё из-за пресловутой job security - опасаются замены на ИИ-агентов имени себя. Решается этот вопрос созданием собственных кастомных курсов обучению ИИ под задачи компании (у провайдеров курсов задача не пилить кастомное, а подороже продать готовое). Отдельное внимание - теме безопасности. Бигтехи уже используют собственные частные модели в собственном контуре под контролем безопасников. Компаниям поменьше приходится использовать публичные модели, проводя обязательные тренинги по тому, какими данными с ними нельзя делиться.
Вторая жизнь «клубов по интересам» внутри компаний. Малобюджетные истории типа книжных клубов, йоги в офисе или клубов дегустаторов кофе и вин внезапно снова набирают популярность - повышать лояльность по-прежнему надо, а денег на шикарные корпоративы почти ни у кого нет. Одним из вариантов поддержки может стать даже бесплатное предоставление офисной площадки корпоративному театру (!). При наличии в компании «живых» клубов опрос про хобби на старте и информирование о возможностях для хобби может стать частью стратегии удержания.
«Найм бриллиантов» в кризис задёшево скорее утопия. Многие компании мониторят рынок на предмет внезапно хороших сотрудников в поиске, но не находят их: настоящих «звёзд» крайне редко увольняют даже в кризис. Для бизнеса такие кадры скорее актив, который можно эффективнее использовать, чем пассив, который надо скинуть.
Отклонения от «среднего по больнице» всегда возможны, но игнорить тренды - непозволительная роскошь. На апрельском ужине-нытинге в Нижнем Новгороде обсудили кризисные изменения в работе DevRel и HR. Ниже обработанные выжимки из моих записей со встречи, с которыми вполне можно поспорить в комментариях)
Акцент на внутренний DevRel. Внешние сообщества разработчиков сейчас развивают только те, кто умеет выстраивать в них воронку продаж. Поскольку найм - это теперь «что-то на богатом», компании перестают поддерживать и заводить внешние сообщества разработчиков, которые раньше были их «наймовыми полянами». Независимым ИТ-сообществам выживать стало сложнее - спонсоры теперь более прижимисты.
Хороводить теперь надо внутренние сообщества по технологиям - это способ улучшить коммуникации между командами, который в долгосрочной перспективе даёт выгоду - люди начинают чаще идти друг к другу за советами, выступать с инициативами, если они уже знакомы по сообществу. Появляется больше прозрачности в том, кто за что отвечает, и больше сведений о том, что пилят в соседних командах. Выше шансы на удержание - вместо ухода из компании человек может рассмотреть переход в другую команду или проект с похожим стеком, если он о них знает.
Отдельная интересная проблема - модерация таких сообществ: многие подвергают самоцензуре то, что пишут в рабочих каналах, но встречается и обратная крайность - главную движуху даже во внутреннем в сообществе могут захватить токсичные ребята, которые неважно себя контролируют. Поддержание пульса сообщества при сохранении здоровой атмосферы = задачка со звёздочкой, нужен баланс между духотой и драйвом. Технический лид чата необязательно должен быть лидом команды - в идеале это должен быть тот, кому эта деятельность по душе.
Внутренние мероприятия для обмена знаниями. Акцент на внутренние митапы, разного рода Tech Talks для межкомандного взаимодействия и повышения осведомлённости о важных разработках тоже стал повсеместным. Целей обычно две - поднять моральный дух, лишний раз собрать ключевых людей вместе и спросить, как у них дела, и заодно обеспечить полезную для компании циркуляцию знаний. Метрики эффективности Tech Talks похожи на метрики внешних ивентов, но в случае с внутренней аудиторией больше вариантов спросить обратную связь - не только догнать коротким опросом, но и в неформальной обстановке уточнить, как оно вообще и не фигню ли мы делаем.
ИИ-зация процесса разработки. Наряду с кризисом, обсуждалось проникновение ИИ в практику разработки ПО. Любопытно, что сопротивление внедрению ИИ в процессы порой демонстрируют и сами разработчики, всё из-за пресловутой job security - опасаются замены на ИИ-агентов имени себя. Решается этот вопрос созданием собственных кастомных курсов обучению ИИ под задачи компании (у провайдеров курсов задача не пилить кастомное, а подороже продать готовое). Отдельное внимание - теме безопасности. Бигтехи уже используют собственные частные модели в собственном контуре под контролем безопасников. Компаниям поменьше приходится использовать публичные модели, проводя обязательные тренинги по тому, какими данными с ними нельзя делиться.
Вторая жизнь «клубов по интересам» внутри компаний. Малобюджетные истории типа книжных клубов, йоги в офисе или клубов дегустаторов кофе и вин внезапно снова набирают популярность - повышать лояльность по-прежнему надо, а денег на шикарные корпоративы почти ни у кого нет. Одним из вариантов поддержки может стать даже бесплатное предоставление офисной площадки корпоративному театру (!). При наличии в компании «живых» клубов опрос про хобби на старте и информирование о возможностях для хобби может стать частью стратегии удержания.
«Найм бриллиантов» в кризис задёшево скорее утопия. Многие компании мониторят рынок на предмет внезапно хороших сотрудников в поиске, но не находят их: настоящих «звёзд» крайне редко увольняют даже в кризис. Для бизнеса такие кадры скорее актив, который можно эффективнее использовать, чем пассив, который надо скинуть.
Компании всё чаще сталкиваются с ИИ-ложью о навыках. ИИ вывел традиционное «приукрашивание» резюме на качественно новый уровень. В высококонкурентном рынке соискатели часто идут на отчаянные шаги, чтобы получить право на интервью. Компании, в свою очередь, хотят подстраховаться от «мусорных» собеседований и начинают настойчивее просить справки о трудовой деятельности и рекомендации с предыдущих мест работы. Наличие собственных тренированных ИИ-агентов искушает квалифицированных специалистов двойным трудоустройством, а законодательной базы под это ещё нет. Чтобы убедиться, что человек действительно приходит на основное место работы при практиках удалёнки и электронного документооборота, HR приходится запрашивать доказательства и быть немного детективом.
Ценность метанавыков в кризис возрастает. Прокачивать hard skills и soft skills мы более-менее привыкли, но турбулентность сегодняшней реальности требует развивать метанавыки, составляющие базис личности для «хардов» и «софтов». Метанавыки - это личностные качества вроде критического мышления, рефлексии и осознанности, гибкости/адаптивности и устойчивости психики в постоянно меняющемся мире. Они могут принести пользу практически в любой профессии, и, поскольку спрос уже рождает предложение, появляются разного рода тренинги для этих направлений.
А майский ужин сообщества DevRel NN уже совсем скоро, вечером 20 мая, если вы вдруг не устали на ЦИПРе, регистрируйтесь и приходите)
Ценность метанавыков в кризис возрастает. Прокачивать hard skills и soft skills мы более-менее привыкли, но турбулентность сегодняшней реальности требует развивать метанавыки, составляющие базис личности для «хардов» и «софтов». Метанавыки - это личностные качества вроде критического мышления, рефлексии и осознанности, гибкости/адаптивности и устойчивости психики в постоянно меняющемся мире. Они могут принести пользу практически в любой профессии, и, поскольку спрос уже рождает предложение, появляются разного рода тренинги для этих направлений.
А майский ужин сообщества DevRel NN уже совсем скоро, вечером 20 мая, если вы вдруг не устали на ЦИПРе, регистрируйтесь и приходите)
👍1
«Технотекст 8» глазами члена жюри
«Технотекст» в эпоху ИИ - это более чем смело. Минус 130 ИИ-статей на входе. Оценить оставшиеся 700+ предстояло живым людям, включая меня (спасибо дорогому Хабру за доверие и приглашение в жюри!). И вот - табличка с десятками статей и несколькими критериями, о-очень сжатые сроки и море азарта. В профессиональном смысле решение присоединиться к жюри себя оправдало на 200% - стало намного лучше видно, как надо и как не надо писать на Хабр. Пару рекомендаций хабровчанам, включая себя, я черкнула в своём отзыве для итоговой статьи.
Сильно бросалась в глаза разница между частными авторами и корпоративными публикациями. То, что эти категории теперь оценивают отдельно - правильно. Видно, что корпоративную статью «тащит» целый локомотив сотрудников, а текст «частника» хорошо если кто-то разок вычитал по дружбе. Но даже этим «разком» пренебрегать не стоит. Если хоть кому-то показал и улучшил, уже круть. Показал нескольким правильным людям - увеличил шансы на победу. А особо продвинутые ничего не пишут, пока не протестируют идею на фокус-группе - все мои вирусные тексты родились именно так.
Были статьи классного технического уровня, но с «собачьей проблемой»: сам автор неплохо всё понимает, но доходчиво объяснить другим не может. Итог - низкие охваты при высоком потенциале. Хабр всё же не хранилище документации, а научпоп-медиа, где классный текст могут прочитать не из-за рабочей необходимости, а из любопытства, ради расширения кругозора.
Среди критериев оценки особое внимание уделялось полезности статьи и воспроизводимости описанных в ней подходов. Вообще в моей выборке было два вида текстов с шансами на победу: «детальный и честный кейс от корпорации» и «лучшие практики / туториал от частника» (они в итоге и победили). Ошибки тут довольно предсказуемы: «кейс, чтобы показать, какие мы большие и успешные, без факапов» («мы же компания XYZ, у нас ничего сломаться и упасть не может!») и «практики / туториал Капитана Очевидность».
Отдельно хочется упомянуть несколько запомнившихся мне статей, не прошедших в финал. Ребята вот тут сверстали всё как боженьки, хотелось им поставить 11 из 10 за умение структурировать материал. А вот здесь авторы интересно рассказали про риски при закупке запчастей и откровенный мухлёж производителей «железа», которое сейчас у всех болит. Ещё запомнилась статья «для сетевиков от сетевика» с матерком, где автору явно было по фану делать туториал без оглядки на то, как он пишет - это, скорее, антипример для «Технотекста», однако ж охват 22К при 72 (!) минутах на чтение.
Ну, и раз уж об этом официально написали аж в итогах «Технотекста», расскажу и тут, что я ищу новые проекты, причём рассматриваю как частичную занятость, так и выход в штат (удалёнка будет плюсом, я на ней 95% времени с 2013 года).
«Технотекст» в эпоху ИИ - это более чем смело. Минус 130 ИИ-статей на входе. Оценить оставшиеся 700+ предстояло живым людям, включая меня (спасибо дорогому Хабру за доверие и приглашение в жюри!). И вот - табличка с десятками статей и несколькими критериями, о-очень сжатые сроки и море азарта. В профессиональном смысле решение присоединиться к жюри себя оправдало на 200% - стало намного лучше видно, как надо и как не надо писать на Хабр. Пару рекомендаций хабровчанам, включая себя, я черкнула в своём отзыве для итоговой статьи.
Сильно бросалась в глаза разница между частными авторами и корпоративными публикациями. То, что эти категории теперь оценивают отдельно - правильно. Видно, что корпоративную статью «тащит» целый локомотив сотрудников, а текст «частника» хорошо если кто-то разок вычитал по дружбе. Но даже этим «разком» пренебрегать не стоит. Если хоть кому-то показал и улучшил, уже круть. Показал нескольким правильным людям - увеличил шансы на победу. А особо продвинутые ничего не пишут, пока не протестируют идею на фокус-группе - все мои вирусные тексты родились именно так.
Были статьи классного технического уровня, но с «собачьей проблемой»: сам автор неплохо всё понимает, но доходчиво объяснить другим не может. Итог - низкие охваты при высоком потенциале. Хабр всё же не хранилище документации, а научпоп-медиа, где классный текст могут прочитать не из-за рабочей необходимости, а из любопытства, ради расширения кругозора.
Среди критериев оценки особое внимание уделялось полезности статьи и воспроизводимости описанных в ней подходов. Вообще в моей выборке было два вида текстов с шансами на победу: «детальный и честный кейс от корпорации» и «лучшие практики / туториал от частника» (они в итоге и победили). Ошибки тут довольно предсказуемы: «кейс, чтобы показать, какие мы большие и успешные, без факапов» («мы же компания XYZ, у нас ничего сломаться и упасть не может!») и «практики / туториал Капитана Очевидность».
Отдельно хочется упомянуть несколько запомнившихся мне статей, не прошедших в финал. Ребята вот тут сверстали всё как боженьки, хотелось им поставить 11 из 10 за умение структурировать материал. А вот здесь авторы интересно рассказали про риски при закупке запчастей и откровенный мухлёж производителей «железа», которое сейчас у всех болит. Ещё запомнилась статья «для сетевиков от сетевика» с матерком, где автору явно было по фану делать туториал без оглядки на то, как он пишет - это, скорее, антипример для «Технотекста», однако ж охват 22К при 72 (!) минутах на чтение.
Ну, и раз уж об этом официально написали аж в итогах «Технотекста», расскажу и тут, что я ищу новые проекты, причём рассматриваю как частичную занятость, так и выход в штат (удалёнка будет плюсом, я на ней 95% времени с 2013 года).
Хабр
Технотекст 8: победа естественного интеллекта
< ... >Нельзя сказать человеку: «Ты можешь творить. Так давай, твори». Гораздо вернее подождать, пока он сам скажет: «Я могу творить, и я буду творить, хотите вы этого или нет!»...