개발자가 SDK를 시도하는 순간을 위한 Web3 DevRel

Web3 DevRel이 개발자들의 진전을 어디에서 도울 수 있나요?

Web3 DevRel은 개발자가 제품을 발견한 후 더 명확한 경로가 필요할 때 유용합니다. 다음 단계를 밟고 SDK를 시도하도록 돕습니다. 제품 설명, 기술 자료, 질문할 수 있는 공간을 연결합니다. 팀은 현재 중요한 장애물에 집중할 수 있습니다.

개발자가 수행하려는 작업부터 시작하세요. 프로토콜 팀은 통합이 어떻게 시작되는지 설명해야 할 수 있습니다. 도구 팀은 간단한 첫 예제가 필요할 수 있습니다. 개발자가 개인적인 안내 없이 무엇을 찾을 수 있는지 확인하세요. 지침이 불명확해지는 부분과 기술적 세부 사항을 확인할 수 있는 사람을 파악하세요.

이 작업은 예정된 런칭을 지원할 수 있습니다. 런칭을 기다릴 필요는 없습니다. 더 넓은 출시 계획을 아직 구체화 중이라면 개발자 경로를 출시 전략과 연결하세요. 그러면 팀이 개발자가 사용할 수 있는 것과 프로젝트가 말할 준비가 된 것을 일치시키는 데 도움이 됩니다.

유용한 첫 대화는 세 가지를 다룹니다. 도달하려는 개발자를 지정하세요. 그들이 완료해야 할 첫 번째 작업을 설명하세요. 기술적 정확성을 검토할 사람을 지정하세요. 이러한 세부 사항이 명확하면 계획을 실질적인 격차에 집중할 수 있습니다. 채널 선택부터 시작하지 않습니다.

보도 자료는 개발자 환영의 격차를 드러낼 수 있습니다

개발자 지원은 질문에 답하는 사람이 정확한 정보에 대한 명확한 경로를 가질 때 더 잘 작동합니다. 보도 자료는 새로운 관심을 불러일으킬 수 있습니다. 이해할 수 있는 첫 단계나 기술 질문에 대한 담당자를 대체할 수는 없습니다.

파트타임 관리자가 있는 디스코드 서버가 첫 보도 자료를 준비 중이라고 가정해 보세요. 멤버들은 SDK가 어디서 시작되는지 묻습니다. 관리자는 여전히 일상적인 질문을 처리해야 합니다. 우리는 그 질문들을 현재 문서로 추적합니다. 그런 다음 누가 답변을 확인할 수 있는지 합의하고 보도 자료가 공유되기 전에 짧은 인수인계 노트를 준비합니다.

그 준비는 관리자가 참조할 유용한 자료를 제공합니다. 또한 엔지니어에게 자신의 입력이 필요한 질문에 대한 더 명확한 시야를 제공합니다. 팀은 다음 작업이 가이드 개선, 예제 추가, 또는 커뮤니티 응답 루틴 설정 중 무엇인지 확인할 수 있습니다.

이미 보유한 채널과 자료로 시작합니다. 프로젝트에 활성 그룹이 있다면 새로운 그룹을 추천하기 전에 개발자를 어떻게 지원하는지 검토합니다. 더 넓은 개발자 커뮤니티 프로그램은 이 지원을 지속적인 교육과 연결할 수 있습니다. 올바른 첫 번째 움직임은 단순히 기존 답변을 더 찾기 쉽게 만드는 것일 수 있습니다.

사용하기 쉽게 만들 수 있는 것

작업은 단순히 자료를 추가하는 것이 아니라 개발자가 실제 다음 단계를 밟도록 도와야 합니다. 제품에 중요한 부분을 합의합니다. 그런 다음 팀이 유지할 수 있는 부분을 준비하거나 개선합니다.

작은 프로토콜 팀이 해커톤 챌린지를 준비한다고 상상해 보세요. SDK 예제가 아직 변경 중입니다. 참가자가 시도해야 할 작업을 매핑합니다. 어떤 지침이 기술 검토가 필요한지 확인합니다. 그런 다음 이벤트 자료를 공유하기 전에 지원 경로를 명확히 합니다.

우선순위에 따라 작업에는 다음이 포함될 수 있습니다:

