Привет, Хабр!

Сегодня поговорим про стратегию Go‑to‑Community вместо Go‑to‑Market. Звучит конечно круто, но суть простая: перестать видеть разработчиков только как лидов в воронке продаж и начать работать с ними как с сообществом на равных, с созданием ценности для всех.

Go-to-Market vs Go-to-Community: в чем разница?

Для начала небольшой ликбез. Go‑to‑Market (GTM) это традиционный подход вывода продукта на рынок. Маркетологи гонят рекламу, собирают лиды, ведут их по воронке (от узнавания — к интересу — к триалу — к покупке). Цель GTM — захватить максимальную ценность (value capture) из аудитории: сконвертировать как можно больше людей в клиентов и продажи. Вы наверняка такое видели.

Go‑to‑Community (GTC) — альтернативный (и дополняющий) путь. Проще говоря, вместо того чтобы на каждом шаге пытаться выудить из аудитории пользу для себя, мы сначала создаем ценность вместе с сообществом и для сообщества. Мы привлекаем вокруг продукта широкое техническое коммьюнити, даже тех, кто прямо сейчас ничего не купит и не принесёт денег. Пусть люди учатся, обмениваются знаниями, придумывают интеграции, помогают друг другу, а там, глядишь, со временем часть из них созреет и до продаж. Да и не только продажи важны, лояльное сообщество будет поддерживать продукт, создавать контент, рекомендовать его коллегам. Маркетинг ловит лишь тех, кто готов купить, а комьюнити охватывает всех, кому интересна тема продукта, и вовлекает их на своих условиях.

GTC не противоречит GTM, а дополняет его. Никто не отменяет воронку продаж, просто параллельно выстраивается воронка сообщества, и они должны работать синхронно. Идеальный сценарий: обе стратегии согласованы, и участники сообщества постепенно переходят в разряд лидов, когда придёт время. Пока же они остаются в комьюнити, получают там пользу и сами вносят вклад. Если же стратегии разрознены, то конечно будет перекос. Либо вы бескорыстно вкладываетесь в комьюнити без всякой выгоды для компании (отличная благотворительность, но бизнес это долго не выдержит), либо зациклены на продажах и игнорируете остальных фанатов продукта (упускаете кучу возможностей и сами того не зная отталкиваете людей). Нужно равновесие.

Ставку на сообщество делают многие успешные технологические компании. В 2021-м сразу несколько «единорогов» с сообществом в ДНК вышли на IPO, вспомним хотя бы GitLab, HashiCorp, Duolingo. Они смогли превратить комьюнити вокруг своих продуктов в реальный драйвер роста и выручки. Например, у HashiCorp открытое сообщество не было чем‑то второстепенным, оно с первых дней определяло архитектуру продуктов, монетизацию и всю стратегию компании.

Выходит, Go‑to‑Community не благотворительность, а инвестиция. Маркетинг приносит рост до определённого предела, дальше без сообщества не выехать. Разработчики больше доверяют друг другу, чем рекламе, любят сами пробовать и учиться. Поэтому стоит задача создать среду, где люди получают ценность: знания, поддержку, возможность влиять на продукт. Тогда сообщество само станет вашим маркетингом.

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

Роли в сообществе и их цепочки ценности

Допустим вы решились сместить фокус с агрессивного маркетинга на комьюнити. Возникает вопрос: «А что вообще из себя представляет мое сообщество? Кто эти люди и как с ними работать?» Ошибка в том, чтобы считать комьюнити однородной массой. На самом деле внутри есть несколько ролей. Люди по‑разному взаимодействуют с вашим продуктом и вносят разный вклад. В этой статье выделим три роли: мейнтейнеры, интеграторы и эдьютейтеры (расскажу, что имеется в виду). Для каждой опишем её мотивацию и цепочку ценности, то есть, какую ценность эта роль приносит проекту и что сама получает взамен.

Мейнтейнеры (Maintainers) – хранители кода

Если ваш продукт связан с open‑source или имеет бесплатное ядро, наверняка есть люди, отвечающие за поддержание и развитие этого проекта, помимо вашей команды. Это и есть мейнтейнеры: разработчики, которые на постоянной основе вкладываются в код, ревьюят чужие контрибьюты, следят за качеством. Чаще всего это либо сотрудники компании, либо ключевые внешние энтузиасты, заслужившие доверие.

