Привет! Меня зовут Женя Голева, я занимаюсь developer relations с 2016 года, и постоянно вижу профессиональных чатах холивары о нашей работе. Люди спорят, кто такие деврелы, кто занимается не деврелом, а какие виды деврелов наоборот имеют право на существование и очень нужны в команде. 

Ответы на многие похожие вопросы уже есть — в книге Мэри Тенгвал “The Business Value of Developer Relations”.  Я заручилась поддержкой автора и издательства-правообладателя и перевела главу “Building a Developer Relations Team / What’s in a name?” для русскоязычного сообщества. У вас впереди 10 коротких и ёмких разделов про цели и задачи всей команды Developer Relations на старте и в процессе развития, про то, какие роли и специализации могут быть востребованы на разных этапах, что кандидатам необходимо знать и уметь на входе, а что — вовсе не обязательно и можно добрать в процессе работы.

Эта статья будет полезна в первую очередь тем, кто хочет разобраться в специфике направления developer relations: если вы СТО или СЕО, то вам скорее будут полезны первые несколько разделов и последний, если вы уже занимаетесь деврелом или очень хотите начать, здесь будут ответы на вопросы, как войти в профессию или куда в ней развиваться дальше.

Разделы главы

1. Developer Relations Team

2. Developer Relations Manager

3. Developer Advocate

4. Technical Community Builder

5. Developer Experience Manager

6. Technical Ambassador

7. Technical Engagement Manager

8. DevRel Project Manager

9. Full-Time Engineer

10. Who’s First?

1. Команда по выстраиванию отношений с разработчиками (Developer Relations Team)

В названии прямо указано, что команда работает с конечными пользователями или покупателями (технологии). [На российском рынке более распространено взаимодействие с "покупателями компании" - потенциальными кандидатами, прим. переводчика.] Это отличие помогает формулировать цели команды и не брать на себя работу других отделов. Члены команды DevRel являются признанными в сообществе экспертами в заявленной области.

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

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

Если вы начинаете небольшой командой, то начните с базовых вещей, необходимых для работы:

• хорошая документация,

• великолепная поддержка,

• бесплатные доступы для разработчиков.

Когда эти задачи будут завершены и перестанут требовать много внимания, можно начать формировать площадку для сообщества, где вы сможете:

• собирать примеры использования кода/продукта,

• выкладывать SDK,

• создавать группы суперпользователей или чемпионов,

• спонсировать open-source проекты и проекты самого сообщества,

• публиковать общую информацию о бренде,

• выкладывать выступления и многое другое.

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

2. Руководитель команды: Менеджер по выстраиванию отношений с разработчиками (Developer Relations Manager)

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

За что же отвечает DevRel менеджер?

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

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

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

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

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

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

3. Технический эксперт: представитель интересов разработчиков (Developer Advocate)

Название Developer Advocate отвечает на два главных вопроса сообщества:

• Какая у тебя квалификация?

• Что ты делаешь?

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

Помните, я упоминала в главе 3 про представительство компании перед сообществом и, наоборот, представлении сообщества перед компанией? Большую часть этой работы делают технические эксперты (Developer Advocates). Именно они больше всего лично общаются с аудиторией разработчиков, когда выступают на конференциях, работают на стендах и в интернете через форумы, слак, разные сайты и соцсети. Часть из этих платформ будут корпоративными, но большую часть времени технические эксперты будут проводить в каналах, управляемых сообществом, а не компанией.

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

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

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

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

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

4. Массовик-затейник: строитель технического сообщества (Technical Community Builder)

Эта роль традиционно называется “менеджером сообщества”, но я сознательно использовала в названии слово “строитель”.

На то есть две причины:

1. Такое название позволяет избежать путаницы.

2. Из этого названия становится кристально ясно, для чего предназначена эта роль: строить техническое сообщество вокруг существующего продукта.

Несмотря на то, что в названии должности есть слово “технический”, эта роль схожа с менеджером по связям с разработчиками (DevRel Manager) в том, что человеку не обязательно иметь опыт разработки; с другой стороны, есть и важное отличие: эту роль должен выполнять тот, кто хочет и может разобраться с техническими основами.

Один из самых ценных навыков заключается в том, чтобы быть “массовиком-затейником”: знать нужных людей в сообществе, а также тех коллег внутри компании, к кому следует отправлять членов сообщества с вопросами и сложностями. Этот человек — главный владелец процессов, систем и любых других конструкций, созданных вокруг поддерживаемых сообществ. Это может быть публичный форум, Slack, закрытая группа ключевых пользователей или чатик самых активных участников сообщества (создателей контента, контрибьюторов в GitHub и т.д.), за каждой кулисой стоит создатель сообщества.

Именно они следят за тем, чтобы всё работало как задумано, стоят на страже кодекса поведения (Code of Conduct), ищут потенциальные связи между участниками сообщества и разными сотрудниками вашей компании и делают многое другое. Кстати, тут можно подумать о метриках позитивного первого контакта и мягкой передачи потенциальных клиентов сейлзам.

