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

Мы решили узнать у экспертов из IT-индустрии, кому и зачем стоит идти в преподавание и какие неочевидные бонусы можно от этого получить.

Энергия и вдохновение

Чтобы обучать других, нужно не только владеть теми навыками, которые вы собираетесь преподавать. Не менее важно уметь объяснять другим сложные вещи доступно и понятно. А ещё хотеть научить других, не раздражаясь на ошибки или непонимание. Без желания ничего не получится, даже если в своём деле вы самый высококлассный эксперт.

Объяснять другим — целое искусство, требующее терпения и эмпатии. Но и вознаграждается оно неожиданными преимуществами — энергией, чувством принадлежности к большому и важному делу, благодарностями от учеников или менти. Это всё — про блага нематериальные. Но для тех, кому важно вносить свой вклад в наше ламповое айти-сообщество, такие бенефиты — желанная награда.

Анастасия Егорова — фронтенд-разработчица с 8+ годами опыта, ментор, автор телеграм-канала кофе и код и авторского youtube-канала по фронту:

Стоит ли айтишнику идти в преподавание? Короткий ответ: да, если вам нравится обучать. Мне самой всегда хотелось преподавать, но чаще всего я делала эту работу дополнением к основной. Во-первых, я всегда с большим доверием относилась к преподавателям-практикам, во-вторых, классическая работа в моем случае приносила больший доход.
Я начинала с работы наставником на курсах, отвела несколько потоков обучения HTML, в мои обязанности входила проверка домашних заданий и консультации студентов по непонятным вопросам. Это была интересная, но совсем низкооплачиваемая работа. Я ушла оттуда через несколько месяцев, но некоторые из моих студентов до сих пор поздравляют меня с праздниками и благодарят за помощь в обучении. А я смотрю, что они стали сильными разработчиками, и радуюсь.
Далее я писала тексты лонгридов-уроков для ещё одной онлайн-академии, мы обучали JavaScript. После этого попала в одну школу программирования, там составляла программу учебного курса по Vue.
После этого были вебинары, где мы со студентами писали приложения на Vue в прямом эфире, а в конце-концов это вылилось в мой личный канал на YouTube с обучающими видео.
Такой подход даёт мне много энергии, мне нравится делиться своими знаниями, объяснять фронтенд простыми словами. Радует, когда на IT-мероприятиях ко мне подходят и благодарят за проведённые вебинары и видео на канале. Если вам интересно преподавание — пробуйте обязательно!

Преподавание даёт чувство сопричастности и внутреннюю мотивацию, особенно тем, кто хочет строить сообщество и формировать стандарты рынка.

Углубление собственных знаний

Объяснения другим усиливают вашу экспертизу и выводят на новый уровень понимания своего дела.

Серёжа Попов, Product Owner в Skillaz и член ПК FrontendConf уверен, что участие в образовательных проектах — одна из важных вех в развитии айти-специалиста:

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

Григорий Петров, директор по техническому маркетингу в Evrone, делится своим опытом:

Последние несколько лет я пишу новый учебник по Python (да, это настолько долго), в этом мне помогают ~300 энтузиастов, которые читают новые главы и делятся обратной связью. За время общения с ними я смог сформулировать для себя многие вещи о программировании гораздо лучше, чем за предыдущие 30 лет коммерческой разработки. Для меня преподавание — это в первую очередь возможность самому стать лучше, как программисту. Всё остальное идет бонусом: пиар, нетворк, возможность сделать мир программирования чуть лучше.

Владимир Бурмистров, главный системный аналитик в Иннотех, считает: чтобы действительно хорошо преподавать — нужно иметь не только желание, но и предрасположенность.

Важно понимать, что преподавание, как и любая другая профессиональная деятельность, требует регулярности — вы будете делать одно и то же много раз. Чтобы сделать хорошую лекцию, надо постоянно готовиться.
Преподавание может приносить дополнительные деньги, прокачать ваши навыки презентации, подачи, объяснения. И просто углублять уже имеющиеся навыки при проработке материалов. Минус — это время.
Большинство айтишников далеки от образования, и им надо всё это осваивать с нуля, либо же быть плохим преподавателем. Нужно ли идти? Да, нужно, но не стоит ждать каких-то супербыстрых результатов. Некоторые становятся менторами, а у них для этого нет навыков и расположенности. Менторить надо уметь — это тоже целая наука. Крутой сеньор — не равно хороший преподаватель.

