Эта статья может пригодиться тем, у кого есть пет-проект с открытым исходным кодом, который хочется продвигать, но нет опыта работы с коммуникациями. Меня зовут Ксения Романова, по образованию я PR-специалист, работала в маркетинге, затем в Developer Relations. Сейчас я менеджер по работе с IT-сообществами в Positive Technologies, организатор DevRel-завтраков и член программного комитета DevRel Conf. Предыдущие шесть лет я работала с глобальным сообществом, построенным вокруг распределенной базы данных с открытым исходным кодом Apache Ignite. Поделюсь опытом, как найти тех, кто полюбит проект, какие инструменты позаимствовать у маркетинга и как измерить результат. Обычно ресурсы команд небольших проектов ограничены, поэтому я собрала много «точек» в коммуникации, приложив минимум усилий к которым, можно получить максимальный эффект.
Статья написана по мотивам доклада на Highload++ 2023, а если вы предпочитаете видео, то посмотреть запись можно здесь.
Концентрировать усилия на тех, кто полюбит проект
Командам, которые делают опенсорс, сообщество очень нужно: оно даёт обратную связь и дополнительные руки, а ещё увеличивает стоимость компании, если бизнес-модель предполагает продажу платного продукта или сервиса, основанных на опенсорс-коде. В общем, комьюнити — полезный ресурс, который упрощает разработку и CustDev и даже приносит деньги. Но люди приходят в сообщество не для того, чтобы приносить пользу чужому бизнесу. Посмотрим на сообщество со стороны его участников.
Представьте себе, что идентичность разработчика — это виртуальная футболка с символическим изображением всех групп людей, с которыми он тесно общается. Очевидно, что даже если зарисовать всё пространство футболки, как комбинезон пилота Формулы-1, место на ней ограничено. Причина — число Данбара. Это гипотетический предел количества стабильных социальных связей, которые человек может поддерживать одновременно. Более подробно про это можно прочитать в статье самого Данбара и в публикации с критикой этой статьи.
Предположим, у человека есть круг близких людей, с которыми он общается постоянно, и круги менее близких, но постоянных связей. Например, этот гипотетический разработчик входит в состав спортивной команды, поддерживает отношения с бывшими однокурсниками, еще с кем-то играет в настолки или ходит в походы. На «футболке социальных связей» осталось не так много места, за которое технологическим сообществам приходится конкурировать не только друг с другом, но и с остальными социальными связями.
На футболку попадут сообщества не всех технологий, которые разработчик знает. И даже не всех, которыми постоянно пользуется. Мой опыт показывает, что больше всего шансов оказаться на воображаемой футболке Данбара у технологий…
Связанных с профессиональной идентичностью. Это технологии уровня «Я — джавист», «Я — игнайтер», «Я — коммитор Kafka» и так далее.
Способствующих достижению целей. Их использование и общение вокруг них помогают человеку реализовывать свои цели — например, стать классным профессионалом, сделать карьеру и так далее.
Продолжительное время влияющих на самоощущение. Милая библиотека, где можно нажать кнопку «Сделай хорошо» — и она сразу сделает, не оставит такого следа в нашем сердце, как технология, которую мы долго и, возможно, мучительно куда-нибудь встраивали, изучали или писали.
Получается, что не все могут стать фанатами конкретной технологии. Даже если продукт классный и бесплатный, попасть на футболку Данбара — не просто. Поэтому эффективнее будет не пытаться убедить всех разработчиков мира вступить в сообщество, а сконцентрироваться на тех, кто вероятнее полюбит продукт.
Настроить коммуникации в разговорах с воображаемыми людьми
Найти свою аудиторию помогут «персоны». Когда-то маркетологи использовали метод персон для продажи шампуня или стирального порошка. Потом приспособили этот приём для IT и стали представлять себе персону разработчика, который покупает или использует конкретные инструменты или технологии.
По сути персона — это персонификация группы людей, обладающих сходными характеристиками. Всем нам удобнее общаться по схеме «человек — человек», а не «компания — сегмент аудитории». Персона покупателя, используя этот эффект, помогает лучше представить собеседников и настроить коммуникацию с ними.
Персона разработчика создаётся на основе реальных данных. В этом помогают опросы, точечные интервью с людьми, которых хотелось бы больше видеть в сообществе, парсинг профилей пользователей в GitHub или других источниках.
К персоне нужно добавлять только те характеристики, которые действительно влияют на поведение в нужной области. Персон должно быть не больше, чем значимых различий в характеристиках, которые есть возможность учитывать в коммуникации.
Если карточка получится слишком подробной или персон получится слишком много, значит, на начальном этапе что-то пошло не так. Важно, чтобы на выходе получился рабочий инструмент, а не полное социологическое описание. Вот как может выглядеть такая карточка:
Лучше меньше, но лучше. Скорее всего, ресурсов на то, чтобы качественно охватить все возможные сегменты аудитории, у маленького проекта не будет. Продуктивнее выбрать несколько самых интересных сегментов — пользователей конкретной технологии, работников конкретной отрасли или людей на определённом этапе карьеры — и плотнее поработать уже с ними.
Важно учитывать и «негативную персону». Создание образа людей, с которыми нет желания взаимодействовать, поможет сберечь силы и не тратить их на заведомо неэффективную коммуникацию. Слушайте тех, кто помогает вам двигаться вперед, а не тех, кто громче говорит.
Многие разработчики только сегментируют юзеркейсы и останавливаются на этом. Сегментировать их нужно, но такая сегментация ничего не скажет о мотивации людей и их предпочтениях, а значит, не поможет с ними подружиться. При этом необязательно идти к дизайнеру и делать красивые карточки. Важнее рассмотреть в разных ракурсах характеристики людей, которые собираются вокруг продукта, чтобы узнать о них больше.
Интеграции — тоже часть отношений с разработчиками
Интеграции можно воспринимать как бэклог, но я предлагаю посмотреть на них скорее как на инструмент для налаживания и поддержания хороших отношений с разработчиками.
Заметнее всего роль интеграций на этапе появления проекта. Найдётся мало желающих полностью сломать свой рабочий процесс ради нового инструмента, даже самого классного. Интегрируя продукт с популярными технологиями, которыми уже пользуются, можно приобрести новую аудиторию.
Даже уже существующим и успешным проектам имеет смысл периодически выяснять, что новенького появилось. Регулярно возникают новые сегменты аудитории — например, использующие новые фреймворки и предпочитающие их всем другим.
Иногда интеграция может быть даже залогом выживания проекта. Если у какой-то компании ваш проект внедрен давно и его нужно поддерживать, вряд ли для этих целей наймут супер-синьоров. Молодые же специалисты могут сказать, что работать без своих любимых инструментов — больно. И велика вероятность, что сложный в поддержке проект вылетит из архитектуры компании.
Как вылавливать технологические тренды и оценивать их? Я советую просматривать эти три исследования: хотя они и касаются глобального рынка, но по большей части перекладываются и на локальную картину.
У каждого из исследований хорошо описана методология, и если по отдельности они ещё могут вызывать вопросы, то все вместе создают достаточно реалистичную картину происходящего.
Модель процессов в сообществе: «орбита» против «воронки»
Итак, мы нашли и сегментировали свою аудиторию. Но аудитория — это ещё не сообщество. Сообщество — это люди, которые общаются с другими людьми. Чтобы лучше представлять себе, как аудитория становится сообществом, нужна какая-то визуализация. Я использую модель «орбиты».
Почему «орбита», а не классическая «воронка»? У воронки есть два критичных недостатка:
Она очень линейная.
Она сконцентрирована на ценности конверсии.
Как только появляется воронка, маркетинг и топы компании привычно устремляются к конверсии, игнорируя процессы и задачи, связанные со всеми остальными этапами участия разработчика в сообществе.
На мой взгляд, больше подойдёт другая модель.
Маркетинг и топы прекрасно понимают «орбиту». При этом на ней легче отражать нелинейные процессы и объяснять, как важно вообще всё, что происходит: и когда человек только попадает в сообщество, и когда изучает его, и когда вступает в небольшую группу организаторов жизни сообщества.
По ссылке можно рассмотреть методологию подробнее.
Я добавила к модели орбиту 0, которой не было в исходнике. Это понадобилось, чтобы рассказывать маркетингу о «выхлопе» бюджета на контент, который требуется для привлечения новых участников.
Я распределила активности по орбитам так:
Осведомлённость: использование продукта, чтение документации и открытого контента без обратной связи.
Изучение: вопросы на форумах, подписка на новости и тому подобное.
Участие: посещение митапов, ответы на вопросы других пользователей, участие в дискуссиях.
Содействие: создание кода или контента.
Лидерство: участие в организации активностей.
Любая модель лучше её отсутствия, потому что модель — это не просто красивая картинка на слайде. Это возможность настраивать свои планы и чужие ожидания. Она помогает определиться, что именно будет считаться успехом на каждой орбите или стадии, которые проходит человек в сообществе.
А чтобы между орбитами шло движение, уже маловато подстелить соломки, нужно расстелить ковровую дорожку.
Стелем ковровую дорожку
Я не стану описывать полный цикл всего, что нужно сделать, чтобы люди захотели стать частью вашего сообщества. Приведу несколько вещей, которые, как правило, забывают делать именно в пет-проектах.
Четко описать, куда репортить баги, присылать предложения, вопросы и обращения. Главное правило — везде набор каналов коммуникации и путеводитель по ним должны быть одинаковыми. К сожалению, часто это правило не соблюдают.
Выбрать каналы, удобные аудитории. Допустим, что ядро сообщества очень любит Discord — он классный, многое умеет. Но если важный сегмент аудитории — разработчики из энтерпрайза, то у них Discord в рабочей сети обычно заблокирован как развлекательный ресурс (это одна из неочевидных причин мирового успеха Slack как платформы для общения вокруг технологий). Держим в уме, что дефолтный канал для России — это Telegram.
Подготовить онбординг для новых участников. Обычно ни у кого нет времени водить за руку новоприбывших. Зато всегда можно настроить автоматическую отправку дружелюбного письма, сообщения в чат-боте. Желательно не просто написать, куда идти или где что прочитать, но и упомянуть, как поскорее начать делать что-то совместно с другими, например посетить митап в своём городе.
Важно не забывать регулярно проверять все автоматизированные сообщения, чтобы там не было протухших ссылок и устаревших данных. Это слишком маленькая задача, чтобы держать её в голове. Поэтому держать её лучше в календаре: настроить регулярное событие — проверку автоматически рассылаемых сообщений.
Если мысленно описать идеальный путь участника сообщества от момента вступления в него (кстати, а как определить, что человек уже участник?) до момента, когда он сам становится его лидером, то обычно можно найти несколько точек, где минимум улучшений дадут наилучший эффект.
Контрибьюторы: правило Парето работает и здесь
Контрибьюторы — самое романтизированное понятие в опенсорсе. Мы часто представляем идеального контрибьютора как классного инженера высокого грейда, который многое умеет и любит продукт почти как создатель. При этом у него есть классные идеи по совершенствованию проекта, и он готов их воплотить в жизнь собственными руками. И, конечно же, бесплатно!
Посмотрим, как дело обстоит в реальности. В качестве примера взяла не чужой для HighLoad фреймворк Аpache Calcite, про который уже было несколько докладов. Проект существует 9 лет, используется в других проектах Apache Software Foundation и в нескольких крупных компаниях. За ним не стоит никакая коммерческая организация. До сих пор его ведет его создатель Джулиан Хайд — человек, который живёт в Бёркли и работает в Google. Если бы я хотела придумать что-то более стереотипное, у меня бы вряд ли получилось. Для этого проекта сейчас выпускают по 3 релиза в год, то есть он находится на плато. Но релиз-менеджер иногда меняется, а это хороший знак.
Взглянем на статистику топ-контрибьюторов за 2 года: основной вклад вносит небольшое количество людей.
Можно ли сказать, что это проблема сообщества на плато, которому 9 лет? Или сообщества, которое делает инженер Google? Нет, это абсолютно типичная картина. Авторы исследования Why Software Projects need Heroes не поленились и проверили более 1000 проектов. Выяснилось, что в 85% из них большую часть кодового вклада делает ограниченное количество людей. В своей терминологии авторы называют этих людей «героями». Это как раз разработчики, которые пишут качественный код и делают это чаще и в больших объемах, чем другие. Также оказалось, что эта тенденция не зависит от размера проекта: вклад «героев» всегда больше, чем остальных участников.
Получается, что если по оси Y провести качество кода, а по оси X — любовь к продукту, то в идеальном контрибьюторе окажется максимум того и другого.
Но таких контрибьюторов на всех не хватит. Возможно, ядро сообщества, его создатели — это и есть те самые идеальные контрибьюторы, и больше их не станет. Значит, нужны какие-то другие люди.
Джунов обычно считают проблемными: их код приходится долго проверять, а потом еще дольше объяснять, что в нем нужно исправить.
Но и высокое качество кода — не панацея. Бывает, что опытные инженеры приходят только потому, что у них что-то не работает в собственном проекте, пока они не напихают полную панамку зависимостей в чужой опенсорс. Специально для таких людей разграничивают права контрибьюторов, которые могут предложить правки, и коммиторов, которые могут их вливать.
Между этими двумя типажами, как между двумя крайними значениями шкалы, много других людей. Попробуем определить для эталонного контрибьютора минимальную степень любви к проекту и минимальный уровень качества кода. Готово? Можем начинать поиск контрибьюторов.
Определим персоны контрибьюторов.
Шире посмотрим на виды участия в сообществе. Можно привлечь людей, которые делают не только код: возможно, кто-то захочет писать документацию или делать тесты. За счет этого у людей, которые пишут код, освободятся для него руки.
Проверим комфортность процесса для контрибьютора, исправим узкие места.
Пример: как вдвое сократить переписку с новыми контрибьюторами
В Apache Software Foundation (ASF) есть особенность — общение идёт через mailing-листы. На сайте Apache Ignite годами висела инструкция, как можно предложить свой код в проект. Первый пункт гласил: напиши нам письмо на dev-лист. В какой-то момент из-за изменений в процессах со стороны ASF активистам сообщества потребовалось написать шаблон этого первого письма. Написали мы его за 15 минут и опубликовали на сайте.
После публикации шаблона остались в прошлом огромные треды с выяснением подробностей, вся информация приходит в первом письме. Но что самое интересное — писем стало больше, а это значит, что кто-то когда-то не донёс свой код просто потому, что не знал, что написать в письме после «Привет!».
Хорошая новость — почти в любом проекте, существующем больше года, есть подобные мелочи. Их легко пофиксить и получить моментальный эффект.
Еще одна мысль, которую стоит держать в голове: контрибьютор с нами не навсегда. Срок активного участия в жизни сообщества составляет приблизительно 3 года. Это значит, что как спортивные скауты всё время ищут классных игроков для своей команды, так и ответственному за развитие сообщества специалисту нужно постоянно подбирать классных новых участников и сразу знакомить их с лидерами. Так передаётся культура, чтобы смена «поколений» происходила постепенно и плавно.
Зачем люди приходят в сообщества вокруг технологии
Принадлежность и идентичность. Крепкие социальные связи нужны не только тем, кто хочет попасть на «футболку Данбара», но и обладателям этой футболки.
Поддержка в достижении целей. Это может быть небольшая цель — успешно запустить проект, или пока неочевидная — стать признанным экспертом в отрасли, выступать на конференциях и поднять свою стоимость как потенциального сотрудника.
Уменьшение сопротивления среды. Что можно сделать вместе такого, что человек не может сделать один? Например, написать идеальную базу данных, изменить стандарты индустрии или даже решить какую-то социальную проблему. Зависит от специфики проекта.
Допустим, у создателей пет-проекта нет времени настраивать автоматические сообщения, рисовать персоны, внедрять модели, а есть только возможность посидеть с ручкой и бумажкой полчаса. Тогда эти полчаса стоит потратить на поиски того, что человек не может получить нигде кроме вашего сообщества, и именно это подсветить. То есть найти то, на что человек готов обменять своё время, экспертизу и ресурс на поддержание социальных связей.
Маркеры здоровья сообщества
История была бы неполной, если бы мы не поговорили про то, как измерять успех в построении сообщества.
Почему маркеры здоровья, а не метрики? Маркеры помогают отследить тенденции, понять, как на длинной дистанции сработали те или другие действия. Метрики же вызывают нездоровый ажиотаж у менеджмента и маркетинга, им сразу хочется получить абсолютные цифры, докрутить их до небес, сделать из них KPI. Принцип тот же, что и в случае выбора модели описания процессов — избежать стереотипов, которые могут повредить результату.
Если использовать маркеры для сравнения разных проектов, важно учитывать не только технологическое сходство, но и контекстуальное — сравнивать проекты, которые похожи:
по стадии зрелости;
по активности разработки;
по количеству контрибьюторов;
по маркетинговой поддержке.
Маркеров, которыми я пользовалась в работе с сообществом Apache Ignite, всего 12. Я разделила их на 3 группы.
Маркер здоровья — 1: популярность
Речь про видимость сообщества среди других:
Загрузки, если в конкретном случае информация о них доступна.
Вопросы на Stack Overflow.
Вакансии — если публикуются вакансии, требующие знания этой технологии, значит, она действительно помогает в карьере разработчика и есть компании, где технология используется.
Профили или резюме на LinkedIn с упоминанием технологии — обратная сторона предыдущего пункта.
Маркер здоровья — 2: активность
Это больше интересно для сравнения проекта с конкурирующими:
GitHub Forks.
Использование кода в других проектах.
Вопросы в официальных каналах сообщества.
Количество регистраций и участников на ключевых мероприятиях.
Маркер здоровья — 3: общение
Показатели, которые говорят об укреплении связей между людьми:
Качественные обсуждения продукта и его дальнейшей судьбы в каналах сообщества.
Новые и повторные участники регулярных активностей.
Новые и повторные контрибьюторы — знак переходов между орбитами.
Активность ядра сообщества — отслеживаем, не пора ли хантить новых людей.
Конечно, такой набор подойдёт не всем. Какие-то маркеры могут быть в зоне ответственности продуктового маркетинга, что-то не подойдет совсем новым и пока маленьким проектам; не будем забывать и о локализации. Пусть этот набор будет примером и поводом поискать маркеры, подходящие к конкретной ситуации.
Выводы
Не все могут стать фанатами технологии. Даже если продукт классный и бесплатный, попасть на «футболку Данбара» разработчиков не так просто. Это значит, что лучше сконцентрироваться на тех, у кого больше шансов полюбит проект.
Важно иметь представление о том, что человек знает и умеет, какие у него проблемы и ценности, как он решает сложные ситуации. Тогда коммуникацию можно настроить так, чтобы она сработала на отбор «своих людей».
Встраиваясь в workflow разработчика, вы повышаете шансы попасть в его набор инструментов. Даже уже существующим и успешным проектам имеет смысл периодически выяснять, что новенького появилось, чтобы удерживать популярность.
Любая модель лучше её отсутствия, потому что модель — это возможность настраивать свои планы и чужие ожидания.
Между идеальным путём участника сообщества и реальностью всегда можно найти небольшие расхождения, исправив которые, можно существенно улучшить ситуацию.
Контрибьюторов всегда меньше, чем хотелось бы, поэтому есть смысл рассмотреть компромиссы и по формату участия, и по его качеству.
В большинстве своем участники сообщества не остаются активными надолго, и готовить смену действующим лидерам нужно постоянно, чтобы передавать культуру сообщества.
Если из всех перечисленных действий есть время и возможность сделать только что-то одно, лучшим выбором будет найти в сообществе что-то, на что человек будет готов обменять своё время, экспертизу и когнитивный ресурс.
Маркеры здоровья помогают отследить тенденции и понять, как на длинной дистанции сработали те или иные действия. Для проектов в разной ситуации нужны разные наборы маркеров.
Полезные материалы
Книга: Создание свободного ПО
Книга: Open Source. Разработка программ с открытым исходным кодом
Книга: Сила сообществ
Книга на английском: The era of community-driven business
Фреймворк для работы с сообществами Canvas (на русском)
EGSP
Годная статья, за ссылки отдельное спасибо