開発者があなたのSDKを試す瞬間のためのWeb3 DevRel

Web3 DevRel は、開発者の前進をどこで支援できますか？

Web3 DevRel は、開発者がプロダクトを発見してから次に進むための明確な経路を必要とする場合に役立ちます。SDKを試す次のステップを支援します。プロダクトの説明、技術資料、質問できる場所を結びつけます。そうすることで、チームは今重要な障害に集中できます。

まずは開発者が意図するタスクから始めます。プロトコルチームは、統合の始め方を説明する必要があるかもしれません。ツールチームは、シンプルな最初のサンプルを必要とするかもしれません。開発者がプライベートなガイダンスなしで何を見つけられるかを確認します。説明が不明瞭になる箇所や、技術的な詳細を確認できる担当者を特定します。

この作業は、今後のローンチをサポートできます。ローンチを待つ必要はありません。まだ広範なリリース計画を策定中の場合は、開発者パスをGo-to-Market戦略に結びつけてください。そうすることで、チームは開発者が使えるものとプロジェクトが発信できる内容を一致させることができます。

最初の会話では、3つのことを確認します。リーチしたい開発者を挙げてください。完了すべき最初のタスクを説明してください。技術的な正確性をレビューできる担当者を特定してください。これらの詳細が明確であれば、実用的なギャップに焦点を当てた計画を立てられます。チャネル選びから始めることはありません。

プレスリリースは、開発者向けウェルカムのギャップを露呈することがあります

開発者サポートは、質問に答える担当者が正確な情報への明確な経路を持っている場合に効果的です。プレスリリースは新たな注目を集めることができます。しかし、理解しやすい最初のステップや技術的な質問の担当者に代わるものではありません。

例えば、パートタイムの管理者がいるDiscordサーバーが初めてのプレスリリースを準備しているとします。メンバーはSDKがどこから始まるのかを尋ねます。管理者は日常的な質問をさばき続ける必要があります。私たちはそれらの質問を現在のドキュメントに遡って追跡します。そして、回答を検証できる担当者を合意し、プレスリリースが公開される前に短い引き継ぎメモを準備します。

その準備により、管理者は参照できる有益な情報を得られます。また、エンジニアは自分たちのインプットが必要な質問をより明確に把握できます。チームは、次のタスクがガイドの改善、サンプルの追加、コミュニティ返信のルーティン設定のいずれであるかを判断できるようになります。

私たちは、お客様が既に持っているチャネルと資料から始めます。プロジェクトにアクティブなグループがある場合は、新しいグループを推奨する前に、それがどのように開発者をサポートしているかをレビューします。より広範な開発者コミュニティプログラムは、このサポートを継続的な教育と結びつけることができます。適切な最初の一手は、単に既存の回答を見つけやすくすることかもしれません。

使いやすくできること

作業は、開発者が実際の次のステップを踏めるようにするものでなければならず、単に資料を増やすだけではいけません。お客様のプロダクトにとって重要な部分を合意します。そして、チームがメンテナンスできる部分を準備または改善します。

例えば、小規模なプロトコルチームがハッカソンのチャレンジを準備しているとします。SDKのサンプルはまだ変更中です。参加者が試すべきタスクをマッピングします。どの手順に技術的なレビューが必要かを確認します。そして、イベント資料を共有する前にサポート経路を明確にします。

優先順位に応じて、作業には以下が含まれる場合があります：

• プロダクト紹介から最初のSDK使用までの経路のレビュー。
• より明確なセットアップガイダンス、ワークフローの説明、または開発者向けサンプル。
• チームが対応すべきドキュメントのギャップを優先順位付けしたリスト。
• コミュニティ対応ガイダンス（質問の担当とエスカレーションを含む）。
• チャレンジ概要、セットアップノート、提出ガイダンスなどのハッカソン資料。

お客様のプロダクトまたはエンジニアリングチームが技術的な詳細を確認します。私たちは体験の形成と作業の調整を支援します。各項目について、誰がレビューするかを合意します。また、公開前に「完了」の定義を明確にします。これにより、資料はプロダクトが現在サポートできる内容に基づいたものになります。

シンプルな作業リズムで詳細を可視化します

合意されたタスク、技術レビュー、明確な進捗記録に基づいて作業を整理します。スケジュールは、お客様が既にお持ちの資料と、適切な担当者がレビューできる速さに応じて決まります。

作業を進めるために3つのチェックポイントを設けます。まず、現在の開発者ジャーニーをレビューします。次に、優先順位と担当者を合意します。その後、お客様の技術チームが完成した資料を確認します。また、お客様側で1名の担当者を指名し、決定事項をまとめ、質問が埋もれないようにします。

エンジニアリングのインプットが必要な場合、2つの技術レビューポイントを合意します。1つ目は、動作に関する主張をドラフトする前です。2つ目は、サンプルや手順を公開する前です。共有の進捗ノートには、完了した項目、未解決の質問、次の決定事項を記録します。リリース後もローンチ作業が続く場合は、ローンチ後のサポートが開発者教育を次のフェーズに結びつけることができます。

開発者がすでに求めているプロダクトのコンテキストをお持ちください

最初のレビューを有意義にするには、チームが共有できる資料が必要です。また、技術的な詳細を確認できる担当者も必要です。SDKまたはプロダクト概要、現在のドキュメント、対象とする開発者層、そして今後のマイルストーンをご用意ください。よくある質問の短いリストもあると役立ちます。

開発者が直面する摩擦を探します。不明確な前提条件、欠落したステップ、確認が必要なサンプル、担当者のいない質問などです。そして、何を最初に対処するか、チームがどのように作業をレビューするかを合意します。差し迫ったニーズがより広範な計画策定である場合は、トークンローンチと成長計画が開発者向け資料をリリース全体に結びつけるのに役立ちます。

合意されたドキュメント、コミュニティガイダンス、ハッカソン資料を準備できます。しかし、独立した開発者がSDKを統合するかどうかを決定することはできません。また、イベント主催者は独自の参加ルールと選考基準を設定します。私たちの責務は、共に合意した作業とレビュープロセスにあります。

Brand Communityに、プロダクト概要、現在のドキュメント、準備中のマイルストーンをお送りください。それらの資料をレビューし、最も有用な最初のタスクを特定します。その後、チームで検討いただくための明確な計画をご提案します。

仕組み

1. プロダクトの全体像を共有するSDKまたはプロダクト概要、現在のドキュメント、対象とする開発者層をお送りください。作業でサポートしたいマイルストーンやタスクもお知らせください。
2. 開発者ジャーニーをウォークスルーする開発者がどのようにプロダクトを発見し、オンボーディングを開始し、ヘルプを見つけるかを追跡します。不明瞭なステップや技術担当者への質問を特定します。
3. 優先順位と担当者を合意する一緒に最初に行う作業を選択し、資料のレビュー、質問への回答、イベントの調整を行う担当者を指名します。
4. 資料を準備し確認する合意されたドキュメント、コミュニティガイダンス、またはハッカソンリソースを作成または改善します。お客様のプロダクトまたはエンジニアリングチームが技術的な詳細を検証します。
5. 進捗と次のアクションを共有する完了したこと、まだ決定が必要なこと、次のサイクルで取り組むべき実用的な改善点を記録します。