Александр Бындю @AlexanderByndyu, основатель Byndyusoft, автор книг «Антихрупкость в IT» и «Карты гипотез», считает, что именно диалог с учениками помогает посмотреть на задачи и проблемы отрасли с новой стороны.

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

Дети — ещё один вызов

Директор студии Монтировка Валера Линьков прошёл все «круги» преподавания — школа, колледж, институт, курсы для взрослых.

Вопрос в том, какие у человека цели и ценности. У обучения в школе будет несколько нюансов. Например, при работе с детьми развязность не подходит. Вы всегда должны быть оплотом, серьёзным человеком в пиджаке, который всегда очень грамотно и сдержанно ответит.
Вторая особенность в том, что детей вы не столько обучаете именно технологии и правилам работы с технологией, сколько увлекаете чем-то интересным. То есть, нужно не показать, как классно работает Python, а заинтересовать ребёнка в том, чтобы он изучал этот Python самостоятельно. Потому что в противном случае, он у вас просто ничего не выучит. Третья особенность школы — всё упирается в ЕГЭ, и натаскивать детей нужно именно по нему.
У колледжей особенность в том, что преподавателю нужен очень твердый характер. Потому что в колледже учатся в основном люди, которые ещё не взрослые, но уже не дети. Они ищут себя, пытаются попробовать весь мир разом. Поэтому первое, чем надо будет заниматься, будучи преподавателем там, это держать серьёзную дисциплину. Образовывать каким-то новым вещам — уже следующая по важности задача. Если мы говорим про институт, там уже нет вопроса дисциплины, зато есть вопрос науки. Там есть определённые паттерны, которые, например, в айтишке очень важны, а в образовании, в науке — вообще нет.
Я попробовал себя в разных амплуа, чтобы понять, каким образом буду взаимодействовать с разными людьми. Я — не тот человек, который жёстко воспитывает дисциплину, и не тот, который будет жёстко натаскивать на ЕГЭ. Ну и при всем при этом я не тот человек, который с диким пиететом относится к науке. Как раз этих трёх недостающих элементов мне и не хватает для того, чтобы стать хорошим преподавателем в классическом смысле.
На курсах же нужен скорее прикладной опыт. Это как раз история о том, чем ты готов поделиться с миром, насколько можешь грамотно изложить свои знания, привести интересные примеры, помочь другим разобраться и ответить на вопросы. Поэтому преподавание на курсах — как раз про тот опыт, который ты можешь передать более молодым коллегам.

Вывод

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

• Объясняя другим, вы лучше понимаете себя.
• Делясь опытом, вы формируете сообщество, в котором потом захотите работать.

Поэтому если чувствуете, что готовы — не ждите идеального момента. Преподавание — это лучший способ проверить, насколько вы сами выросли.

Уже 24 сентября Наталия совместно с ведущим специалистом в области конфликтологии Андреем Кёнигом проведут воркшоп с разбором типичных и нестандартных конфликтов в работе DevRel-менеджеров, включая истории самих участников.

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

— Наталия, расскажи пару слов о себе.

— В настоящий момент я консультирую компании по стратегии DevRel и специалистов по карьерным вопросам. Ещё преподаю на курсе OTUS и помогаю стартапам, чьи продукты ориентированы на разработчиков. Когда узнала про новый сезон конференции Онтико, предложила тему, и программный комитет принял мой воркшоп в программу.

— Расскажи, о чём будет твой доклад. Что вообще ждёшь от конференции?

— У меня противоречивая тема. Многие не любят говорить про конфликты или стараются считать себя неконфликтными людьми. Я к ним тоже отношусь. Но наша работа связана с взаимодействием с очень большим числом людей, в том числе из смежных подразделений. Хочешь ты или нет, конфликтные ситуации неизбежны. И многие страдают из-за этого. Но мало кто знает, что на самом деле далеко не каждая критическая ситуация конфликт. А ещё меньше людей знает, что на самом деле конфликты могут быть очень полезны.

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

