Team API

Обзор Developer Journey Map

В конце 2021 года в книге Developer Relations: How to Build and Grow a Successful Developer Program авторов Caroline Lewko и James Parton был представлен инструмент и карта Developer Journey Map для визуализации опыта взаимодействия и диагностики пути, который проходит разработчик.

Использование карты Developer Journey Map для аудита Developer Experience (DX) позволяет:
  • показать, как разработчики взаимодействуют с продуктом, платформой или экосистемой;
  • предоставить наглядное представление о зонах, требующих фокуса для повышения принятия и адаптации продукта или платформы;
  • продемонстрировать взаимосвязи между точками контакта;
  • сформировать перечень конкретных улучшений.

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

В Developer Journey Map выделяют пять этапов, отражающих изменения в намерениях, уровне доверия и глубине использования продукта или платформы:
  1. Discover (Обнаружение). Цель этапа — сформировать первичный интерес и понимание ценности. Ключевые вопросы разработчика: Имеет ли это для меня ценность? Что это такое? Может ли это решить мою проблему? Насколько это надежно и заслуживает доверия?
  2. Evaluate (Оценка). Цель этапа — определить релевантность и соответствие ожиданиям. Ключевые вопросы: Соответствует ли это моим потребностям? Выглядит ли это простым в использовании? Есть ли тревожные сигналы или риски? Является ли цена барьером?
  3. Learn (Изучение). Цель этапа — получить первый успешный результат и сформировать уверенность. Ключевые вопросы: Как это работает? Сколько времени потребуется до первого результата уровня Hello World? Является ли документация удобной и понятной? Возникает ли у меня уверенность в продукте? Есть ли сообщество?
  4. Build (Разработка). Цель этапа — создать рабочий прототип или MVP. Ключевые вопросы: Могу ли я собрать Proof of concept? Сколько времени требуется до MVP? Является ли сам продукт иди платформа удобным в использовании? Как я могу получить поддержку? Соответствует ли продукт своей стоимости?
  5. Scale (Масштабирование). Цель этапа — расширить использование и интеграцию продукта. Ключевые вопросы: Могу ли я масштабировать решение? Могу ли я расширить использование? Как я могу дать обратную связь? Как я могу внести вклад? Будет ли продукт или платформа развиваться вместе с моими потребностями?

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

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

Ответственность за развитие и оптимизацию точек контакта лежит на командах или экспертах по Developer Experience или Developer Relations. Их задача — обеспечить целостность пути, устранить трение и гарантировать, что на каждом этапе разработчик получает необходимые ответы и поддержку.

В Developer Journey Map выделяют два типа точек контакта:
  • Owned touchpoints (Контролируемые точки контакта) — это ресурсы и контент, находящиеся во владении и управлении компании. Их структура, содержание и пользовательский опыт полностью определяются организацией. К ним относятся: сайт, Developer hub, документация, коммуникации в социальных сетях, рекламные материалы, информация о ценах, примеры кода, поддержка и другие управляемые активы;
  • External touchpoints (Внешние точки контакта) — это каналы и ресурсы, находящиеся вне прямого контроля компании, но существенно влияющие на восприятие и принятие продукта. К ним относятся профильные медиа, отраслевые аналитики, сторонние сообщества, внешние форумы и другие независимые площадки. Обеспечение присутствия, корректного позиционирования и позитивного контекста на этих площадках напрямую влияет на осведомленность, доверие и темпы принятия продукта.

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