Строитель сообщества (Community Builder) вместе с техническим экспертом (Developer Avdocate) коллекционируют уникальные кейсы из разговоров в сообществе, собирают информацию о возникающих проблемах, потенциальном контенте или возможностях сделать с кем-то совместный проект.

5. Менеджер по (пользовательскому) опыту разработчиков (Developer Experience Manager)

Пользовательский опыт разработчика критически важен для успеха вашего продукта. Это один из трёх вопросов, которые мы задавали в главе 2, чтобы классифицировать ваши цели в DevRel. Я поставила эту роль сразу следом за тремя основными, потому что как только ваша команда начнет расти, а сообщество — масштабироваться, вам тут же понадобится ответственный за пользовательский опыт.

Пользовательский опыт разработчика — краеугольный камень всего продукта, но, по мере роста команды, люди начнут углубляться в свою специализацию, и вы не захотите их регулярно дергать на базовые вопросы. Этот менеджер владеет пользовательским опытом разработчика от начала и до конца. У них может не быть подчиненных (пока команда не станет достаточно большой, и не возникнет такая потребность), но они будут контролировать каждый кроссфункциональный проект, который затрагивает пользовательский опыт разработчика: от UX и дизайна сайта до документации и SDK.

Человек в этой роли не обязательно отвечает за непосредственную реализацию, но именно они будут отвечать за то, чтобы работа в этой области выполнялась плавно и своевременно. Менеджер по пользовательскому опыту разработчиков (Developer Experience Manager) следит за тем, чтобы документация была осмысленной и понятной клиентам (я поклонник этой матрицы документации от Даниэля Прочиды). Они приглядывают за инструкциями “Приступая к работе” (Getting Started) и общим пользовательским опытом, а также играют ключевую роль в метрике “время окупаемости”, упомянутой в главе 4.

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

6. Технический амбассадор (Technical Ambassador)

Я намеренно называю этих людей абмассадорами, а не евангелистами. Слово “евангелист” вызывает религиозные ассоциации и может порождать негативные коннотации в разных странах. Иногда это может помешать даже зайти на порог некоторых компаний, что уж говорить о создании доверия. Гай Кавасаки в 80-х годах, продавая ранний компьютер Macintosh, популяризировал термин “евангелист”, концепцию евангелизационного маркетинга и технологического евангелизма.

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

С другой стороны, термин Технический амбассадор (Technical Ambassador) отличает эту роль от Технического эксперта (Developer Advocate) и делает этого человека послом доброй воли от имени компании.

На первый взгляд, эта роль очень похожа на Технического эксперта (Developer Advocate). Но эта роль больше про продажи, чем про сообщество. Технические амбассадоры (Developer Ambassador) прекрасно выступают на больших сценах и продают не только продукт, но и саму важность этого продукта для всего технического сообщества в целом. Технические эксперты (Developer Advocate) легко входят в контакт с инженерным сообществом и продают продукт, который облегчает работу инженера. Тогда как Технические амбассадоры (Developer Ambassadors) показывают руководству компаний важность продукта в долгосрочной перспективе.

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

Эта роль лучше всего подходит для новых направлений в технической индустрии (например, революционная услуга “email servers as a service” от SendGrind или культурная революция DevOps), когда нужно не только рассказать сообществу про бренд компании, но и объяснить, какую проблему решает продукт, и кому он вообще нужен.

7. Менеджер по вовлечению инженеров (Technical Engagement Manager)

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

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

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

Они могут отвечать только за постинг и верную интонацию для технарей, а могут и сами писать весь контент для каналов, заточенных под техническую аудиторию. Снова обращаю внимание, что функционал каждого специалиста зависит от специфики вашей компании и существующих ресурсов. Если у вас уже есть гениальный сммщик, способный вовлечь инженеров в разговоры, то ему может понадобиться только помощь технического эксперта (Developer Advocate), чтобы они подсказали авторитетных членов сообщества или ключевых контрибьюторов (подробнее об этом написано в главе 3).

8. Менеджер DevRel проектов (DevRel Project Manager)

Так как эта универсальная роль подходит примерно любым направлениям работы команды DevRel, я совершенно намеренно поместила эту роль в мир управления проектами. Википедия даёт очень четкое определение управления проектами:

“Дисциплина по инициированию, планированию, выполнению, контролю и закрытию работы команды для достижения конкретных целей и критериев успеха в указанное время.”

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

В зависимости от размера вашей команды, эта роль может проявляться по-разному.

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

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

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

9. Штатный инженер (Full-Time Engineer)

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

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

Эти же люди напишут специальное приложение для мероприятия или инструмент для автоматизации некоторых DevRel процессов, и вам не придется выпрашивать время разработчиков продукта. Многие крупные компании переходят на такой формат работы: Google и Twitter, Oculus и RiotGames имеют штатных инженеров в DevRel командах. Именно они дежурят во время конференций, чтобы починить свою демку, если она сломалась прямо на сцене.

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

10. Кого нанять первым? (Who’s First?)

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