— То есть речь идёт именно о конфликтах со смежными подразделениями в нескольких компаниях?

— Не совсем так. Например, DevRel-менеджер часто выступает в роли проектного менеджера по коммуникациям. Для организации любого проекта или мероприятия ему приходится взаимодействовать с большим числом смежных подразделений. Это могут быть разработчики, тимлиды, дизайнеры, юристы, финансисты, hr-ры, маркетологи — в зависимости от структуры компании.

— И именно на стыке этих взаимодействий возникают трудности?

— Да. Здесь могут быть самые разные конфликты; рабочие, но сложные ситуации — от несовершенства в системе до личностного недопонимания: кто-то что-то не успел, кто-то кого-то неправильно понял. При этом очень часто мы сами становимся не исполнителями, а менеджерами, и отвечаем за процессы. И очень часто — за такие, на которые напрямую повлиять сложно. Поэтому конфликты в этой работе неизбежны.

— Приведешь примеры наиболее типичных конфликтов?

— Например, спор с PR, чей Хабр :)

Это один из главных инструментов DevRel. Пиар-служба тоже понимает, что это важный канал коммуникации, и считает, что он должен быть под их контролем. Но у них есть своё видение — исходят из логики массовых коммуникаций, работы с журналистами, внешнего имиджа компании. А мы в DevRel-направлении настаиваем, что для аудитории разработчиков важно быть максимально открытыми. Надо публиковать не только статьи, которые соберут десятки тысяч просмотров, но и узко-специализированные полезные профессиональные материалы от наших коллег. Важно говорить не только о позитивных сторонах, но и прорабатывать негативные стереотипы или признавать ошибки. Мы этого не боимся, а вот PR боится. Именно на этой границе часто возникает конфликт.

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

Предположим, мы строим сообщество или сотрудничаем с независимым сообществом. Хотим укрепить идентичность, приверженность комьюнити к бренду, ценностям, общим элементам культуры; способствовать самовыражению; повышать вовлеченность участников. Мы обратили внимание на то, что в сообществе родился и хорошо разлетелся мем про «свод код ближе к телу» и пожелание сделать «трусы с символикой сообщества». Да, культура сообществ может быть очень «разной». Но маркетинг это категорически не пропускает, потому что для них это нарушение правил бренда. В итоге такие ситуации становятся источником конфликта: мы хотим быть ближе к сообществу, а маркетинг стоит на страже имиджа.

Мы упираемся в ситуацию: нам нужно, а маркетинг говорит «нет». Конфликт ли это или рабочая ситуация, будет зависеть от компании и людей. Но чаще — это конфликт.

— А бывают ли подобные ситуации и с другими подразделениями?

— Конечно. Например, наша работа предполагает коммуникацию между разработчиками компании и внешним сообществом. Мы готовим специалистов к выступлениям, помогаем им писать статьи, участвовать в профильных активностях. Но и тут может возникнуть сопротивление. Представьте: сверху приходит задача — «пусть разработчики выступают». А тимлид отвечает: «Я не хочу, чтобы они выступали. Это отвлекает их от основной работы — написания кода». В результате появляется конфликт интересов: мы настаиваем на публичной активности, а руководитель команды считает её лишней нагрузкой.

Наша задача — мотивировать и поддерживать разработчиков, которые сами хотят писать статьи. Но бывает, что тимлид против. Ситуация может оказаться и более острой, когда тимлид чувствует угрозу бизнес-процессу, где конфликт заложен системой KPI, когда у тимлидов и DevRel-менеджера совершенно разные и взаимоисключающие цели. Появляется угроза авторитету, если руководителю кажется, что его сотрудник станет “звездой” и “подсидит его” или уйдет. Или есть уже недоверие к работе DevRel, так как в прошлый раз не было быстрого результата и пр.

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

— А как вообще объяснять разработчикам и их лидам, что оно того стоит — выступать, писать статьи? Как аргументировать, на какой профит делать акцент?

— Тут всё зависит от ситуации. Есть разные варианты мотивации и разные задачи. Если руководитель поддерживает активность, то убедить команду гораздо проще. Если же он говорит: «Я не против, договаривайся сам», — тогда приходится работать напрямую с разработчиками.