Их главная цель сделать проект лучше для всех пользователей. Мотивация обычно техническая и идеологическая: мейнтейнеры хотят, чтобы продукт решал их (и не только их) задачи эффективно, был надежным, соответствовал видению. Часто они сами начинали этот проект или присоединились, потому что горят этой технологией.

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

Ценность для мейнтейнера: а что ему с этого? Разные люди находят разную выгоду. Кто‑то просто решает свои задачи. Кто‑то прокачивает навыки, строит карьеру в опенсорсе, статус мейнтейнера известного проекта дорогого стоит на рынке труда. Кто‑то получает моральное удовлетворение и уважение коллег. Иногда бывают и прямые выгоды: компания может спонсировать ключевых мейнтейнеров, донатить им, приглашать на конференции.

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

Как работать с мейнтейнерами: прежде всего, уважать и признавать их вклад. Ваша комьюнити‑стратегия должна явно давать мейнтейнерам место и голос. Простые шаги: регулярно благодарить публично, давать статус (например, звание Core Contributor, доступ в приватный Slack с командой). Прислушиваться, звать в совет проекта, собирать фидбэк перед релизами. Предоставить ресурсы: может быть, вы поможете им с инфраструктурой для тестирования, оплатите облако, пришлёте мерч. Сюда же со‑creation активности: проводите кодовые спринты вместе с мейнтейнерами, брейнштормьте фичи. Если есть возможность, выделите бюджет на гранты или part‑time контракты для особо ценных мейнтейнеров. Словом, встроите их в свою ценностную цепочку: мейнтейнеры дают проекту свой труд, а компания возвращает им поддержку и возможности. Тогда они будут еще больше заинтересованы развивать продукт, и вокруг них подтянутся другие контрибьюторы.

Интеграторы (Integrators) – двигатели экосистемы

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

Ценность для компании: интеграторы — те самые люди, которые находят новым технологиям реальные применения. Они показывают, как продукт вписывается в разные use‑case, часто в связке с другим софтом. Например, кто‑то сделал открытый коннектор, чтобы ваша платформа работала с Kafka, и вот у вас целый новый сценарий использования для целой группы потенциальных клиентов. Интеграторы фактически расширяют рынок вашего продукта, создают вокруг него экосистему. Многие SaaS и платформы выстрелили именно благодаря сообществу, написавшему кучу плагинов и интеграций (взять ту же VS Code, тысячи расширений написаны внешними девелоперами). Кроме того, интеграторы часто становятся адвокатами продукта: раз они встроили его в своё решение, то будут убеждать и других в его ценности. Они же первыми ловят узкие места API, дают глубочайший фидбэк, могут помочь ответами на форумах.

Ценность для интегратора: эти ребята обычно решают прикладные задачи. Их главный профит — рабочее решение проблемы. Если ваш продукт помог закрыть потребность — интегратор уже выиграл. Но сверх того: интегратор вкладывает время, чтобы проектировать архитектуру, писать код интеграции, и ему важно, чтобы усилия были оценены. Например, если он сделал плагин, видеть, что сообщество им пользуется, получить звезд на GitHub, благодарности, может даже клиентов. Многие интеграторы по совместительству партнеры в бизнес‑смысле. Компания‑разработчик может направлять клиентов к сертифицированным интеграторам для внедрения. Тогда интегратор зарабатывает как эксперт. Либо вы откроете свой Marketplace расширений и разрешите авторам монетизировать плагины. Либо хотя бы упомянете их кейс в блогах/на конференциях, что приносит признание. Короче, интегратору важно, чтобы его работа была востребована и приносила ему выгоду, будь то деньги, репутация или новые возможности.

Как работать с интеграторами: в первую очередь, облегчить им жизнь технически. Документация, стабильные API, SDK — это база. Сделайте отличные примеры интеграции, опишите case studies, чтобы новым людям было проще повторить успех. Создайте каналы связи: технические каналы поддержки специально для интеграторов (Slack/форум с инженерами). Хороший ход запустить программу партнеров/интеграторов. Например, HashiCorp помимо сообщества юзеров имеет сеть системных интеграторов и облачных провайдеров, которые обучают и поддерживают новых клиентов. Их вовлекают: дают материалы, возможно, сертификации. Да, кстати, сертификация важный мотиватор. Если интегратор может получить статус «Certified Expert по продукту X», он с большим энтузиазмом погрузится (HashiCorp выдала уже 20k сертификатов через свою обучающую платформу). Не забудьте про витрину успехов: рассказывайте о решениях, которые делают интеграторы. Например, раздел на сайте «Built with OurProduct», чтобы все видели, какие крутые штуки делают люди. И, конечно, обратная связь: регулярно спрашивайте интеграторов, что улучшить. Может, проведите совместный co‑creation спринт: соберите самых активных внедренцев и ваших инженеров, и за пару дней допилите вместе интеграцию с популярным инструментом — они принесут экспертизу домена, вы — ресурсы разработки.

