developer advocate кто такой
Кто такие девелопер адвокаты, где они нужны и чем занимаются?
Выступления на конференциях по всему миру, общение с топовыми IT-специалистами и авторитет среди разработчиков — только видимая часть профессии девелопер адвоката. На самом деле все гораздо интереснее.
С одной стороны, девелопер адвокат — очень востребованная профессия. Она есть во многих крупных IT-компаниях, таких как Microsoft, JetBrains, Google. Написать полезную статью, выступить с докладом или рассказать, как лучше использовать ту или иную технологию — задачи для девелопер адвоката, и многие компании выделяют для этого специально обученных сотрудников.
С другой стороны, Developer Advocacy — довольно узкая ниша, которая напрямую зависит от деятельности компании. А порой — одной из ее команд. Например, большинство IT-компаний отлично справляются без девелопер адвокатов силами разработчиков, тестировщиков, аналитиков. Также для них работают классические модели продаж, рекламы и PR. Все потому, что результат их работы ориентирован на бизнес-аудиторию.
А что, если наша цель — профессиональное IT-сообщество: разработчики, DevOps-инженеры, QA-специалисты и прочие технари? С такой публикой не забалуешь, ведь эти люди по роду профессии привыкли сомневаться, перепроверять, не принимать импульсивных и необдуманных решений.
Представьте: в магазине электроники вам помогает консультант, с трудом читающий с ценника. Это настораживает, раздражает. Ваши вопросы совсем на другом уровне, далеко за пределами информации на ценнике, и вам нужен конкретный и понятный ответ эксперта. Так вот девелопер адвокат — как раз такой эксперт в мире IT. Это специально обученные (на самом деле, скорее, предрасположенные) люди, которые хотят и готовы профессионально делиться информацией с такими же профессионалами, искать истину и развивать отрасль.
В нашей компании есть подразделение, которое создает библиотеки и инструменты как раз для разработчиков: платформу c открытым исходным кодом и инструмент для работы с данными в Java-приложениях. И вот тут без IT-экспертов уже не обойтись. Мы называем работников этого фронта девелопер адвокатами, хотя, возможно, это и не совсем точно. В этой статье мы посмотрим из чего состоят будни специалиста такой профессии.
В целом, Developer Advocacy (можно также встретить Developer Relations) — это обособленный и специфичный вид PR, который направлен на узкую профессиональную группу (в основном, разработчики, тестировщики, DevOps). Задачи девелопер адвоката и его KPI направлены на создание контента, причем любого вида: технического или маркетингового. Это требует определенного склада ума, глубоких технических знаний и характера. Но те, кому это подходит, смогут чувствовать себя в профессии, как рыба в воде, и получать удовольствие от работы каждый день.
Пожалуй, это самая заметная деятельность девелопер адвокатов, и она действительно занимает много времени. Логика очевидна: продвигать продукт нужно там, где собирается его аудитория.
Haulmont часто появляется на крупных онлайн и офлайн IT-конференциях в России и за рубежом. Среди них — Oracle Code One в Сан-Франциско, SCALE в Пасадене, Joker в Санкт-Петербурге. Или сам организует митапы и дни открытых дверей для разработчиков. Как прошла прошлая встреча, можно прочитать здесь.
Иногда девелопер адвокат общается и с потенциальными клиентами, которые интересуются платформой, но далеки от мира IT, или студентами. В общем, говорить просто о сложном не только технически подкованной аудитории — важный навык.
Помимо выступлений, девелопер адвокат регулярно пишет материалы в блоги, твиты и комментарии. Так что грамотность, понимание логики текста и авторский стиль — это еще один не менее эффективный инструмент коммуникации, которым нужно владеть.
Недостаточно просто познакомить аудиторию с продуктом. Важно также помочь разработчику успешно освоить и применить этот продукт в работе. Порой приходится погружаться в частные случаи и вместе искать решения.
Например, пользователи Jmix и JPA Buddy используют платформу и плагин в разных ситуациях и сценариях, сравнивают их с другими технологиями. И, конечно, задают много вопросов в соцсетях, блогах и на форуме. В нашей компании девелопер адвокат помогает пользователям не в одиночку, а вместе с разработчиками и тестировщиками. Однако, отвечая на вопросы, он выполняет еще одну задачу.
Иногда пользователи просят дополнить технологию или вообще все изменить. Такие предложения могут быть конструктивными и действительно полезными. А могут и не быть — к чему тогда прислушиваться? Именно поэтому нужен девелопер адвокат, который слушает мнения пользователей, знает тренды и потребности IT-индустрии и может донести разработчикам компании действительно ценные предложения. Это сложный процесс, требующий глубокого анализа, постоянного общения с разработчиками и знания рынка. Но благодаря этой деятельности девелопер адвоката достигается правильное продвижение продукта на рынке и его развитие.
На самом деле, быть девелопер адвокатом и не разбираться в разработке можно, но сложно и не слишком эффективно. Чтобы понимать разработчиков, представлять им продукт компании и тем более помогать в нем разобраться, нужно говорить на одном языке — только так рыбак увидит рыбака. Да, работа девелопер адвокатом может быть основным видом деятельности, но часть времени все равно придется писать код и погружаться в продукт.
Обычно, когда мы ищем девелопер адвоката в нашу команду, мы ждем разработчика с определенными экстра-навыками: создавать контент, много общаться с техническими специалистами, выступать на конференциях и много читать. Кстати, о последнем.
Потребление информации занимает от трети до половины времени девелопер адвоката. А иногда и больше. У технологий и продуктов постоянно выходят новые релизы, компании проводят конференции, опытные специалисты публикуют статьи. Все как в Зазеркалье: нужно потреблять информацию «со всех ног», чтобы оставаться в индустрии. И делать это в два раза быстрее, чтобы хорошо разбираться в ней и помогать другим. Очень важно не уставать от английского, потому что большую часть времени предстоит общаться, читать и даже думать на этом языке.
Мы считаем: девелопер адвокат — прежде всего разработчик. Грейд здесь не так важен, хотя придется общаться в том числе с очень опытными специалистами. А это требует определенных знаний и склада ума.
На самом деле, девелопер адвокат — это лишь одно из направлений развития разработчика. Можно прокачивать Hard Skills и стать техлидом, или сделать шаг в сторону коммуникаций и маркетинга. И это тоже отличный путь для развития, в том числе и финансового. Все потому, что девелопер адвокат — специалист с богатым кругозором, который имеет авторитет среди других разработчиков, умеет разговаривать с публикой, знает IT-индустрию и свой продукт, пишет хорошие тексты, не устает от постоянного изучения технологий и английского языка. Если сложить все это, окажется, что таких людей действительно мало.
Ну и, конечно, девелопер давокат — это уже не профессия, а образ жизни. Если вы замкнуты, не получаете удовольствия от изучения технологий и боитесь летать на самолете, скорее всего, данное направление не для вас. Но если даже вечером в компании друзей вы любите обсудить, что выйдет в тренды среди языков программирования, или мечтаете о чем-то большем, чем создание новых фич, а еще любите изучать технологии, возможно, профессия девелопер адвоката — отличный выбор.
К сожалению, не существует универсального совета или книги «Как стать девелопер адвокатом за 10 минут». Но для начала можно завести технический блог на Хабре, выступить с докладом на конференции в своем городе и подтянуть английский. На этом пути вас ждет возможность увидеть мир, лично пообщаться с известными людьми из IT-сферы, представлять компанию на международных конференциях и много всего интересного.
А как вы видите роль девелопер адвоката и хотели бы такую работу? Поделитесь с нами в комментариях.
Тонкое искусство быть девелопер адвокатом
От переводчика: профессия девелопер адвоката появилась не так давно и почти у каждого крупного продукта или технологии есть свой адвокат, технологические компании понимают важность этого канала общения с миром. Есть такая должность и в Haulmont. Когда мы формулировали требования к вакансии, нам самим пришлось отвечать на вопрос «А что же должен делать девелопер адвокат?» И эта статья простым языком и очень исчерпывающе на этот вопрос отвечает.
Несколько лет назад я написал статью “Кто такой вообще этот девелопер адвокат?”, в которой постарался помочь людям в технической индустрии понять, что входит в эту роль. И до сих пор я получаю тонны вопросов про это в Твиттере.
В этой статье я собираюсь пролить свет на роль Developer Advocate и в этот раз приведу конкретные примеры задач и обязанностей, которые я выполняю в своей ежедневной работе в качестве Senior Developer Advocate в Microsoft, а также в качестве человека, который занимается этим с 2015 года.
Предупреждение:
Все мнения, выражаемые в этой статье, являются моими собственными и не представляют моего нанимателя или коллег.
Давайте сначала немного проясним разницу между дев. адвокатством и технологическим евангелизмом. Посмотрим на определение обоих терминов.
Девелопер адвокат и технологический евангелист
Существует некоторая путаница в понимании терминов “Дев. адвокатство” и “Технологический евангелизм”. Давайте взглянем на их определения.
Согласно википедии, понятие “Technology Evangelist” было изобретено Apple в рамках инициативы по убеждению разработчиков создавать приложения для Macintosh. Глагол “убедить” здесь очень важен, потому что евангелист должен был пытаться склонить разработчика к использованию определенной технологии, не обязательно выслушивая его доводы и не беря во внимание его потребности или мнение.
И это прямо противоположно тому, что делает адвокат!
“Advocacy” — это старая концепция, которая берет свое начало от латинского слова “advocare”, что значит “добавить голос”. Термин “advocate” происходит от старофранцузского “avocat”, что означает “законник”. Таким образом, Advocate дословно означает, “кто-то, кто ведет дело в суде”, “кто спорит о том, что что-то должно быть изменено, улучшено”.
Применительно к технологической индустрии эти два термина могут выглядеть довольно похожими, но есть маленькое различие: роль технологического евангелиста состоит в том, чтобы доносить информацию в одну сторону (только выдавать её), а роль адвоката рассматривается в разрезе двунаправленного потока информации — как выдача информации, так и её приём. Адвокат обычно заинтересован в том, чтобы выслушать разработчиков, понять их желания и предоставить наиболее подходящую помощь. Также адвокат собирает обратную связь и доносит её людям внутри компании.
Именно поэтому эти два звания должны применяться осмысленно.
Тем не менее, я хочу сделать шаг назад и обратить ваше внимание на то, что за теоретическим определением на практике всегда есть некоторые исключения из понимания составляющих этой работы. У меня есть друзья на должности “Технологический евангелист”, но то, что они делают, больше похоже, на “Дев. адвокат” (и наоборот). Что действительно имеет значение — это не должность, а то, что делается, чтобы помогать разработчикам достичь успеха.
Девелопер адвокат и маркетолог
Спроси любого адвоката о его роли — всегда получишь разный ответ, и это немного путает. Причем это обычный случай. А вы когда-нибудь задумывались, почему так? Основная причина в том, что множество компаний нанимают дев. адвоката для выполнения разных задач, от продаж и коммуникаций до (в основном) маркетинга. Почему маркетинг? Потому что компании обычно тратят от 5 до 12 процентов своего дохода на маркетинг, и, когда нужно достучаться до большего количества разработчиков, они обычно нанимают кого-то в качестве “адвоката” (или чего-то похожего), кто отчитывается отделу маркетинга и должен выполнять KPI по маркетингу и продажам. Ещё важнее в этой ситуации то, что эта роль существует вне команды разработки продукта, что может стать проблемой (поговорим об этом далее).
Не поймите меня неправильно, нет ничего плохого в компаниях, которые используют маркетинг и продажи для привлечения большего количества разработчиков, но делать это, используя зонтичный бренд “дев. адвокат”, — это оказание медвежьей услуги буквально всем. В целом, это обычно оказывается неудачным шагом, потому что не все разработчики хорошо умеют продавать (и заниматься продвижением продукта) и обычно делают это плохо. Разработчики изобретательны и креативны, но немногие обладают базовыми навыками продвижения бизнеса. Почему, вы думаете, большинство стартапов основаны как минимум двумя людьми? Если бы я был хорош в продажах и маркетинге, я бы гораздо лучше продвигал свои собственные open-source проекты, а вы наверняка даже не слышали про xlayers.dev. Так ведь?
Для того, чтобы достучаться до разработчиков, команда маркетинга должна объединять усилия с дев. адвокатами и помогать им лучше сформулировать то, что нужно донести. Почему? Потому что дев. адвокаты прежде всего сами являются разработчиками и говорят с ними на том же языке.
Во многих других случаях компании просто игнорируют настоящий смысл понятия “адвокатство”, и всё заканчивается придумыванием своего собственного определения, основанного на требованиях бизнеса. Ровно поэтому дев. адвокаты не понимают, какова их роль или какова она должна быть. Я надеюсь, что эта статья хоть как-то поможет!
Девелопер адвокат и деврел (Developer Relations)
Говоря простым языком, деврел — это зонтичный термин для команд, включающих дев. адвокатов, менеджеров сообществ разработчиков и любых других команд, в чьи обязанности входит налаживание и укрепление связей с разработчиками. Некоторые большие компании делают так же, как мы в Microsoft, включая туда команды, ответственные за документирование, мероприятия и социальные сети.
Таким образом, дев. адвокатство — крохотное подмножество деврел.
Какая у меня роль в Microsoft?
В качестве дев.адвокатов мы можем не совпадать во мнении о том, что мы делаем или что должны делать, но все согласны с одним определением:
“Наша роль — работать мостиком между внутренней командой разработки и сообществом разработчиков. Мы также защищаем мнение сообщества внутри команды”.
Перед тем, как я начну описывать свою работу в Microsoft, немного контекста: меня наняли из-за моего знания JavaScript и моих крепких отношений с сообществом JavaScript разработчиков. В настоящее время я работаю в составе команды адвокатов JavaScript. Наша команда принадлежит к деврел организации, которая является частью департамента разработки Azure в Microsoft.
Моя ежедневная работа — говорить от имени сообщества JavaScript разработчиков внутри Microsoft, быть их голосом в ходе митингов команды продукта или внутренних исследований. Во “внешнем мире” я поддерживаю и собираю обратную связь от JavaScript разработчиков, чтобы мы могли улучшить наши продукты и услуги. В общем, я помогаю JavaScript разработчикам успешно использовать Microsoft Clouds, сервисы и инструменты разработки с открытым кодом.
Вы, возможно, видите, что Microsoft постоянно поднимает планку качества для своих продуктов, и, чтобы этого достичь, компания инвестирует в разработчиков и открытый код. Поэтому миссия нашей деврел команды — помогать разработчикам достигать большего. Наша большая дев. адвокатская команда (или облачная дев. адвокатская команда, как мы ее внутри называем, поскольку помогаем команде девопс) состоит из нескольких подкоманд, которые сфокусированы на различных сообществах разработчиков, таких как Rust, Java, Python и т.д., а также на таких аудиториях, как студенты, научные работники и стартапы.
Миссия облачной команды адвокатов — завоевать сердца и умы разработчиков через честность, дух сообщества и вовлечение через технологии.
Как выглядит мой типичный день дев адвоката?
Задачи, о которых я расскажу ниже, это дела, которые “я” обычно делаю. Мои коллеги могут делать, а могут и не делать “то же самое”.
Создание контента
Я участвую в написании документации и остального контента в различных форматах, используемых инженерами по всему миру. Это может быть просто обновление существующей документации, а может быть создание полной документации, как, например, документация по Azure Static Web Apps, над которой работала моя команда совместно с командой документации Microsoft.
Другой контент включает создание и размещение уроков для разработчиков, задачек на кодирование, а также вещей “на один зубок”, которые я регулярно публикую в твиттере.
Вот пара примеров из недавнего:
Публичные выступления
Возможно, это одна из самых заметных активностей, которые приносят дурную славу дев. адвокатам. Это тоже часть моей работы: чтение технических докладов или участие в пленарных докладах на международных конференциях и выставках. В основе своей это означает быть там, где разработчики. Это также включает в себя проведение прямых эфиров, участие в подкастах и создание прочего медиаконтента.
Создание инструментария “в открытую”
Кроме работы, которую я делаю для своей компании, я также активный участник сообщества разработчиков софта с открытым кодом, и большая часть проектов, которые я делаю для своего нанимателя — это тоже софт с открытым кодом. Это значит, что моя работа ещё и помогать разработчикам успешно осваивать инструменты, которые помогают им использовать и интегрировать Azure в свои продукты и приложения. Последние инструменты, которые я делал — https://www.hexa.run, библиотеки Nest.JS для Azure CosmosDB, и Azure Storage. Можете посмотреть на все мои проекты с открытым кодом на wassim.dev.
Донесение обратной связи о продукте
Постоянно улучшать продукты и сервисы, которые используют разработчики, — одна из центральных задач нашей команды. Я провожу почти все время общаясь с разработчиками и инженерами через социальные сети, на онлайн и офлайн конференциях. Я получаю тонны запросов от разработчиков, которые задают вопросы, сообщают о проблемах или просят о новой функциональности. В первую очередь, я стараюсь им помочь, если я хорошо знаком с продуктом. Для серьезных проблем или популярных запросов о новой функциональности я завожу задачи на нашей внутренней доске и плотно сотрудничаю с продуктовой командой, чтобы улучшить опыт использования на основе обратной связи от разработчиков.
Это как раз тот случай, когда в качестве дев. адвоката я могу выступать от имени JavaScript разработчиков, быть их голосом внутри команды. Недавний пример — продукт Azure Static Web Apps, где я провел последние полтора года, участвуя в разработке продукта и помогая команде инженеров создать часть сервиса, обеспечивая важную обратную связь, пробуя новую функциональность и разрабатывая CLI инструмент для разработчиков.
Создание и выпуск продукта
Ещё один аспект работы дев. адвоката, который, возможно, игнорируется множеством людей — это то, что некоторые из нас также участвуют в создании продуктов и их выкатке в прод, как внешних, так и внутренних. Последние полгода у меня была возможность поучаствовать в создании, лидировании и доставке пользователям официального приложения Azure Static Web Apps CLI, которое позволяет разработчикам запускать и отлаживать свои приложения локально.
Я думаю, это то, что должен делать каждый дев. адвокат, потому что это крайне необходимо для понимания того, как продукт или сервис спроектирован, реализован, знать его сильные и слабые стороны. Это то знание, которым необходимо обладать, если мы хотим помогать разработчикам.
Быть “нулевым пользователем”
Приличная часть моего времени уходит на улучшение продуктов и сервисов Azure, на работу с командами разработчиков Azure во всей компании для того, чтобы попробовать новую функциональность и дать обратную связь от JavaScript разработчиков об их ожиданиях. Продукты, с которыми я успел поработать за последние два года: Azure Functions, Azure Storage, Azure Cosmos DB, Azure IoT, Azure Static Web Apps, GitHub Codespaces и npm. Быть “нулевым клиентом” — отличный способ кардинально повлиять на продукт до его релиза. Один из примеров здесь — Azure Static Web Apps: моя команда и я тесно сотрудничали с командой разработки, чтобы помочь обеспечить лучший опыт использования сервисов для всех web разработчиков, которые будут им пользоваться.
Постоянное обучение
Поскольку JavaScript широко используется в множестве различных областей, стек технологий, на котором я обычно сосредоточен, это: Node.js, TypeScript, Serverless, архитектура IoT, базы данных и хостинг. Я также буду честным: я был восхищен языком Rust и планирую изучать его в ближайшем будущем! К счастью, мои коллеги из команды дев. адвокатов языка Rust сделали учебник 5 hours free guide about Rust for beginners. Похоже, для меня это отличное начало!
Создание и улучшение официальной документации
Как дев. адвокат я также трачу какое-то время на создание подробных технических наставлений для многих сервисов Microsoft Cloud. Одно из последних, над которой моя команда и я работали четыре месяца, — the Node.js Learn Path. Что хорошо в нашей официальной документации — это то, что она открыта и любой может помочь с улучшением. Мы также регулярно принимаем в этом участие и делаем пулл реквесты на улучшение и обновление документации на http://docs.microsoft.com.
Помогать другим расти
Ещё один аспект моей работы — ну, это не совсем официальный аспект моих должностных обязанностей — но он очень важен для меня: помогать людям вокруг меня расти и быть успешными. Как представитель меньшинства, который добился успеха в индустрии, я очень забочусь об инклюзивности и разнообразии. Таким образом, помогать другим расти профессионально и персонально — это часть меня самого.
Я участвую во внутренних менторских программах через официальную программу менторства в Microsoft. Во внешнем мире я работаю как наставник для людей из сообщества, которые являются новичками в программировании и хотят поменять карьеру, а также для тех, кто хочет принимать участие в проектах с открытым кодом. Я, очевидно, не могу раскрывать все подробности, но, в целом, помогаю и даю советы по программированию, технологиям и карьерному росту моим ученикам.
Бизнес, цели и ключевые результаты
Давайте внесем ясность: цель каждой компании — делать бизнес. Компания не просто платит тебе за то, что ты работаешь над проектами с открытым кодом, путешествуешь и выступаешь. Компания инвестирует в тебя и ожидает ROI (возврата инвестиций). Но мы все знаем, что ROI сообществ и построения отношений не так просто определить и измерить.
Мы постоянно пересматриваем и обновляем наши OKR (цели и ключевые результаты), стратегию и планирование, чтобы соответствовать более широкой стратегии компании, в то же время давая команде свободу общаться с разработчиками естественным образом, вести полезные беседы, помогать им решать их проблемы и быть их адвокатом.
Заключительные идеи
Основные задачи инженеров — дизайн, реализация и выкатка продукта, и те, кто хочет поделиться своим опытом с сообществом, могут это сделать. Дев. адвокаты не отличаются от инженеров, кроме того, что они не работают над продуктом полный рабочий день, а помогают командам разработки достучаться до разработчиков и понять их нужды, чтобы создать наилучший опыт использования для каждого.
Дев. адвокаты — инженеры, которым нравится учиться открыто.
Кто такие DevRel, зачем они нужны и какие вопросы могут решить для бизнеса
Привет! Меня зовут Женя Голева, я занимаюсь developer relations с 2016 года, и постоянно вижу профессиональных чатах холивары о нашей работе. Люди спорят, кто такие деврелы, кто занимается не деврелом, а какие виды деврелов наоборот имеют право на существование и очень нужны в команде.
Ответы на многие похожие вопросы уже есть — в книге Мэри Тенгвал “The Business Value of Developer Relations”. Я заручилась поддержкой автора и издательства-правообладателя и перевела главу “Building a Developer Relations Team / What’s in a name?” для русскоязычного сообщества. У вас впереди 10 коротких и ёмких разделов про цели и задачи всей команды Developer Relations на старте и в процессе развития, про то, какие роли и специализации могут быть востребованы на разных этапах, что кандидатам необходимо знать и уметь на входе, а что — вовсе не обязательно и можно добрать в процессе работы.
Эта статья будет полезна в первую очередь тем, кто хочет разобраться в специфике направления developer relations: если вы СТО или СЕО, то вам скорее будут полезны первые несколько разделов и последний, если вы уже занимаетесь деврелом или очень хотите начать, здесь будут ответы на вопросы, как войти в профессию или куда в ней развиваться дальше.
Developer Relations Team
Developer Relations Manager
Technical Community Builder
Developer Experience Manager
Technical Engagement Manager
DevRel Project Manager
1. Команда по выстраиванию отношений с разработчиками (Developer Relations Team)
От целей компании зависят обязанности команды DevRel, а также в каком департаменте она будет находиться. (И мы поговорим об этом позже в этой главе)
Тем не менее, главная задача команды DevRel состоит в том, чтобы обеспечивать успех аудитории разработчиков (делать так, чтобы они могли лучше делать свою работу), а также транслировать потребности целевой аудитории остальной части компании. Почти каждый отдел так или иначе взаимодействует с сообществом, но именно команда DevRel фокусируется на благополучии сообщества.
Если вы начинаете небольшой командой, то начните с базовых вещей, необходимых для работы:
бесплатные доступы для разработчиков.
Когда эти задачи будут завершены и перестанут требовать много внимания, можно начать формировать площадку для сообщества, где вы сможете:
собирать примеры использования кода/продукта,
создавать группы суперпользователей или чемпионов,
спонсировать 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)
Эта роль традиционно называется “менеджером сообщества”, но я сознательно использовала в названии слово “строитель”.
На то есть две причины:
Такое название позволяет избежать путаницы.
Из этого названия становится кристально ясно, для чего предназначена эта роль: строить техническое сообщество вокруг существующего продукта.
Несмотря на то, что в названии должности есть слово “технический”, эта роль схожа с менеджером по связям с разработчиками (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?)
Роли, которые я выделила, скорее теоретические, такую полноценную структуру команды редко увидишь вне крупных компаний. Первый нанятый специалист будет отвечать за кусочки всех перечисленных ролей. Хоть и любой найм считается инвестицией, найм вашего первого деврела критически важен. Этот человек принесёт с собой не только экспертизу, но и связи. Если вам удастся найти того, кто получает удовольствие от общения с сообществом и высоко ценится компанией, то этот человек будет первой скрипкой и задаст верную тональность будущим отношениям с инженерами. Как вы уже поняли, чрезвычайно важно правильно выбрать и роль, на которую вы нанимаете, и человека под неё.