В таком случае важно правильно описать задачу и объяснить, зачем всё это делается. Мы можем исходить из того, что это пиар компании. А дальше включаются разные мотивационные «ключи». Например, если руководителю нужно нанимать людей, то наши аргументы к его мотивации: публичные выступления команды помогают привлечь кандидатов и сделать задачи команды более заметными. Если же у лида найм не стоит на повестке, ищем другие аргументы. Главное — подобрать тот мотив, который для человека будет значимым.

— А какая мотивация выступать или писать статьи может быть у разработчиков?

— Можно сказать: «слушай, во-первых, это помогает структурировать знания. Во-вторых, это вклад в личный бренд — и внутри компании, и во внешнем профессиональном сообществе». Если в команде уже есть люди с таким опытом, они понимают ценность и соглашаются быстрее. Для новичков это шанс проявить себя и получить поддержку от команды.

— Но ведь многим сложно начать, особенно если это первый опыт.

— Именно поэтому очень важно, чтобы разработчик не оставался один на один с задачей написать статью или подготовить доклад. Это должно быть не обязанностью, а частью выстроенного процесса, который помогает. У кого-то это реализуется через внутренние сообщества, но я больше за процессный подход. Если разработчик говорит: «Я может и хотел бы, но не знаю, о чём писать», — процесс должен подхватывать его и помогать двигаться дальше.

— А что делать, если разработчик вроде бы не против написать статью или подготовить доклад, но сам не знает, о чём?

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

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

— У тебя есть какой то пайплайн, как готовить спикера, который ещё не выступал на конференции?

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

Здесь важно определить, чего именно он боится. Мы можем вместе посмотреть доклады прошлых лет, чтобы появились идеи. Обсудить с его командой, накидать возможные темы. У меня часто есть контакт с программными комитетами конференций — я могу уточнить у них, интересны ли такие темы, стоит ли их подавать. Это снимает лишнюю тревогу.

Мы объясняем: будет несколько прогонов, будет шаблон презентации и помощь дизайнеров. Если есть ресурсы в компании, то для спикеров проводятся тренинги по публичным выступлениям и подготовке презентаций. Никто не кидает человека сразу на большую сцену. Можно начать с внутреннего доклада, небольшой встречи или даже модерации панели. Постепенное вхождение даёт уверенность и делает процесс менее пугающим.

— А если вернуться к конфликтам: часто ведь руководство не хочет отпускать людей на конференции. Это же командировка, выпадают несколько дней, плюс время на подготовку. Как с этим быть?

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

Сначала руководители могут сопротивляться, но постепенно меняют мнение. Когда они видят, что коллеги разрешают выступления, их сотрудники становятся более мотивированными и довольными, а сами команды — более заметными и привлекательными, то понимают, что это работает на результат. Тогда у CTO или команды постепенно начинает меняться мышление в эту сторону. Это не всегда происходит быстро — иногда требуется время, но результат заметен.

— А если посмотреть шире — какие компании более открыты к таким практикам, а какие менее? Есть разница между стартапами и крупными корпорациями?

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

С крупными компаниями, особенно из реального сектора, которые пришли к цифровой трансформации относительно недавно, ситуация сложнее. Некоторым компаниям может потребоваться несколько лет, чтобы наладить процесс. Сначала придется преодолевать сопротивление со стороны служб безопасности и PR, которые категорически не готовы пускать простых разработчиков к публичным коммуникациям. Но постепенно накапливается пул собственных успешных кейсов, приходит понимание, что пользы больше чем опасности, присматриваются к успешным референсам с рынка и конкурентов и … закрытая вчера корпорация приносит 10-15 докладов на конференцию для разработчиков.

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

— Ты говорила про конфликты с PR, брендом, маркетингом. Как их разруливать? Особенно когда они упираются и не хотят, например, выделять бюджет или делать то, что тебе нужно. Как донести свою позицию?

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

Если ты понимаешь, что твою работу и запрос поддерживает авторитетный заказчик или топ-менеджер, то сопротивление PR или бренда снижается. Можно прямо сказать: «Это нужно не только мне, это нужно вот этому человеку». И тогда вопрос решается быстрее. Бывают ситуации, когда после слова ключевого руководителя все тут же меняют позицию и делают то, что до этого категорически отвергали.

