사용자가 제품을 사용하는 방식에 맞춘 웹3 개발

웹3 빌드가 가장 먼저 지원해야 할 사용자 작업은 무엇인가요?

웹3 빌드는 기술 목록이 아니라 사람이 해야 할 일부터 시작해야 합니다. 이러한 선택은 팀이 어떤 부분을 온체인에 둘지, 어떤 부분을 인터페이스에 둘지, 그리고 무엇을 나중으로 미룰지 결정하는 데 도움이 됩니다.

예를 들어, 토큰 프로젝트는 정의된 토큰 동작과 배포 지원이 필요할 수 있습니다. 지갑 연결 작업이 있는 제품은 사람들이 정보를 보거나 트랜잭션을 제출할 수 있는 dApp이 필요할 수 있습니다. 커뮤니티 경험은 텔레그램 미니 앱에 적합할 수 있습니다. 저희는 이러한 사용자 작업을 구체적인 소프트웨어 조각으로 전환하고 각 조각에 필요한 서비스나 접근 권한을 기록합니다.

새 사용자가 무엇을 보고, 무엇을 할 수 있으며, 다음에 무엇이 일어나야 하는지 질문하는 것부터 시작할 수 있습니다. 그런 다음 예상되는 동작을 평이한 용어로 설명하세요. 토큰 생성 및 배포를 토큰 개발에 매핑할 수 있습니다. 또는 상호작용 뒤에 있는 규칙을 스마트 컨트랙트 개발을 통해 살펴볼 수 있습니다. 사용자 대면 여정의 경우 dApp 개발이 계획의 적절한 부분일 수 있습니다.

이렇게 하면 첫 대화가 실용적으로 유지됩니다. 필수 출시 기능, 종속성 및 이후 아이디어를 별도로 식별하여 팀이 개발을 시작하기 전에 선택 사항을 검토할 수 있습니다.

명확한 빌드 경계가 있으면 로드맵 업데이트가 더 쉽습니다

명확한 경계를 통해 팀은 무엇이 구축되고 있는지와 아직 결정이 필요한 사항을 설명할 수 있습니다. 또한 작업을 검토하는 사람들에게 확인할 구체적인 대상을 제공합니다.

앰배서더 프로그램 책임자가 로드맵 업데이트를 곧 발표하려는 상황을 상상해 보세요. 팀은 토큰 기능과 텔레그램 경험을 언급하고 싶지만, 정확한 사용자 여정은 아직 구체화 중입니다. 저희는 앰배서더가 무엇을 할 수 있어야 하는지, 제품이 필요한 네트워크, 그리고 연결해야 하는 기존 서비스를 물을 것입니다. 그런 다음 확인된 기능과 미해결 질문을 분리하여 업데이트가 가정이 아닌 계획을 설명하도록 합니다.

여러 부분으로 구성된 제품의 경우, 해당 부분들이 어떻게 만나는지 기록합니다. 컨트랙트는 지정된 동작을 제공하고, 인터페이스는 사용자에게 상호작용 방법을 제공합니다. 텔레그램 미니 앱은 별도의 여정을 처리할 수 있습니다. 팀이 공개 제품 사이트도 필요로 하는 경우, 계획을 웹3 웹사이트 개발과 연결할 수 있습니다. 지갑 동작이 핵심인 경우, 암호화폐 지갑 개발은 자체 결정과 검토가 필요할 수 있습니다.

이러한 초기 대화는 이후의 불필요한 왕복을 줄일 수 있습니다. 로드맵은 유용하게 유지되고, 빌드는 공유된 기대치로 시작됩니다.

팀이 받을 수 있는 것

프로젝트에 대해 합의된 소프트웨어 조각과 팀이 작업을 검토하고 계속하는 데 필요한 정보를 받게 됩니다. 기능 목록을 완전한 계획으로 취급하지 않고, 개발을 시작하기 전에 내용을 명확히 합니다.