Эдьютейтеры (Edutainers) – евангелисты и учителя

Третья важнейшая группа — люди, которые обучают и вдохновляют остальных пользователей. Назовем их условно эдьютейтеры (от education + entertainer): авторы статей, туториалов, докладчики на митапах, ютуберы, создатели курсов. Про них часто говорят «Developer Advocates», «Evangelists», но мы сейчас имеем в виду внешних энтузиастов, не штатных деврелов компании. В каждом активном сообществе находятся личности, которые обожают рассказывать другим, как пользоваться технологией, делиться своим опытом, упрощать сложное.

Ценность для компании: эти люди — настоящие мультипликаторы знаний. Благодаря им даже небольшой проект может получать непропорционально широкое внимание. Написал кто‑то толковый гайд на медиуме и сотни новых разработчиков узнали о вашем инструменте. Записал обзор на YouTube, тысячи посмотрели и заинтересовались. Контент от сообщества бьет все рекорды доверия: он независимый, «от такого же разработчика, как я». А если у вас ещё и своя площадка для контента… DigitalOcean выезжает на том, что тысячи авторов публикуют обучающие статьи на их платформе, кучу туториалов создали эту экосистему знаний вокруг продукта.

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

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

Как работать с эдьютейтерами: находить и вдохновлять их. Выявляйте активных авторов в сообществе: кто пишет блоги, отвечает на Stack Overflow, делает демо‑проекты. Начните с простого: репостните их статью в своих соцсетях, похвалите в рассылке. Дайте почувствовать, что компания видит их вклад. Далее можно формализовать. Многие запускают программы амбассадоров. Например, HashiCorp запустила HashiCorp Ambassador Program, сейчас там 100+ человек со всего мира. Отбор по критерию: делится знаниями, помогает другим, проявляет экспертизу. Амбассадоры получают официальный статус, мерч, а главное эксклюзивную инфу: брифинги о новых релизах, превью фич, закрытые сессии с командой. Это отличный стимул для эдьютейтеров, они чувствуют себя инсайдерами, первыми узнают новости и могут готовить контент заранее. Плюс им просто приятно быть в клубе причастных. Ваша задача — сделать так, чтобы создавать контент по вашему продукту было легко и выгодно. Предоставьте материалы: готовые презентации, демо‑проекты, библиотеку изображений. Запустите конкурс статей или хакатон по созданию туториалов, с призами и публикацией лучших работ. Организуйте мероприятия, где эдьютейтеры смогут выступить: митапы, вебинары. Поощряйте их рост: может, кто‑то из них созреет стать официальным Developer Advocate в вашей команде — прекрасный вариант рекрутинга из сообщества.

Подытожим сегментацию: в сообществе есть разные роли, и у каждой своя цепочка ценности. Мейнтейнеры улучшают продукт и получают поддержку и признание. Интеграторы расширяют сферу применения продукта и получают решения для своих задач (плюс статус экспертов и, возможно, бизнес‑возможности). Эдьютейтеры распространяют знания и получают аудиторию и благодарность. Эти цепочки переплетены: обучающие статьи привлекают новых интеграторов, хорошие интеграции разгружают мейнтейнеров от просьб о фичах, мейнтейнеры дают материал для новых статей и так далее Наша задача как DevRel‑стратегов — поддерживать баланс, чтобы каждый тип участников чувствовал: вклад окупается, ему есть смысл дальше участвовать. Для этого пригодятся специальные методики, о которых далее.

Методы DevRel 2.0: value chain mapping, persona-jobs, co-creation

Когда мы поняли, кто наше сообщество и что ценно для разных людей, стоит применить несколько инструментов. Расскажу о трех: community value chain mapping, persona‑jobs и co‑creation спринты.

Community Value Chain Mapping – карта ценности сообщества

Звучит мудрено, но идея простая: картирование цепочки ценности означает явным образом расписать, как каждая роль в сообществе создает ценность и получает её обратно. Фактически, мы частично это сделали выше в описании ролей. Зачем нужна такая карта?