Мы можем закладывать бюджет в разные «кубышки» — бюджеты разных направлений, тех, кто заинтересован в DevRel. Но в любом случае, когда работаешь со смежниками, нужно быть готовым к компромиссам и к аргументации.

Если приходишь в компанию, где раньше этим не занимались, придётся долго перестраивать процессы. И это нормально. Не стоит думать, что проблема в тебе. Просто система может быть сложной, «тягучей», ей нужно время. В одной компании изменения идут быстрее, в другой — медленнее. Иногда бывает так, что два года приходится спорить по поводу бюджета, доказывать свою приоритетность, преодолевать сопротивление или даже конфликтовать. Но происходит эффект накопления, когда все понимают: бюджет надо выделить, и можно сразу в распоряжение DevRel, а не в маркетинг или HR-бренд.

— А как быть, если один топ-менеджер полностью тебя поддерживает, а другой — равного уровня — наоборот, против? И начинается конфликт уже между ними?

— Это очень хороший вопрос. У меня был похожий кейс: два сильных руководителя, и между ними возник серьёзный конфликт. Здесь важно понимать, что это не твой конфликт — это их конфликт, в который тебя пытаются втянуть.

Нужно разводить процессы. Если один из топ-менеджеров тебя поддерживает, можно сконцентрироваться на работе с ним, приносить пользу его направлению и не вовлекаться в противостояние. Есть подразделения, которые уже понимают важность этой работы, а есть те, которые ещё «не дозрели». Работать стоит с теми, кому это реально нужно. А если решение зависит сразу от двух лидеров, пусть они договариваются между собой — это их зона ответственности. То есть управленческие конфликты должны решаться на управленческом уровне, а не на твоём. Такой алгоритм.

— Звучит логично. А можешь посоветовать какие-то книги или ресурсы для тех, кто только начинает работать? Может, что-то по конфликтам или коммуникациям? Какие навыки вообще нужно прокачивать?

Начнем с последнего вопроса. Нужно быть:

– психологами, чтобы успешно взаимодействовать с разными людьми, уметь вдохновлять и поддерживать, убеждать и соглашаться, задавать правильные вопросы,

– проджект-менеджерами: уметь поставить правильно задачу, планировать ресурсы и бюджет, выстроить процесс и организовать мероприятие, владеть разными методологиями проектного управления.

– маркетологами и пиарщиками, потому что надо использовать маркетинговые инструменты, каналы, форматы, приемы и аналитику.

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

— А как прокачивать коммуникации, особенно в части договорённостей и конфликтов?

— Здесь важно общее понимание конфликтологии. Например, у моего содокладчика Андрея Кёнига есть отличный четырехдневный тренинг. Там не просто рассказывают теорию, а глубоко отрабатывают ситуации на практике: что такое конфликт, что им не является, какие бывают уровни и причины конфликтов, когда стоит отстаивать позицию, а когда нет.

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

— А в каких случаях всё-таки стоит идти в конфликт? Ты говорила, что иногда конфликты бывают полезны.

— Конфликт — это противостояние двух или более сторон, когда им выгодно оставаться в этом состоянии. Есть несколько признаков. Во-первых, у каждой стороны должна быть своя выгода от противостояния. Во-вторых, ни одна из сторон не готова выйти из него. В-третьих, у сторон есть что делить. И, наконец, в-четвёртых, у сторон есть что терять.

— Вот для меня DevRel — это когда ты всегда на стороне разработчиков, отстаиваешь их интересы в любом случае?

— Абсолютно. Те, кто работает с инженерами, должны отстаивать их интересы, иначе принцип взаимодействия ломается. И ещё важнее, чтобы людям было комфортно с тобой работать.

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

В итоге, виноват деврел. Хотя объективно это несправедливо. Это системный конфликт: дизайнер может снизить оценку на ревью, потому что якобы деврел не сумел выстроить процесс так, чтобы избежать форс-мажора. С другой — процесс должен учитывать реальность: дизайнеру может действительно придётся работать в последний момент. Потому что разработчики часто отдают презентацию в последний момент — так это работает.