Список точек контакта:
  1. Dev Hub Landing Page. Главная страница портала для разработчиков, точка входа в экосистему.
  2. SEO/PPC. Каналы привлечения трафика через поисковую оптимизацию и платную рекламу.
  3. Social. Коммуникации в социальных сетях и платформах профессионального общения.
  4. Events. Конференции и мероприятия для привлечения и вовлечения разработчиков.
  5. Blog. Публикации о продукте, технологиях и сценариях применения.
  6. Newsletter. Регулярная рассылка для поддержания интереса и информирования аудитории.
  7. Case Studies. Кейсы использования продукта реальными клиентами.
  8. Docs Landing Page. Главная страница раздела документации.
  9. FAQs. Раздел с ответами на часто задаваемые вопросы.
  10. Product Pages. Страницы с описанием возможностей, ценности и позиционирования продукта.
  11. Getting Started/Quick Start Guide. Руководство по быстрому началу работы.
  12. Code Samples. Примеры кода для демонстрации использования API или SDK.
  13. Tutorials. Пошаговые обучающие материалы.
  14. Sign up/Registration. Процесс регистрации и создания учетной записи.
  15. Extensions. Расширения и плагины, дополняющие функциональность продукта.
  16. Sandbox. Тестовая среда для безопасных экспериментов.
  17. Reference Guide. Подробная техническая справочная документация.
  18. Changelog. Журнал изменений и обновлений продукта.
  19. Forums. Форумы для обсуждений и взаимопомощи пользователей.
  20. Use Cases. Описание типовых сценариев применения продукта.
  21. Pricing Page. Страница с тарифами и условиями использования.
  22. Webinars. Онлайн-семинары и демонстрации продукта.
  23. Office Hours. Регулярные сессии вопросов и ответов с командой.
  24. Training. Формальные обучающие программы и курсы.
  25. Learning Resources. Дополнительные образовательные материалы.
  26. Support. Каналы технической поддержки пользователей.
  27. Workshops. Практические обучающие сессии.
  28. Developer Success. Проактивное сопровождение разработчиков при использовании продукта.
  29. SLAs. Соглашения об уровне сервиса и гарантиях доступности.
  30. Product Roadmap. Публичный план развития продукта.
  31. Showcase. Демонстрация решений и проектов, созданных на основе продукта.
  32. Ambassador Program. Программа для активных представителей сообщества.
  33. Partner Program. Программа сотрудничества с технологическими и коммерческими партнерами.
  34. Certification. Программы официальной сертификации пользователей или партнеров.
  35. Online Media/Press. Публикации в профильных медиа и отраслевой прессе.
  36. Syndication. Распространение контента через внешние площадки.
  37. Events, Meetups, Hackathons. Офлайн и онлайн встречи, митапы и хакатоны.
  38. Referrals. Привлечение новых пользователей через рекомендации.
  39. Online & Offline Groups. Профессиональные сообщества разработчиков.
  40. GitHub. Платформа для размещения кода, SDK, примеров и открытых проектов.
  41. Stack Overflow. Платформа вопросов и ответов по техническим темам.
  42. Technology Dependencies. Зависимости продукта от сторонних технологий и экосистем, влияющие на его восприятие и принятие.

Как использовать Developer Journey Map
Developer Journey Map применяется как инструмент регулярного аудита Developer Experience (DX) для выявления и устранения трения, замедляющего или блокирующего принятие продукта или платформы. Качественно выстроенный Developer Experience напрямую влияет на переход от вовлеченности к реальному использованию продукта или платформы — процессу, который часто называют онбординг (Onboarding).

Шаг 1. Подготовка карты
Шаблон Developer Journey Map воспроизводится на онлайн доске или на листе формата A3. По вертикали фиксируются разделы:
  • Stage
  • Goal/Needs
  • Questions
  • Internal and External Touchpoints
По горизонтали — пять этапов пути разработчика.
На каждом этапе формулируются цели и ключевые вопросы. Можно использовать базовые примеры или адаптировать их под собственный контекст.

Шаг 2. Моделирование сценариев
Необходимо выбрать один или несколько сценариев использования с учетом:
  • профиля разработчика;
  • уровня его знакомства с компанией, продуктом или платформой;
  • конечной цели, которую он стремится достичь, например: выполнить API запрос, создать сервис, выполнить деплой.

Шаг 3. Прохождение пути
С точки зрения выбранного сценария последовательно моделируется весь Developer Experience: от обнаружения до масштабирования. По мере прохождения добавляются точки контакта, которые реально задействуются на каждом этапе. Каждая точка контакта оценивается с позиции разработчика. Для оценки удобно использовать систему RAG (Red / Amber / Green):
  • Red — трение, останавливающее или существенно препятствующее продвижению;
  • Amber — трение, замедляющее продвижение и снижающее уверенность, но не приводящее к отказу;
  • Green — отсутствие значимого трения и предсказуемое взаимодействие.

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

Ограничения внутреннего аудита
Даже при системном подходе команда не может полностью устранить предвзятость. Типовые когнитивные искажения включают:
  • confirmation bias — поиск подтверждения уже существующих убеждений;
  • self-serving bias — склонность объяснять проблемы внешними причинами;
  • fundamental attribution error — объяснение поведения пользователей через упрощенные допущения;
  • generalization — игнорирование отдельных шагов процесса из-за эффекта привычности.
По этой причине внешний независимый аудит может существенно повысить объективность оценки. Внешняя экспертиза позволяет сопоставить практики с отраслевыми бенчмарками и выявить системные зоны риска, которые сложно заметить изнутри.

Пример Developer Journey Map приведен ниже:
Если вам важно системно оценить Developer Experience и выявить факторы, замедляющие принятие продукта или платформы, обращайтесь к нам за помощью. Мы проводим аудиты с использованием инструмента и карты Developer Journey Map, в рамках работы совместно с платформенными или продуктовыми командами моделируются ключевые сценарии, формулируются цели и ключевые вопросы, картируются все точки контакта и оценивается уровень трения. Мы выявляем разрывы в пути разработчика, несогласованность коммуникаций, барьеры в адаптации и масштабировании, а также формируем приоритетный план улучшений с привязкой к метрикам активации, удержания и роста использования. Результатом является прозрачная карта пути разработчика, список конкретных изменений и рекомендации по развитию процессов, практик и точек контакта.

Не забывайте подписываться на наш канал Enabling.team Insights, чтобы оставаться в курсе технологических трендов.