독자부터 고려하는 암호화폐 백서 작성

이해해야 할 사람부터 시작하세요

유용한 백서는 독자가 가져오는 질문에 답합니다. 프로젝트가 무엇을 구축하는지, 접근 방식이 어떻게 작동하는지, 독자가 직접 확인할 수 있는 세부 사항을 설명합니다.

문서의 대상과 그들이 배워야 할 내용을 함께 합의하는 것부터 시작합니다. 개발자는 시스템 세부 사항과 가정이 필요할 수 있습니다. 신규 사용자는 제품의 목적과 주요 단계에 대한 명확한 설명이 필요할 수 있습니다. 하나의 문서가 여러 그룹을 대상으로 할 수 있지만, 구조는 각 독자가 적절한 수준의 세부 정보를 찾을 수 있도록 도와야 합니다.

팀에 기술 개요, 제품 페이지 및 엔지니어링 노트가 있다고 가정해 보겠습니다. 이러한 자료를 검토하고, 동일한 이야기를 전달하는 부분을 찾고, 아직 담당자가 없는 질문을 식별할 수 있습니다. 암호화폐 백서 작성 가이드는 초기 브리프를 수집하는 데도 도움이 될 수 있습니다. 제품 및 기술 세부 사항을 확인할 수 있는 사람을 초기에 대화에 참여시키세요. 이는 페이지 목표나 프로젝트에 대한 일반적인 설명보다 더 나은 출발점을 제공합니다.

각 문서에 하나의 명확한 역할을 부여하세요

백서, 라이트페이퍼 및 제품 문서는 각각 독자가 다른 작업을 수행하도록 도울 때 함께 작동할 수 있습니다. 작성 전에 이러한 역할을 합의하여 문서가 모든 설명을 반복하지 않고도 사실을 공유하도록 합니다.

1. 백서: 독자가 프로젝트 맥락, 설계 선택, 구현 상태 및 지원되는 기술 세부 사항 등 더 완전한 설명이 필요할 때 사용합니다.
2. 라이트페이퍼: 독자가 프로젝트의 핵심 아이디어에 대한 간결한 소개가 필요할 때 사용합니다. 모든 세부 사항을 포함하려고 하기보다는 더 심층적인 자료를 가리킬 수 있습니다.
3. 제품 문서: 기능, 작업 또는 통합 경로를 설명하는 데 사용합니다. 설명하는 워크플로우에 가깝게 지침을 유지합니다.

팀에 커뮤니티 구성원을 위한 간결한 소개와 기술 파트너를 위한 심층 설명이 있다고 가정해 보겠습니다. 먼저 공유 사실을 매핑한 다음 각 문서에 자체 개요를 제공할 수 있습니다. 이렇게 하면 각 문서가 독자에게 말을 걸면서 핵심 용어의 일관성을 유지할 수 있습니다. 더 광범위한 콘텐츠 계획을 위해 암호화폐 콘텐츠 제작 또는 Web3 카피라이팅과 문서를 연결할 수 있습니다. 올바른 조합은 이미 보유한 자료와 독자가 여전히 수행해야 할 작업에 따라 달라집니다.

원천 자료를 검토 가능한 초안으로 어떻게 전환하나요?

프로젝트의 실제 설명을 중심으로 자료를 구성하고 검토를 위해 미해결 질문을 표시하여 원천 자료를 초안으로 전환합니다. 개요는 전체 문서를 작성하기 전에 팀이 방향을 수정할 기회를 제공합니다.

알려진 것부터 시작하세요

제품 노트, 기술 사양, 다이어그램, 기존 문서 및 관련 토큰 정보를 검토합니다. 확정된 세부 사항과 제안 및 가정을 분리합니다. 두 출처가 일치하지 않으면 차이점을 표시하고 팀에 어떤 정보가 최신인지 문의합니다.

설명 순서를 유지하세요

작업 개요는 프로젝트 맥락에서 제안된 접근 방식, 제품 작동 방식, 중요한 설계 선택 및 구현 상태로 이동할 수 있습니다. 용어를 사용하기 전에 소개합니다. 토큰 또는 거버넌스 세부 사항은 독자가 프로젝트를 이해하는 데 도움이 되는 위치에 속하며, 채우기용이 아닙니다.

주장에 담당자를 지정하세요