Часто лучший вариант — нанимать дизайнеров прямо в DevRel-команду или хотя бы именно на ваши задачи. Тогда дизайнер понимает специфику: его роль не в том, чтобы «творить», а в том, чтобы быстро доработать презентацию разработчика перед выступлением. Такой процесс честнее и эффективнее.

— Насколько, на твой взгляд, DevRel-специалисту важно выстраивать личные хорошие отношения со всеми контрагентами, с которыми работаешь?

— Всё зависит от стиля человека. Есть те, кто любят со всеми пить кофе, быть «котиками», и вроде все их любят. Но потом они недоумевают, почему на ревью вдруг появляется негативный отзыв. А бывают люди очень системные, которые не тратят время на неформальные отношения, зато у них всё чётко выстроено, и даже при минимуме общения с разработчиками работа идёт отлично.

Хорошие отношения, конечно, важны — я всегда за них. Но если конфликт назревает, а это пока не ваш конек, то полезно подключить медиатора, и это работает быстрее.

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

— Получается, хорошие отношения всё же важны?

— Безусловно. Человек не должен быть токсичным, он должен обладать позитивной энергией и харизмой, уметь благодарить. В нашей работе это особенно важно: даже если разработчик просто сделал свою работу, всё равно нужно сказать «спасибо». Это элементарно, но многие забывают или не находят на это времени. Хорошие отношения важны, но степень их глубины зависит от стиля самого человека.

— Мне казалось, что в профессиях с Rel в названии, отношения — это ключ.

— Тут важно различать два контекста. Одно дело — отношения как часть коммуникации. Когда мы выстраиваем диалог с разработчиками вовне, речь идёт о прозрачности, честности, постоянстве в коммуникации. Мы должны давать качественный контент, пользу, быть последовательными — и это тоже про отношения.

А другое дело — личные, «дружеские» отношения: когда всем нужно давать социальное поглаживание, поддерживать в неформальном ключе. И вот тут уже многое зависит от культуры компании. Где-то это уместно, где-то корпоративный стиль более сдержанный. Поэтому отношения не стоит понимать исключительно как дружелюбие. Это прежде всего правильная коммуникация.

Если хотите глубже разобраться в работе DevRel, научиться выстраивать взаимоотношения с техническими специалистами и зажечь в них жажду выступать и появляться в сообществе — приходите на DevRelConf #9.Там будем разбираться со всеми аспектами работы DevRel, чтобы приносить пользу инженерам и классно делать свою работу!

Кого опрашивали

Мы опросили 145 человек, из которых:

• 45.5% оказались разработчиками,
• 11% — тимлидами и техлидами,
• 6.9% — айти-авторами или редакторами,
• 6.9% — аналитиками,
• 5.5% — продакт- или проджект-менеджерами,
• 4.8% — маркетологами,
• 3.4% — CEO компаний,
• 3.4% — контент-менеджерами,
• 2.8% — SMM-специалистами,
• 2.8% — дата-сайентистами и ML-инженерами,
• 2.1% — дизайнерами или иллюстраторами,
• 1.4% — деврелами или техпиарщиками,
• 0.7% — SEO-оптимизаторами.

Большинство опрошенных или 18,5% работают в бигтехе, на втором месте — 13,7% — аутсорс, 12.1% – финтех, 9.7% — госкомпании, 8.9% — фриланс, 8.1% — стартапы, 5.6% — эдтех и ещё 23.4% отметили категорию другое.

Среди опрошенных большинство имеют грейд мидл — 43.8%, сеньоров — 25.7%, джуниоров – 17.1%, менеджеров — 9.5%, собственный бизнес – у 3.8%.

Более половины или 52,4% не развивают личный бренд, 28,6% — задумываются об этом, а 19% активно этим занимаются.

При этом 18.6% пишут статьи для развития личного бренда, 17.8% ведут блоги, 17.1% ничего не делают, 11.6% преподают, 10.9% менторят, 7.8% выступают с докладами, 5.4% занимаются наукой. Ещё 3.9% ответили, что пишут книги, аналогичное количество ведёт подкасты, ​​3.1% — участвует в хакатонах.

Как используют ИИ при создании контента

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

