Developer Advocate
Виды DevRel: что делают разные специалисты-деврелы, и где они обитают
Я буду выкладывать сюда частями перевод главы “Building a Developer Relations Team / What’s in a name?” из книги “The business Value of Developer Relations”.
Технический эксперт: представитель интересов разработчиков (Developer Advocate)
Название Developer Advocate отвечает на два главных вопроса сообщества:
- Какая у тебя квалификация?
- Что ты делаешь?
Эта должность помогает установить тот факт, что эти сотрудники, во-первых, разработчики, а во-вторых, их основная задача быть голосом сообщества в компании. Это делает их одновременно и представителями сообщества, и экспертами об этом сообществе.
Помните, я упоминала в главе 3 про представительство компании перед сообществом и, наоборот, представлении сообщества перед компанией? Большую часть этой работы делают технические эксперты (Developer Advocates). Именно они больше всего лично общаются с аудиторией разработчиков, когда выступают на конференциях, работают на стендах и в интернете через форумы, слак, разные сайты и соцсети. Часть из этих платформ будут корпоративными, но большую часть времени технические эксперты будут проводить в каналах, управляемых сообществом, а не компанией.
Когда команда станет больше, можно начать специализировать технических экспертов по технологическому стеку, по навыкам личного общения, и даже по регионам.
Вы обнаружите, что кто-то лучше выступает с докладом, а кто-то хорош именно в личном общении на стенде. Другие станут известны благодаря своим писательским навыкам, создавая контент, который точно бьет в целевую аудиторию разработчиков. Третьи смогут писать самую легкую для понимания документацию, разбивая продукт на понятные и детальные этапы, а может они будут обладать врожденной способностью находить уже сложившиеся сообщества в самых узких нишах вашей отрасли.
Будьте осторожны при найме: очень легко потребовать, чтобы технический эксперт и по несколько статей в месяц писал, и на всех конференциях выступал, и был в курсе свежайших и наилучших подходов в разработке, а также глубоко разбирался в кодовой базе продукта, создавая демки и SDK; важно понимать, что такое описание вакансии тянет на три должности сразу.
Тщательно выберите нужные навыки, максимально соответствующие текущей ситуации и ближайшим планам, а когда команда станет расширяться, нанимайте тех, кто закроет образовавшиеся дыры. Это может быть владение ещё одним языком или какие-то специфические навыки, расширяйте свою команду до тех пор, пока каждый не сфокусируется на своей специализации. Так каждый член команды займёт ровно ту позицию, которая лучше всего подходит его талантам. Это не только принесет максимум пользы, но и позволит человеку развиваться именно в той области, которая ему интересна.
Помните, что в предыдущей главе я говорила о такой метрике, как создание DevRel команды мирового класса? Именно таким образом формируется сильная команда, и это начинают замечать за пределами компании.
Это только 3 подглава из 10. Оставайтесь на связи!
- 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?
За помощь в переводе спасибо Баруху Садогурскому, Тоне Татчук и Лизе Швец.