• 제품 소개부터 첫 SDK 사용까지의 경로 검토
• 더 명확한 설정 가이드, 워크플로우 설명 또는 개발자 예제
• 팀이 해결해야 할 문서 격차의 우선순위 목록
• 질문 소유권 및 에스컬레이션을 포함한 커뮤니티 응답 가이드
• 챌린지 브리프, 설정 노트, 제출 가이드 등의 해커톤 자료

제품 또는 엔지니어링 팀이 기술 세부 사항을 확인합니다. 우리는 경험을 구성하고 작업을 조정하는 데 도움을 줍니다. 각 항목에 대해 검토자를 합의합니다. 또한 자료가 나가기 전에 '준비 완료'의 의미를 정의합니다. 이렇게 하면 자료가 오늘 제품이 지원할 수 있는 것에 기반을 둡니다.

간단한 작업 리듬이 세부 사항을 명확하게 유지합니다

합의된 작업, 기술 검토, 명확한 진행 기록을 중심으로 작업을 구성합니다. 일정은 이미 보유한 자료와 적절한 사람이 검토할 수 있는 속도에 따릅니다.

3개의 체크포인트를 사용하여 작업을 진핸시킵니다. 첫째, 현재 개발자 여정을 검토합니다. 다음으로 우선순위와 담당자를 합의합니다. 그런 다음 기술 팀이 완료된 자료를 검사합니다. 또한 귀측에서 결정을 모으고 질문이 사라지지 않도록 1명의 담당자를 지명합니다.

엔지니어링 입력이 필요할 때 2개의 기술 검토 시점을 합의합니다. 첫 번째는 작동 방식에 대한 주장을 초안하기 전입니다. 두 번째는 예제나 지침을 게시하기 전입니다. 공유 진행 노트는 완료된 항목, 미해결 질문, 다음 결정을 기록합니다. 출시 작업이 릴리스 후에도 계속된다면 출시 후 지원이 개발자 교육을 다음 단계와 연결할 수 있습니다.

개발자가 이미 묻는 제품 맥락을 가져오세요

유용한 첫 검토는 팀이 공유할 수 있는 자료로 시작합니다. 또한 기술 세부 사항을 확인할 수 있는 사람이 필요합니다. SDK 또는 제품 개요, 현재 문서, 의도한 개발자 대상, 그리고 다가오는 마일스톤을 모으세요. 반복되는 질문의 짧은 목록도 도움이 됩니다.

개발자가 겪을 수 있는 마찰을 찾습니다. 불명확한 전제 조건, 누락된 단계, 확인이 필요한 예제, 또는 담당자가 없는 질문일 수 있습니다. 그런 다음 무엇을 먼저 다룰지와 팀이 작업을 어떻게 검토할지 합의합니다. 즉각적인 필요가 더 넓은 계획이라면 토큰 런칭 및 성장 계획이 개발자 자료를 더 넓은 출시와 연결하는 데 도움이 될 수 있습니다.

합의된 문서, 커뮤니티 가이드, 해커톤 자료를 준비할 수 있습니다. 독립적인 개발자가 SDK를 통합할지 여부를 결정할 수는 없습니다. 이벤트 주최자도 자체 참여 규칙과 선정 결정을 설정합니다. 우리의 약속은 함께 합의한 작업과 검토 프로세스에 있습니다.

Brand Community에 제품 개요, 현재 문서, 준비 중인 마일스톤을 보내주세요. 해당 자료를 검토하고 가장 유용한 첫 작업을 식별합니다. 그런 다음 팀이 고려할 명확한 계획을 가지고 돌아오겠습니다.

이용 방법

1. 제품 개요 공유SDK 또는 제품 개요, 현제 문서, 의도한 개발자 대상을 보내주세요. 작업이 지원하려는 마일스톤 또는 작엄을 추가하세요.
2. 개발자 여정 살펴보기누군가 제품을 발겆하고, 온보딩을 시자하며, 도움을 찾는 과정을 추적합니다. 불명확한 단계와 기술 담당자에 대한 질문을 기록합니다.
3. 우선순위와 담당자 합의함께 먼저 할 작업을 선택하고 자료를 검토하거나 질문에 답하거나 이벤트를 조정할 사람을 지명합니다.
4. 자료 준비 및 확인합의된 문서, 커뮤니티 가이드 또는 해커톤 리소스를 작성하거나 개선합니다. 제품 또는 엔지니어링 팀이 기술 세부 사항을 검증합니다.
5. 진행 상황 및 다음 조치 공유완료된 항목, 아직 결정이 필요한 사항, 다음 주기에 포함할 실용적인 개선 사항을 기록합니다.