브리프에 따라 작업에는 다음이 포함될 수 있습니다:

• 합의된 컨트랙트, 애플리케이션 또는 미니 앱 구성 요소의 소스 코드.
• 선택한 환경에 대한 배포 또는 구성 지침.
• 어떤 예상 동작이 확인되었는지 보여주는 테스트 케이스 및 노트.
• 통합 세부사항, 가정 및 실용적인 인계 노트.
• 작업을 이어받을 사람들과의 최종 워크스루.

저희는 킥오프 체크리스트를 사용하여 기능, 접근 권한, 종속성 및 승인 기준을 수집합니다. 2개의 검토 시점에 합의합니다. 첫 번째는 구현 전에 계획을 확인하기 위한 것입니다. 두 번째는 인계 전에 합의된 기준에 따라 결과를 확인하기 위한 것입니다. 작업이 진행되는 동안 불일치 사항을 제기할 수 있습니다. 이렇게 하면 마지막에 가서야 발견하는 일이 없습니다.

팀에 이미 dApp이 있지만 그와 함께 AI 워크플로우를 원한다고 가정해 보겠습니다. AI 에이전트 개발을 통해 별도의 조각으로 논의할 수 있으므로, 사용자 대면 제품과 자동화된 워크플로우는 각각 별도의 기대치를 갖습니다.

빌드 진행에 도움이 되는 네 가지 결정

유용한 웹3 개발 계획은 코드가 빌드 준비가 된 것으로 간주되기 전에 네 가지 실용적인 질문에 답합니다. 명확한 답변은 제품 팀과 저희 모두의 검토를 더 쉽게 만듭니다.

저희는 이러한 세부사항을 팀과 검토하고 답변되지 않은 항목을 기록합니다. 두 가지 합리적인 기술적 경로가 있는 경우, 일상적인 언어로 장단점을 설명합니다. 그런 다음 선택한 경로를 기록합니다. 또한 테스트 환경, 디자인 파일 또는 기존 리포지토리를 사용할 수 있는지 확인합니다.

첫 주에 유용한 목표는 기능과 검토 시점에 대한 공유된 이해입니다. 서두른 약속 목록이 아닙니다. 접근 권한이나 제품 규칙이 누락된 경우, 이를 미결정 사항으로 표시합니다. 이는 팀에게 명확한 다음 조치를 제공하고 구현이 실제로 내린 선택에 기반하도록 합니다.

제품이 구체화됨에 따라 외부 종속성을 계속 확인하세요

좋은 빌드는 합의된 동작을 테스트 가능하게 만들고 팀이 사용 가능한 인계를 받을 수 있도록 합니다. 초기에 해결해야 할 주요 사항은 제품 규칙, 통합 접근 권한 및 각 기능을 검토할 사람입니다.

체인 도구, 지갑 동작, 텔레그램 검토 결정 및 타사 서비스 가용성은 저희 통제 범위를 벗어납니다. 저희는 이들의 승인이나 중단 없는 운영을 약속할 수 없습니다. 저희는 함께 합의한 구현, 점검 및 인계를 약속할 수 있습니다. 또한 숨겨진 가정이 되기 전에 종속성을 식별합니다.

시작하려면 Brand Community에 사용자 여정과 대상 체인이 포함된 간단한 제품 브리프를 보내주세요. 요청된 기능과 사용 가능한 리포지토리 또는 디자인 참조 자료를 포함하세요. 유용한 세 가지 시작 세부사항은 사용자가 해야 할 일, 연결해야 하는 기존 서비스, 그리고 팀이 작업을 검토하는 데 사용할 항목입니다. 하나의 답변이 아직 열려 있는 경우에도 포함하세요.

저희는 공유된 내용을 검토하고 답변되지 않은 사항을 명확히 합니다. 그런 다음 제안된 기능, 검토 시점 및 인계를 제시합니다. 무엇을 먼저 구축할지 결정하기 전에 고려할 구체적인 계획을 갖게 됩니다.