ユーザーの行動に沿ったWeb3 開発サービス

Web3構築で最初にサポートすべきユーザーアクションはどれですか？

Web3構築は、テクノロジーのリストではなく、ユーザーが何をする必要があるかから始めるべきです。その選択により、どの部分をオンチェーンにするか、どの部分をインターフェースにするか、何を後回しにできるかをチームが判断しやすくなります。

例えば、トークンプロジェクトでは、定義されたトークンの動作とデプロイメントサポートが必要になる場合があります。ウォレット接続アクションを伴うプロダクトでは、情報を表示したりトランザクションを送信したりできるdAppが必要になるかもしれません。コミュニティ体験にはTelegramミニアプリが適している場合もあります。私たちはそれらのユーザーアクションを具体的なソフトウェア部品に変換し、各部品が必要とするサービスやアクセスを明記します。

まずは、新規ユーザーが何を見るか、何ができるか、次に何が起こるべきかを考えてみてください。そして、期待される動作を平易な言葉で説明してください。トークンの作成とデプロイメントはトークン開発にマッピングできます。あるいは、スマートコントラクト開発を通じて、インタラクションの背後にあるルールを検討することもできます。ユーザー向けの体験については、dApp開発が計画の適切な部分になるかもしれません。

これにより、最初の会話が実践的になります。必須のローンチ機能、依存関係、後回しにするアイデアを別々に特定するため、チームは開発開始前に選択肢をレビューできます。

明確な構築範囲があればロードマップの更新が容易になります

明確な範囲があれば、チームは何を構築中で、何にまだ決定が必要かを説明できます。また、作業をレビューする人に具体的な確認対象を提供します。

アンバサダープログラムのリーダーがロードマップの更新を間近に控えていると想像してください。チームはトークン機能とTelegram体験について言及したいが、正確なユーザージャーニーはまだ固まっていません。私たちは、アンバサダーが何をできるべきか、どのネットワークが必要か、どの既存サービスを接続する必要があるかを尋ねます。そして、確定した機能と未解決の質問を分離し、更新が仮定ではなく計画を説明するようにします。

複数の部分からなるプロダクトの場合、それらの部分がどのように連携するかを記録します。コントラクトが特定の動作を提供し、インターフェースがユーザーにそのコントラクトと対話する方法を提供する場合があります。Telegramミニアプリは別のジャーニーを処理するかもしれません。チームが公開プロダクトサイトも必要とする場合は、計画をWeb3ウェブサイト開発に接続できます。ウォレットの動作が中心的な場合は、仮想通貨ウォレット開発に独自の決定とレビューが必要になるかもしれません。

このような初期の会話は、後でのやり直しを減らすことができます。ロードマップは有用なまま維持され、構築は共有された期待から始まります。

チームが受け取れるもの

プロジェクトで合意されたソフトウェア部品と、チームがレビューと作業継続に必要な情報を受け取ります。機能リストを完全な計画として扱うのではなく、開発開始前に内容を明確にします。

概要に応じて、作業には以下が含まれる場合があります：

• 合意されたコントラクト、アプリケーション、またはミニアプリコンポーネントのソースコード。
• 選択された環境向けのデプロイメントまたは設定手順。
• チェックされた期待動作を示すテストケースとノート。
• 統合の詳細、前提条件、実践的な引き継ぎノート。
• 作業を引き継ぐ担当者との最終ウォークスルー。

キックオフチェックリストを使用して、機能、アクセス、依存関係、合格基準を収集します。2つのレビューポイントに合意します。1つ目は実装前で、計画を確認します。2つ目は引き継ぎ前で、合意された基準に対して結果をチェックします。作業中に不一致があれば報告できます。そうすれば、最後になって初めて発見することを防げます。

チームがすでにdAppを持っているが、それに加えてAIワークフローが必要だとします。その場合は、AIエージェント開発を通じて別の部品として議論できるため、ユーザー向けプロダクトと自動化ワークフローにそれぞれ明確な期待を持たせることができます。

構築を前進させる4つの決定

有用なWeb3開発計画は、コードを構築可能と見なす前に、4つの実践的な質問に答えます。明確な回答により、プロダクトチームと私たちの両方にとってレビューが容易になります。

これらの詳細をチームとレビューし、未回答の項目を記録します。2つの合理的な技術的経路がある場合は、日常言語でトレードオフを説明します。その後、選択した経路を記録します。また、テスト環境、デザインファイル、既存のリポジトリが利用可能かどうかも確認します。

最初の週の有用な目標は、機能とレビューポイントに関する共通理解です。急いだ約束のリストではありません。アクセスやプロダクトルールが欠けている場合は、未決定としてマークします。これにより、チームは明確な次のアクションを得られ、実際に行った選択に基づいた実装を維持できます。

プロダクトが形になるにつれて外部依存関係を可視化し続ける

優れた構築は、合意された動作をテスト可能にし、チームに使いやすい引き継ぎを残します。早期に確定すべき主な事項は、プロダクトルール、統合アクセス、各機能をレビューする担当者です。

チェーンツール、ウォレットの動作、Telegramのレビュー判断、サードパーティサービスの可用性は、当社の管理外です。それらの承認や中断のない運用を約束することはできません。私たちは、一緒に合意した実装、チェック、引き継ぎにコミットできます。また、依存関係が暗黙の前提になる前に特定します。

開始するには、Brand Communityにユーザージャーニーと対象チェーンを含む短いプロダクト概要を送ってください。要求された機能と、利用可能なリポジトリやデザイン参照を含めてください。3つの有用な開始詳細は、ユーザーが何をすべきか、どの既存サービスを接続する必要があるか、チームが作業のレビューに何を使用するかです。1つの回答がまだ未確定の場合は、それも含めてください。

共有された内容をレビューし、未回答のポイントを明確にします。その後、提案される機能、レビューのタイミング、引き継ぎを提示します。何を最初に構築するかを決定する前に、具体的な計画を検討できます。