«Ищу фреймы с нужным мне функционалом, которых я не знаю или знаю, но не применял ранее. То есть без кода, а в качестве источника идей. Также ИИ служит для автоматизации рутины в коде: простые циклы или простейшая логика, максимум 10-15 строк, пока я пишу что то другое».

«Если попросить его написать какие то атомарные короткие блоки, методы, функции, то ИИ неплохо справляется».

«Нейросеть может накинуть идеи, дать свежий взгляд на проблему, помочь с рутинным переписыванием кода. В контексте AI-агентов — под тщательным присмотром, чтобы избежать последствий галлюцинаций».

«Очень удобный инструмент для быстрого преодоления входного порога в новую тему. С помощью ИИ удобно анализировать статьи, узнавать базовые определения, быстро решать технические проблемы в языке программирования, с которым пока сам мало знаком. Однако нужно быть аккуратным при попытках создавать что-то новое и сложное — на мой взгляд, ИИ здесь не заменит учёного».

15.5% — генерирует с помощью нейросетей идеи, 11.4% — создают иллюстрации. 9.4% — обращаются к ИИ для саммаризации. 8.5% — для расшифровки аудиозаписей, 7.6% — для переводов, 6.7% — при редактуре статей, 5.3% — для создания постов, 4.7% — для написания статей, 3.2% — для создания презентаций, 2% – для видео-контента, 1.5% — для сео-оптимизации. 4.4% отметили, что вообще не используют ИИ, а 3.8% — что используют, но для каких-то других целей.

Среди других целей отмечали создание баннеров и логотипов, фреймов постов, подбора «цепляющих» заголовков:

«Беру у ИИ идеи для креативного описания и каких-то интересных цепляющих фраз. Это просто новый уровень в работе, новая эра».

Большинству респондентов нравится Chat GPT — 32.6%; Gemini выбрали 8.7%; Gigachat и Yandex GPT набрали поровну, по 7%; Midjourney и DeepL — по 6.5%; Kandinsky — 3.9%; Dall-E2 — 3%; RoBERTa — 0.9%.

23.9% отметили, что предпочитают другие нейросети. Среди них — Deep Seek (особенно популярен среди собственных вариантов респондентов), Claude (на втором месте по популярности), Grok (на третьем месте), Sonar и Qwen (обе на четвёртом). Также опрошенные назвали Cursor, v0.dev, Gemma, ollama, Perplexity, Kling, Luma DM, SD1.5, Sora, Suno, Шедеврум.

Хотя с последним опыт респондентов был неоднозначным:

«Т.к. “тестировала” Шедеврум, получаемый в результате контент выходит спорным: не все условия учитываются, тяжело работает со специфичными запросами (или вообще не понимает их), бывают непонятные артефакты или нарушение построения (анатомического и пр.)»

Отношение к ИИ в контенте

Подавляющее большинство относится к нейросетям скорее хорошо. 72.1% опрошенных отметили положительное отношение к ИИ при условии, что он «используется с умом», ещё 21.3% отметили, что считают ИИ — эффективным и современным инструментом.

При этом 4.9% были категоричны и отметили, что относятся негативно или даже запрещают использовать ИИ сотрудникам. Ещё 1.6% не используют сами и обязательно пишут негативный комментарий, если замечают признаки использования.

Из негативных аспектов 33.1% опрошенных отмечают галлюцинации нейросетей.

«Не стоит доверять всему что выдаёт ИИ, так как зачастую для хорошего ответа нужно задать правильный и детально расписанный вопрос. И если уж пользоваться ИИ для решения каких-либо задач, то нужно всё равно проделать двойную работу, чтобы проверить ответ, который впоследствии ты будешь записывать куда либо (в код, статью, подкаст и т.д.)».

«Нормально использовать его, если есть опыт применения и знаешь, где ИИ может накосячить. Перепроверяешь за ним такие места».

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

1) Плохой промпт = плохой результат

2) Даже при хорошем промпте нейросети склонны всё равно ошибаться и врать. Был случай, когда разработчик просто скопипастил в код прода пример псевдокода из документации, который оптимизировался нейросетью. Надо ли говорить, что всё закончилось производственным фиаско… развитие нейронок подразумевает, что нужно самому развиваться еще быстрее и быть на шаг впереди, чтобы быть в состоянии грамотно анализировать и фильтровать то, что они выдают».