Чтобы убедиться, что нигде не образуется разрыв. Если обнаружим, что какая‑то группа дает ценности больше, чем получает (или наоборот — много получает, но мало отдает), можно внести коррективы в программу работы с комьюнити.

Как это сделать на практике: возьмите роли (персоны) — мейнтейнер, интегратор, эдьютейтер. Для каждой нарисуйте две колонки: «Что он дает проекту» и «Что проект (компания) дает ему». Подробно перечислите пункты. Например:

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

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

• Эдьютейтер дает: контент (статьи, доклады, примеры кода), обучает новых юзеров, увеличивает охват аудитории, снижает нагрузку на техподдержку. Получает: популярность в сообществе, прямую благодарность от аудитории, эксклюзивный доступ к информации, мерч/призы, карьерные возможности.

Если выяснится, что интеграторы у нас очень ценны, а мы им почти ничего не предлагаем, надо думать, как увеличить для них отдачу. Или наоборот, мы всем дарим мерч и даём статус амбассадора, а толку от человека ноль, надо условия изменить, требовать минимальный вклад. Эта же карта ценности помогает обосновать руководству бюджет на комьюнити‑программы: вы показываете, какую работу выполняет каждая группа пользователей, и что нужно вложить, чтобы это продолжалось. По сути, value chain mapping переводит мягкое «строим отношения» в понятный бизнес‑язык «мы инвестируем X и получаем Y ценности». В open‑source мире такой подход уже применяется для оценки устойчивости проектов, упоминается создание «симбиотической цепочки ценности», где участники взаимно выгодно связаны.

Рекомендую пересматривать карту ценности хотя бы раз в год. По мере роста сообщества могут появляться новые роли (например, отдельным сегментом выделятся дизайнеры или студенты), добавляйте их в карту. Так вы не упустите новую аудиторию. Кроме того, на основе этой карты удобно строить метрики: если знаете, что ценность дает, скажем, количество написанных комьюнити‑статей, можете отслеживать этот показатель и целенаправленно его растить инициативами.

Persona-Jobs – объединяем портреты и задачи

Теперь о методе persona‑jobs. Он объединяет классический подход персонажей (persona) с фреймворком Jobs‑to‑be‑Done (JTBD, «работы, которые хотят выполнить пользователи»).

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

Мы берем нашу персону — например, «Интегратор Игорь» (можно даже придать образ: архитектор 35 лет, в большой компании, отвечает за внедрение технологий). Выписываем, какие у него Jobs‑to‑be‑Done относительно нашего продукта. Допустим интегрировать библиотеку в существующую систему без простоев; убедиться в безопасности решения для продакшена; обучить команду пользоваться новым инструментом; и тому подобное Для каждой такой задачи укажем, что ему помогает или мешает. Возможно, у Игоря боль в нехватке документации по масштабированию, или бюрократия на согласование новых технологий.

Проделав это, мы увидим, как лучше помочь интеграторам: например, сделать whitepaper «Как убедить менеджмент внедрить OurProduct» или добавить раздел доки про безопасность. Точно так же делаем для мейнтейнера Марины (job: привлечь новых контрибьюторов, автоматизировать релизы, и так далее) и эдьютейтера Евгения (job: быстро разбираться в новых фичах, получать благодарную аудиторию, иметь доступ к примерам из реальной практики, и так далее).

Персона сама по себе фокусируется на кто наш пользователь, каков его контекст и мотивы. А Jobs‑to‑be‑Done фокусируется на что пользователь пытается сделать и почему. Вместе они позволяют выйти за рамки стереотипов. Например, если смотреть только на персону «DevOps инженер, 5 лет опыта, такого‑то возраста», мы можем упустить, что конкретно ему нужно от нашего сообщества. А если смотреть только на абстрактный «job: получить ответ на вопрос по настройке CI/CD», упустим контекст, новичок это или эксперт, как он предпочитает учиться (читать, смотреть видео, задавать в чате?). Persona‑JTBD гибрид учитывает и то, и другое.

В итоге получаем очень интересные инсайты. Например, выясняется, что молодые разработчики (персона: Студент Саша) хотят прокачать навыки (job: найти pet‑проект и ментора). Тогда вам стоит запустить для них программу стажировок в опенсорс‑проекте сообщества или выделить «good first issues». А, скажем, Solution‑архитекторы в компаниях (персона: Архитектор Антон) хотят делиться экспертизой (job: выступать на конференциях, чтобы признали). Значит, их можно вовлекать модераторами вебинаров, авторами гостевых постов, то есть давать площадку для самореализации в рамках вашего комьюнити.

