Web3 DevRel, который ведет разработчиков от документации к использованию SDK

3 поверхности, 1 путь разработчика

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

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

Этот сервис подходит для протоколов, API, SDK и других продуктов, ориентированных на разработчиков. Он полезен, когда продукт работает, но инструкции трудно понять. Технические вопросы могут поступать в разрозненные места. Запуск также может не иметь четкого плана онбординга разработчиков.

• Документация: сделайте шаги настройки и предварительные требования легко находимыми.
• Сообщество: дайте разработчикам понятное место для технических вопросов.
• Хакатоны: поставьте практическую задачу по сборке и подготовьте материалы поддержки.

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

Какая поверхность для разработчиков требует работы в первую очередь?

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

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

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

Для более сильного образовательного слоя рассмотрите контент для обучения разработчиков. Держите материалы мероприятий и ответы сообщества в соответствии с той же поддерживаемой документацией.

3 группы материалов для подготовки перед запуском

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

• Технические материалы: приоритеты документации, краткие руководства, примеры SDK или обучающие материалы.
• Руководства по поддержке: заметки для ответов, контакты для эскалации и маршрутизация нерешенных вопросов.
• Ресурсы для мероприятий: челлендж по сборке, инструкции для участников и стартовые материалы.

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

Перед началом производства DigitalMedia1 использует чек-лист для старта, чтобы подтвердить:

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

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

Как Web3 DevRel переходит от анализа к запуску?

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

1. Анализ продукта: отправьте продукт, документацию, SDK и ссылки на сообщество. Укажите, что уже работает. Определите, кто может проверить технические детали.
2. Проверка пути: мы изучаем, как разработчик находит, запускает и тестирует продукт. Мы отмечаем неясные шаги и пробелы в поддержке.
3. План работы: согласуйте приоритетное действие разработчика, материалы, ответственных и сигналы для отчетности.
4. Проверка материалов: мы готовим одобренные материалы. Ваш технический ответственный проверяет примеры и утверждения перед публикацией.
5. Запуск и отчет: мы координируем согласованную работу и фиксируем выполненные материалы, доступную активность и следующие действия.

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

Для более широкой последовательности запуска свяжите работу с токен сейлом и ростом. Мы анализируем материалы вашего продукта и отправляем письменное предложение в течение 2 рабочих дней. Работа начинается в течение 24 часов после подтверждения оплаты.

Что ваша команда DevRel может проверить?

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

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

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

• Подтвердите, что примеры соответствуют текущему продукту перед публикацией.
• Привязывайте утверждения к функциям, которые ваша команда проверила.
• Фиксируйте повторяющиеся вопросы и направляйте нерешенные проблемы.
• Связывайте каждое мероприятие или активность сообщества с поддерживаемой документацией.

Отправьте нам URL продукта, текущую документацию, ссылки на SDK или репозиторий и активные каналы разработчиков. Укажите желаемый результат.

• Статус: сообщите, что уже работает, а что планируется.
• Техническая проверка: укажите, кто может проверить технические детали.

Мы анализируем путь первого использования и возвращаем письменный план и предложение в течение 2 рабочих дней. Затем мы согласуем ответственных и следующие действия.

Как мы работаем

1. 1. Отправьте контекст продуктаПоделитесь ссылками на продукт, документацию, SDK и каналы разработчиков. Укажите, что уже работает и кто может проверить технические детали.
2. 2. Проверьте путь первого использованияМы анализируем, как разработчики находят, запускают и тестируют продукт. Вы получаете список пробелов в документации, поддержке и мероприятиях.
3. 3. Согласуйте план работыВыберите приоритетное действие разработчика, материалы, ответственных и сигналы для отчетности до начала производства.
4. 4. Проверьте технические материалыМы готовим согласованный контент или материалы мероприятия. Ваш технический ответственный проверяет точность перед публикацией.
5. 5. Запуск и отчетМы координируем одобренную работу и отчитываемся о выполненных материалах, доступной активности и следующих действиях.