DevRel Web3 para o momento em que um desenvolvedor testa seu SDK

Onde o DevRel Web3 pode ajudar seus desenvolvedores a avançar?

O DevRel Web3 é útil quando os desenvolvedores precisam de um caminho mais claro a partir da descoberta do seu produto. Ele os ajuda a dar o próximo passo e testar seu SDK. Ele conecta explicações do produto, materiais técnicos e lugares para fazer perguntas. Sua equipe pode então se concentrar nos obstáculos que importam agora.

Comece com a tarefa pretendida do desenvolvedor. Uma equipe de protocolo pode precisar explicar como uma integração começa. Uma equipe de ferramentas pode precisar de um primeiro exemplo simples. Verifique o que um desenvolvedor pode encontrar sem orientação privada. Observe onde as instruções se tornam confusas e quem pode confirmar detalhes técnicos.

Este trabalho pode apoiar um lançamento futuro. Não precisa esperar por um. Se você ainda está moldando o plano de lançamento mais amplo, conecte o caminho do desenvolvedor à estratégia de go-to-market. Isso ajuda sua equipe a alinhar o que os desenvolvedores podem usar com o que o projeto está pronto para dizer.

Uma primeira conversa útil cobre três coisas. Nomeie o desenvolvedor que você deseja alcançar. Descreva a primeira tarefa que ele deve concluir. Identifique quem pode revisar a precisão técnica. Se esses detalhes estiverem claros, podemos focar o plano nas lacunas práticas. Não começaremos escolhendo canais.

Uma nota de imprensa pode expor uma lacuna na recepção ao desenvolvedor

O suporte ao desenvolvedor funciona melhor quando a pessoa que responde perguntas tem uma rota clara para informações precisas. Uma nota de imprensa pode trazer nova atenção. Ela não pode substituir um primeiro passo compreensível ou um responsável por perguntas técnicas.

Digamos que um servidor Discord com um administrador de meio período esteja preparando uma primeira nota de imprensa. Membros perguntam por onde começar com o SDK. O administrador ainda precisa manter as perguntas do dia a dia em andamento. Nós rastrearíamos essas perguntas até a documentação atual. Então, concordaríamos quem pode verificar as respostas e prepararíamos uma breve nota de passagem antes de a nota de imprensa ser compartilhada.

Essa preparação dá ao administrador algo útil para apontar. Também dá aos engenheiros uma visão mais clara das perguntas que precisam de sua contribuição. A equipe pode então ver se sua próxima tarefa é melhorar um guia, adicionar um exemplo ou definir uma rotina para respostas da comunidade.

Começamos com os canais e materiais que você já tem. Se seu projeto tem um grupo ativo, revisamos como ele apoia os desenvolvedores antes de recomendar um novo. Um programa de comunidade de desenvolvedores mais amplo pode conectar esse suporte com educação contínua. O primeiro movimento certo pode ser simplesmente tornar as respostas existentes mais fáceis de encontrar.

O que podemos tornar mais fácil de usar?

O trabalho deve ajudar um desenvolvedor a dar um próximo passo real, não apenas adicionar mais material. Concordamos quais partes importam para seu produto. Então, preparamos ou melhoramos as peças que sua equipe pode manter.

Imagine uma pequena equipe de protocolo preparando um desafio de hackathon. Seus exemplos de SDK ainda estão mudando. Mapearíamos a tarefa que os participantes devem tentar. Verificaríamos quais instruções precisam de revisão técnica. Então, tornaríamos a rota de suporte clara antes de compartilhar os materiais do evento.

Dependendo de suas prioridades, o trabalho pode incluir:

• Uma revisão da rota da introdução do produto ao primeiro uso do SDK.
• Orientações de configuração mais claras, explicações de fluxo de trabalho ou exemplos para desenvolvedores.
• Uma lista priorizada de lacunas na documentação para sua equipe abordar.
• Orientações de resposta da comunidade, incluindo responsabilidade por perguntas e escalonamento.
• Materiais de hackathon, como um resumo do desafio, notas de configuração e orientações de submissão.