Применять persona‑jobs можно на этапе планирования DevRel‑инициатив. Собираетесь сделать хакатон, подумайте, для каких персон и каких «jobs» он вообще нужен. Закрывает ли он задачу мейнтейнера (например, собрать новых контрибьюторов)? Или нацелен на эдьютейтеров (дать им показать свой проект)? Если не понимаете, для кого стараетесь, возможно, мероприятие получится пустым. А когда явно видишь: для такой‑то персоны решаем такую‑то задачу, успех измеряется легко.

Co-creation спринты – совместное творчество с комьюнити

Последний метод — co‑creation спринты, то бишь совместные короткие циклы разработки/творчества с участием сообщества. Идея навеяна дизайн‑спринтами и хакатонами, но с упором на совместную работу команды продукта и внешних участников. Если перевести дословно — спринты с со‑творчеством. Это могут быть разные форматы:

• Community Hackathon, классика: вы объявляете тему (например, расширения для вашего API), собираете команды из внешних разработчиков и своих менторов, и за выходные они пилят готовые проекты. В отличие от обычного хакатона, здесь важно участие ваших инженеров бок о бок с комьюнити — это ломает барьеры «разработчик vs компания». Все становятся коллегами на пару дней.

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

• Feedback/Design Sprint — это когда сообщество участвует в проектировании новых фич. Например, у вас назрел большой релиз, проведите двухдневный спринт с наиболее вовлеченными пользователями и мейнтейнерами. В первый день соберите боль и хотелки (что нужно улучшить, какие use‑case не покрыты), во второй совместно приоритизируйте и набросайте макеты решений. Можно даже прототипировать вместе.

• Content Sprint, похож на докатон, но шире по форматам. Например, объявляете «Writing Sprint» на неделю: каждый день даёте тему (пн — установка продукта, вт — кейсы интеграции, ср — разбор ошибок и тому подобное), участники пишут небольшие заметки или снимают скринкасты. В конце недели готов целый пакет контента от сообщества для сообщества.

Ключевое в co‑creation спринтах это не соревнование (как часто бывает в хакатонах), а именно сотрудничество. Здесь уместно убрать соревновательность и делать упор на общий результат. Как в Open Source, все коммитят в один проект. Роли можно распределять: кто‑то кодит, кто‑то тестирует, кто‑то пишет документацию. Это очень сплочает. Люди чувствуют: «Мы вместе сделали что‑то крутое, и наш вклад встроен прямо в продукт/доку/базу знаний».

Эффект от таких спринтов потрясающий. Во‑первых, куча полезных артефактов, новые фичи, улучшенные доки, примеры, плагины. Во‑вторых, вы выращиваете новых лидеров: тот, кто блеснул на спринте идеей или решением, потом наверняка станет еще активнее в сообществе. В‑третьих, это привлекает внимание более широкой аудитории, результаты спринта можно анонсить, хвастаться, мол вот, сообщество вместе с нами сделало релиз. Для участников co‑creation это тоже реклама и признание.

Планируя co‑creation sprint, четко обозначьте цель и формат. Люди должны понимать, что на выходе. Желательно ограничить время (не более недели, а лучше 1–3 дня). И обязательно отпразднуйте результаты, финальный демо‑день, список всех авторов, сертификаты участникам, сувениры, словом, отметьте вклад каждого. Тогда в следующий раз желающих будет ещё больше.

Конечно, полностью заменить классический маркетинг на одну только работу с сообществом не получится. Да и не нужно. Правильный шаг — интегрировать GTC и GTM. Например, KPI маркетинга и DevRel должны быть взаимосвязаны. Сообща решайте, как перевести рост активности в сообществе в бизнес‑метрики: «community members → leads → клиенты».

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

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

Чтобы превратить GTC из концепции в работающий процесс, присмотритесь к курсу OTUS «DevRel». В программе — EVP/EJM, стратегия HR-бренда, метрики комьюнити и отчётность, контент- и event-практики, работа с амбассадорами и внешними сообществами на реальных кейсах. Если хотите понять формат обучения — записывайтесь на бесплатные демо-уроки от преподавателей курса:

• 20 ноября: «DevRel и HR на практике: формула успешных мероприятий для разработчиков». Записаться

• 25 ноября: «DevRel и HR-метрики: какие показатели будут важны стейкхолдерам в 2026 году». Записаться