21.6% критикует ИИ за странный стиль и метафоры. 18.4% считают, что видят, когда текст писал робот и им неприятно. Среди менее очевидных неприятностей, связанных с ИИ: 11.4% называют ограничения использования из-за санкций/импортозамещения, 9% — цену подписки, 5.7% — личное недоверие к ИИ.

«Если говорить в общем, контент, генерируемый ИИ, всегда лишён личного начала. Да, где-то торчат уши автора (автора промта). Но и всё на этом. Примерно как: президент озвучил идею , что неплохо бы поддержать семью… А дальше, ну вы сами знаете. То есть, для генерации творческого контента ИИ — инструмент так себе. Среднего уровня оруэлловский станок для написания романов.

Другое дело — техническая писанина и код. Вот тут ИИ на своем месте. Но всё же, нуждается в тщательном контроле на всех этапах работы. Свою нишу ИИ в контенте занял, и ему есть, куда расти, но ведь это просто инструмент. А он не может быть совершеннее своего изобретателя. Тема ИИ — не творчество в широком смысле. Его удел — техническая часть».

У некоторых опрошенных сама ценность ИИ вызывает сомнение — они считают, что явление слишком переоценено:

«ИИ используется уже много лет в совершенно разных сферах. Но когда он стал доступным массовому пользователю, начал невероятную войну хайпа. Теперь каждая продуктовая компания должна внедрить ИИ в свой продукт. Открывается огромное количество стартапов, которые собирают деньги только благодаря наличию двух букв “AI” в своём названии. Контент, сгенерированный с помощью ИИ, просто завалил интернет.

Дело в том, что написанный ИИ текст, программный код, либо сгенерированная картинка или видео видны сразу, что понижает ценность этого контента (по моему мнению). Я считаю, что если есть желание использовать ИИ в создании контента, то нужно, чтобы ты его делал с помощью ИИ, а не ИИ делал его с твоей помощью. Через какое-то время хайп пойдёт на спад, контентмейкеры и компании найдут баланс в использовании современных ИИ технологий и именно тогда он начнет приносить наибольшую пользу человечеству. На данный момент ИИ генерирует 80% хайпа и 20% пользы, а должно быть, как минимум, диаметрально противоположная картина. P.S. все цифры и заявления, приведенные в этом комментарии, не основаны ни на каких исследованиях, чисто на моих ощущениях».

Ряд опрошенных беспокоит, что ИИ отучает нас, то есть человечество, мыслить:

«Люди, заменяющие человекодумательные функции использованием ИИ, часто демонстрируют собственные проблемы с когнитивной функцией. Сам контент вызывает чувство приедания и ещё к концу прошлого года любой контент от ИИ не вызывал никаких положительных эмоций. К коду, сгенерированному ИИ, неприязни пока не испытывал. Люди, которые юзают кодогенерацию для учебных целей — возвращаемся к началу, имеют проблемы с когнитивкой. Используйте ИИ только если он помогает вам начать думать. Никогда не используйте ИИ, чтобы завершить то, о чём уже начали думать».

В целом, многие респонденты сходятся в мысли, что ИИ здорово ускоряет создание контента, но требует работы над стилем, чтобы сделать его более человечным:

«Удобный и полезный инструмент. Но нужен навык, чтобы им пользоваться. Нейросети могут довольно быстро выдать вариант “на 4”. Чтобы получилось “на 5”, нужно приложить немало усилий. Ну и я вижу, что студенты пытаются делегировать 100% домашки нейронкам и очень удивляются, когда их в этом разоблачают».

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

Как минимум, большинство опрошенных не считают ИИ-контент — злом:

«Не считаю, что ИИ-контент — это что-то ужасное, Как и не думаю, что «мертвый интернет» придёт в скором времени, но надеюсь на повышение качества такого контента, либо на ограничение его показов».

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

«С нейросетями так же как с автомобилями: использовать можно, а иногда даже необходимо, но нужны правила и те, кто проверяет и наказывает за несоблюдение. Пока что в мире бардак. Кто, как смог, собрал себе какие-то драндулеты и катается по городу, пугая прохожих 🙂».

А как используете ИИ в контенте вы? Пишите в комментариях!