Sua equipe de produto ou engenharia verifica detalhes técnicos. Nós ajudamos a moldar a experiência e coordenar o trabalho. Para cada item, concordamos quem o revisa. Também definimos o que “pronto” significa antes de qualquer coisa ser publicada. Isso mantém o material baseado no que o produto pode suportar hoje.

Um ritmo de trabalho simples mantém os detalhes visíveis

Organizamos o trabalho em torno de tarefas acordadas, revisão técnica e um registro claro de progresso. O cronograma segue os materiais que você já tem. Também segue a rapidez com que as pessoas certas podem revisá-los.

Usamos 3 pontos de verificação para manter o trabalho em andamento. Primeiro, revisamos a jornada atual do desenvolvedor. Em seguida, concordamos com prioridades e responsáveis. Então, sua equipe técnica verifica os materiais finalizados. Também nomeamos 1 pessoa do seu lado para reunir decisões e evitar que perguntas se percam.

Concordamos com 2 pontos de revisão técnica quando a contribuição de engenharia é necessária. O primeiro vem antes de redigir afirmações sobre como algo funciona. O segundo vem antes de publicar exemplos ou instruções. Uma nota de progresso compartilhada registra itens concluídos, perguntas em aberto e a próxima decisão. Se seu trabalho de lançamento continuar após o release, o suporte pós-lançamento pode manter a educação do desenvolvedor conectada a essa próxima fase.

Traga o contexto do produto que seus desenvolvedores já pedem

Uma primeira revisão útil começa com materiais que sua equipe pode compartilhar. Também precisa de uma pessoa que possa verificar detalhes técnicos. Reúna sua visão geral do SDK ou produto, documentação atual, público-alvo de desenvolvedores e qualquer marco futuro. Uma lista curta de perguntas repetidas também é útil.

Procuramos atritos que um desenvolvedor pode encontrar. Isso pode ser pré-requisitos pouco claros, etapas faltando, exemplos que precisam de confirmação ou perguntas sem um responsável. Então, concordamos o que abordar primeiro e como sua equipe revisará o trabalho. Se sua necessidade imediata for um planejamento mais amplo, o plano de lançamento de token e crescimento pode ajudar a conectar os materiais do desenvolvedor ao lançamento mais amplo.

Podemos preparar a documentação acordada, as orientações da comunidade e os materiais do hackathon. Não podemos decidir se desenvolvedores independentes escolhem integrar um SDK. Os organizadores do evento também definem suas próprias regras de participação e decisões de seleção. Nosso compromisso é com o trabalho e o processo de revisão que acordamos juntos.

Envie para Brand Community sua visão geral do produto, documentação atual e o marco para o qual você está se preparando. Revisaremos esses materiais e identificaremos a primeira tarefa mais útil. Então, voltaremos com um plano claro para sua equipe considerar.

Como funciona

1. Compartilhe a visão do produtoEnvie uma visão geral do SDK ou produto, documentação atual e seu público-alvo de desenvolvedores. Adicione o marco ou tarefa que você deseja que o trabalho apoie.
2. Percorra a jornada do desenvolvedorRastreamos como alguém descobre o produto, inicia a integração e encontra ajuda. Observamos etapas pouco claras e perguntas para seus responsáveis técnicos.
3. Concorde com prioridades e responsáveisJuntos, escolhemos o trabalho a fazer primeiro e nomeamos as pessoas que revisam materiais, respondem perguntas ou coordenam um evento.
4. Prepare e verifique os materiaisCriamos ou refinamos a documentação acordada, as orientações da comunidade ou os recursos do hackathon. Sua equipe de produto ou engenharia verifica os detalhes técnicos.
5. Compartilhe o progresso e as próximas açõesRegistramos o que está completo, o que ainda precisa de uma decisão e quais melhorias práticas pertencem ao próximo ciclo.