각 중요한 진술에 대해 어떤 출처가 이를 뒷받침하고 누가 확인할 수 있는지 묻습니다. 기술 및 제품 검토자는 표현이 시스템 및 현재 제품 동작과 일치하는지 확인할 수 있습니다. 또한 다이어그램과 텍스트가 동일한 대상을 설명하는지 확인합니다. 팀이 투자자를 위한 별도 프레젠테이션이 필요한 경우 암호화폐 스타트업 피치덱과 언어를 조정할 수 있습니다. 그 목적을 백서와 구별되게 유지합니다.

검토를 작성 과정의 공유된 부분으로 만드세요

출시 3주 전에 새로운 언어 시장에 진입하는 지역 팀을 상상해 보세요. 팀에는 한 언어로 된 제품 노트와 다른 언어로 된 미해결 기술 질문이 있습니다. 먼저 확인된 정보와 질문을 분류한 다음, 초안 작성 전에 각 부분을 승인할 수 있는 사람을 합의할 것입니다.

차분한 검토 계획은 불확실성을 숨기지 않고 팀이 작업을 계속 진행하는 데 도움이 됩니다. 승인된 자료를 바탕으로 작성하고, 세부 사항이 충돌할 때 명확한 질문을 하며, 해결하기 쉬운 주석을 만듭니다. 예를 들어, 제품 기능이 아직 계획 중인 경우 사용 가능하다고 설명하지 않고 계획으로 표시할 수 있습니다.

검토자를 준비시키기 위해 다음을 제안합니다:

• 한 사람을 지정하여 팀 의견을 수집하고 반환하도록 합니다.
• 기술 담당자에게 시스템 설명과 다이어그램을 확인하도록 요청합니다.
• 제품 담당자에게 현재 기능과 용어를 확인하도록 요청합니다.
• 추가 증거나 승인이 필요한 주장을 표시합니다.

Brand Community는 구조, 명확성 및 원천 자료와의 일관성을 위한 선임 편집 검토를 포함합니다. 지원 시각 자료가 필요한 경우 Web3 디자인 서비스가 문서 프레젠테이션을 정렬하는 데 도움을 줄 수 있습니다. 팀은 제품 사실과 최종 승인에 대한 진실의 원천으로 남습니다.

최종 주장을 증거 범위 내에서 유지하세요

명확한 문서는 독자가 프로젝트의 설계, 상태 및 가정에 대한 설명을 검토하는 데 도움이 됩니다. 이러한 설명이 팀이 뒷받침할 수 있는 자료에 가깝게 유지될 때 가장 유용합니다.

백서는 상장 검토자가 보는 주장을 명확히 할 수 있지만, 플랫폼의 검토 또는 승인 결정을 통제할 수는 없습니다. 제공된 증거를 바탕으로 작성하고 뒷받침되지 않는 주장을 표시합니다. 기술, 법률 및 토큰 모델 승인은 자격을 갖춘 담당자에게 맡깁니다.

개요가 승인되면 문서가 구체화되는 동안 주제별 검토자가 응답할 수 있도록 섹션별로 초안을 작성합니다. 팀은 각 검토 시점에 통합된 의견 세트를 반환할 수 있습니다. 그런 다음 합의된 변경 사항을 처리하고 문서 전체의 용어를 확인하며 합의된 파일을 제공합니다. 소수의 지정된 검토자와 미해결 질문에 대한 명확한 담당자는 반복적인 편집이 텍스트를 다른 방향으로 끌어가는 것을 방지하는 데 도움이 됩니다.

동일한 승인된 사실은 라이트페이퍼, 제품 페이지 및 기타 콘텐츠를 안내할 수 있습니다. 더 광범위한 계획을 위해 소셜 미디어 및 콘텐츠 허브를 살펴보세요. 시작하려면 프로젝트 개요, 기존 문서, 대상 독자 및 기술 주장을 승인할 사람을 보내주세요. 자료를 검토하고 미해결 질문을 식별하며 명확한 작성 계획을 제안합니다.

이용 방법

1. 자료 공유제품 개요, 기존 문서, 대상 독자 및 승인 연락처를 보내주세요. 확정된 사항과 아직 논의 중인 사항을 표시해 주세요.
2. 형식 및 개요 합의문서의 목적과 구조를 함께 결정합니다. 팀은 전체 초안 작성 전에 개요를 검토합니다.
3. 주제별 팀과 함께 초안 작성승인된 자료를 바탕으로 작성하고 답변할 수 있는 사람에게 질문을 보냅니다.
4. 검토 및 의견 해결검토자가 정확성과 명확성을 확인합니다. 합의된 변경 사항을 처리하고 미해결 주장을 표시합니다.
5. 최종 파일 준비문서 전체의 일관성을 확인하고 승인 및 게시 워크플로우를 위해 합의된 파일을 제공합니다.