Dev rel что это
«Профессии будущего» давно появились — современному миру нужны специалисты, работающие на стыке нескольких направлений. В IT-индустрии это — DevRel, незаменимые люди в компаниях, где создают продукты для разработчиков. Эта профессия полна возможностей и интересных задач. Рассказываем, кто такие DevRel, почему они востребованы, и делимся опытом нашего коллеги из воронежского офиса Haulmont. Кстати, недавно мы рассказывали, чем занимается команда разработки Haulmont в Воронеже.
Кто такой DevRel
Developer Relations (сокращ. DevRel) дословно означает «Отношения с разработчиками». Однако это далеко не все задачи. Да, DevRel общается с разработчиками, а также участвует в создании и поддержке продукта, маркетинге, бизнес-аналитике и публичных коммуникациях. В мире IT так и не сложилось единого мнения, что важнее в работе DevRel: каждая компания по-своему расставляет приоритеты. Вот несколько задач, которые выполняет такой специалист в Haulmont.
Эксперт среди специалистов. DevRel общаются как с внешними разработчиками, так и с продуктовыми девелоперами компании. И у каждой стороны — свои интересы. Пользователи хотят знать, как устроен продукт, в чем его удобства и преимущества, а компании нужна качественная обратная связь. Developer Advocate должен выступать неким информационным фильтром между разными специалистами, а это требует глубоких технических знаний и аналитической работы.
Свой среди заказчиков. Аудитория DevRel — не только опытные разработчики. Зачастую нужно общаться и с потенциальными клиентами, которые не всегда имеют техническое образование и в целом далеки от мира IT. Так что умение говорить просто о сложном — еще один навык, которым обладает хороший DevRel.
Хороший инженер. Конечно, нельзя рассказывать о продукте компании, не участвуя в его разработке. Все-таки приоритетом этой профессии являются технологии и их использование, а не маркетинг. Так что Developer Advocate — это прежде всего разработчик, и часть рабочего времени он пишет код и погружается в создание продукта.
Публичный коммуникатор. DevRel-специалист участвует в крупных конференциях и митапах. Там он обменивается техническими знаниями с другими экспертами и продвигает бренд компании. Эта профессия дает возможность познакомиться с разработчиками со всего света, вырасти до технического эксперта и, конечно, улучшить навыки публичных выступлений.
Технический писатель. Участие в конференциях — лишь один способ заявить о продукте. Не менее важным инструментом является контент. Поэтому DevRel регулярно пишет статьи в блог и активно общается с разработчиками на форумах и в соцсетях. Поэтому грамотность и авторский стиль — его лучшие друзья.
Стать DevRel может даже опытный регуляр — конечно, для этого нужно упорно работать: погружаться в низкоуровневую разработку и оттачивать Hard и Soft skills. Мы уже говорили, что самообучение входит в должностные обязанности DevRel? Он отлично разбирается не только в продукте своей компании, но и во всем, что происходит в мире IT. Профессия DevRel очень разнообразна, но именно поэтому такой специалист заслуженно является авторитетом среди разработчиков.
Кто такой деврел, чем он занимается, сколько зарабатывает и почему он не евангелист
Рассказываем, зачем разработчику становиться техпиарщиком и сколько российские компании платят новым специалистам прямо сейчас.
Обложка: Альберто Блинчиков для Skillbox Media
Деврел (от англ. developer relations — отношения с разработчиками) — это профессионал, который занимается техническим пиаром и выстраивает отношения с IT-индустрией. Иными словами, это амбассадор, который продвигает бренд компании среди технарей.
Иногда деврела также называют Developer Advocate (дословно «разработчик-адвокат»). Отсюда и пошли «авокадные» мемы, связанные с профессией: слово advocate созвучно с avocado.
Мы все прекрасно знаем, что авокадо — это источник полезных жиров. Если мы используем их в нужное время, правильным образом, с правильными ингредиентами, они могут принести огромную пользу.
Цитата из книги Мэри Тенгвалл «В чём ценность отношений с разработчиками для бизнеса»
Филолог, полиглот, IT-гик. В прошлом — преподаватель английского и литературы и рецензент Rolling Stone Russia. Ныне переводит для РБК и пишет о программировании и образовании для Skillbox.
Что делает DevRel
В 2010-х профессия Developer Advocate была не особо распространена даже на Западе. Однако обязанности, которые выполняет такой специалист, не новы — чем-то похожим давно занимаются представители IT-гигантов.
Например, с оговоркой деврелом можно назвать известного IT-евангелиста Apple Гая Кавасаки. В 1980-х он продвигал платформу Macintosh и массово убеждал разработчиков создавать ПО и приложения для «яблочной» продукции.
Нужно было использовать весь пыл и энтузиазм (но никак не деньги), чтобы убедить разработчиков ПО создавать продукты для компьютеров без установленной базы, со 128 Кб ОЗУ, без жёсткого диска, без документации и без технической поддержки… Нужно было как-то убедить людей создавать софт для шаткой компании без репутации, которую вот-вот растопчет IBM.
Цитата из книги Гая Кавасаки «Путь Макинтоша» (англ. The Macintosh Way)
Почему с оговоркой? Несмотря на то что должности «IT-евангелист» и «деврел» действительно похожи, между ними есть существенное различие. IT-евангелист, по сути, ведёт монолог, в котором убеждает людей делать что-то в интересах бренда. Деврел же участвует как в монологах, так и в диалогах. Например, вместе с аудиторией на хакатонах решает проблемы выпускаемого софта.
В 2021 году термин «деврел» только входит в IT-обиход. Поэтому даже в крупных компаниях обязанности деврела размыты и нередко пересекаются или путаются с задачами пиарщика.
Ключевое отличие DevRel от PR в том, что продукт продвигают среди IT-специалистов, а не среди пользователей. Однако в России распространена и обратная практика — налаживать отношения именно с конечным клиентом, но на более айтишной почве. То есть не только рассказывать о возможностях продукта, но и заглядывать вместе с пользователями под капот. В теории это не совсем правильно, но нужно быть готовым к правилам того рынка, на котором вы работаете.
Некоторые специалисты утверждают, что DevRel (деврел) — это исключительно название сферы деятельности, и профессию так называть нельзя. Другие наставивают, что Developer Advocate и деврел — разные роли. Об эту тему сломано немало копий в Twitter, на англоязычных форумах и в блогах.
Среди ключевых обязанностей «каноничного» деврела можно выделить следующие:
Этот список условный — деврелы могут выстраивать отношения с разработчиками так, как им кажется лучше. Если отлично заходят статьи, а во «ВКонтакте» нет ЦА, то тратить время на паблик во «ВКонтакте» и YouTube-контент, возможно, нет смысла. Однозначных решений и стратегий нет даже у больших корпораций.
Кстати, в больших компаниях иногда существуют целые деврел-отделы со своей иерархией. Там обязанности разделяют между несколькими сотрудниками, которых координирует деврел-менеджер.
Вне зависимости от подхода, у DevRel есть две основные цели:
Какие-то компании решают только одну из задач, а другие — обе. Например, когда Adobe продвигает Photoshop, она одновременно продаёт его конечным пользователям и привлекает новых дизайнеров и художников в компанию.
Наглядный пример деятельности деврела — выступление Григория Петрова на RubyRussia Online. Эксперт делится знаниями и мнением о языке, но вместе с тем продвигает бренд Evrone среди Ruby-разработчиков и рассказывает, что в его компании активно используют Ruby (что как бы намекает):
Ещё один вход в IT для гуманитариев?
Обычно деврелами становятся технари с круто прокачанными soft skills — те самые харизматичные прогеры, которые и код классно пишут, и разъясняют самые непонятные штуки на пальцах. Как правило, такие гики продолжают кодить, время от времени очаровывая всех выступлениями на форумах или классными постами на «Хабре», в Facebook и Twitter. Они становятся авторитетными экспертами и быстро собирают крепкие комьюнити.
Но бывает, что в DevRel «залазят через окно» — пиар, маркетинг, продажи или HR. Правда, без технической базы — в любом случае никак. Нужно уметь общаться с айтишниками на одном языке. А для этого необходимо понимать, что делает компания, хотя бы на уровне джуна.
И даже в этом случае штурмовать крупный форум деврелу-гуманитарию вряд ли доверят — вдруг облажается на продвинутых вопросах. А фейлы в IT-сфере помнят очень долго.
Поэтому гораздо чаще деврелы-гуманитарии направляют и организуют работу деврелов-технарей или просто наиболее софтовых разработчиков. Они договариваются о встречах, следят за постами, помогают упростить доклады, мотивируют разработчиков, настраивают материал под аудиторию. То есть деврелы-гуманитарии выступают неким проводником между компаниями и внешним миром.
Особенно полезны такие спецы в России, где общение часто происходит с конечными пользователями. Чтобы захватить внимание неподготовленной аудитории, материал важно легко подать — и с этим деврелы-гуманитарии часто справляются без проблем. Но опять же: только если у них есть хоть какой-то технический бэкграунд.
Востребованы ли DevRel-специалисты и сколько они зарабатывают
Полноценных спецов в DevRel пока не так много, как и предложений на рынке труда. На hh.ru — не более 50 активных вакансий (включая околодеврелов). При этом нужно знатно изощряться и искать обязанности по смежным должностям.
Вакансии можно искать по таким ключевым словам, как devrel, «деврел», «PR-менеджер», «техномаркетинг», «директор проектов», «техпиар» и «IT-евангелист». Обязанности деврела можно найти даже в вакансиях рекрутеров и менеджеров. Скорее всего, ситуация изменится уже в 2022 году, когда профессия станет обыденной, а российские компании определятся, чего хотят от деврела.
Деврелов обычно ищут крупные компании или стартапы с серьёзными амбициями, которым есть что рассказать. Например, на hh.ru есть вакансии от «Билайна», «Тинькофф», «2ГИС», Сбербанка. Кстати, их описания соответствуют обязанностям каноничного деврела.
Правда, ни одна из крупных организаций не указала зарплатную вилку — очевидно, всё индивидуально. Более конкретные предложения нашлись в нескольких вакансиях. Например, BestDoctor предлагает от 150 тысяч рублей на руки. Увесистый ценник указал разработчик робота-обзвонщика Dasha.AI — от 210 тысяч до 360 тысяч рублей. Разумеется, с такой зарплатой и требования соответствующие:
Делать выводы на основе нескольких вакансий не стоит. Также нет смысла изучать западный рынок — он далеко не всегда совпадает с российским. Поэтому о зарплатах деврелов в будущем можно лишь догадываться, но, скорее всего, предложения будут начинаться со 100 тысяч рублей.
Что должен уметь DevRel
От деврела обычно ждут нескольких ключевых качеств:
Огромную роль играют софты:
Для управленцев и гуманитариев ещё важно уметь организовывать работу, делегировать задачи и мотивировать людей.
Где обучают DevRel
На деврелов пока нигде не учат — их растят в компаниях. Но можно пройти дополнительные курсы, которые докрутят навыки, необходимые для этой должности.
Например, если хромают только коммуникабельность и эмпатия, то можно пройти курсы по эмоциональному интеллекту. Если мало знаете об управлении продуктом и бизнесе, то можно прокачаться в маркетинге и продакт-менеджменте.
А если у вас не хватает технического бэкграунда, то в разделе «Программирование» есть множество курсов, которые помогут сформировать крепкий технический бэкграунд для деврела. Выбирайте подходящий курс и учитесь у опытных разработчиков из «Яндекса», Mail.ru, «Тинькофф» и других крупных IT-компаний.
Понятие «IT-евангелист» изобрели в Apple. Основной задачей таких специалистов было убеждать или заинтересовывать программистов разрабатывать софт для новой платформы — Macintosh. Главный инструмент IT-евангелизма — вера.
Кто такие 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?)
Роли, которые я выделила, скорее теоретические, такую полноценную структуру команды редко увидишь вне крупных компаний. Первый нанятый специалист будет отвечать за кусочки всех перечисленных ролей. Хоть и любой найм считается инвестицией, найм вашего первого деврела критически важен. Этот человек принесёт с собой не только экспертизу, но и связи. Если вам удастся найти того, кто получает удовольствие от общения с сообществом и высоко ценится компанией, то этот человек будет первой скрипкой и задаст верную тональность будущим отношениям с инженерами. Как вы уже поняли, чрезвычайно важно правильно выбрать и роль, на которую вы нанимаете, и человека под неё.
