코인 백서 작성법: 따라 하기 쉬운 가이드

작성 전에 어디서부터 시작해야 하나요?

문서가 누구를 위한 것인지, 그 독자가 무엇을 이해해야 하는지 결정하는 것부터 시작하세요. 간단한 준비 과정을 통해 첫 번째 초안의 초점을 유지할 수 있습니다.

1. 독자를 지정하세요. 제품 사용자, 개발자, 파트너 또는 토큰 보유자 등 주요 청중을 선택하세요.
2. 문서의 역할을 설정하세요. 누군가가 이 문서를 읽은 후 이해해야 할 내용을 적어보세요.
3. 프로젝트를 간결하게 설명하세요. 문제, 제안된 해결책, 프로젝트의 현재 단계를 명시하세요.
4. 질문을 나열하세요. 이 독자에게 중요한 제품 사용, 시스템 설계, 토큰 역할에 관한 질문을 포함하세요.
5. 정보 소유자를 찾으세요. 각 주제를 확인할 수 있는 사람이나 문서를 연결하세요.

아마 전날 밤 소규모 파트너십 팀을 상상해보세요. 그들은 프로젝트에 대한 간단한 설명이 필요하며, 서로 연결되지 않은 주장 더미는 필요하지 않습니다. 우리는 그들이 백서가 설명해야 할 내용을 나열한 다음, 공유하기 전에 팀 확인이 필요한 사항을 표시하도록 도울 것입니다.

팀이 프로젝트를 몇 문장으로 간결하게 설명할 수 없다면 잠시 멈추세요. 각 장을 작성하기 전에 핵심 아이디어를 함께 정리하세요. 이 작은 멈춤은 반복적인 설명과 모든 청중을 동시에 만족시키려는 문서를 방지할 수 있습니다.

독자에게 프로젝트를 이해할 수 있는 경로를 제공하세요

유용한 구조는 독자의 문제에서 프로젝트의 해결책으로 이동한 다음 시스템과 미해결 질문을 설명합니다. 핵심 설명을 초반에 배치하여 독자가 프로젝트의 목적을 찾기 위해 검색할 필요가 없도록 하세요.

유연한 순서는 간단한 요약으로 시작할 수 있습니다. 그런 다음 문제와 영향을 받는 사람들을 소개하세요. 다음으로 제품과 주요 사용자 여정을 설명하세요. 시스템 설계 방식을 보여준 다음, 관련이 있는 경우 토큰의 역할을 설명하세요. 프로젝트 상태, 종속성 및 위험으로 마무리하세요. 팀 세부 정보, 출처 및 공개 사항은 독자가 자료를 평가하는 데 도움이 될 때 추가하세요.

예를 들어, 독자가 제품이 무엇을 하는지 알기도 전에 토큰 할당 테이블을 본다고 상상해보세요. 그들은 할당이 왜 중요한지 이해하는 데 어려움을 겪을 수 있습니다. 제품 설명을 먼저 배치한 다음 각 토큰 기능을 시스템의 실제 부분에 연결하세요.

이것을 필수 장 목록이 아닌 경로로 취급하세요. 문서의 목적에 도움이 되지 않는 자료는 생략하고, 독자가 혼란스러워할 수 있는 경우 생략 이유를 설명하세요. 다이어그램은 누가 행동하고, 무엇이 이동하며, 사용자가 무엇을 관찰할 수 있는지 표시할 때 흐름을 명확히 할 수 있습니다. 서면 설명과 일관성을 유지하세요. 토큰 런칭 체크리스트는 백서가 다른 런칭 자료와 어떻게 조화를 이루는지 확인하는 데 도움이 될 수 있습니다.

백서에 무엇을, 언제 포함해야 하나요?

독자가 프로젝트를 이해하거나 중요한 주장을 확인하는 데 도움이 되는 주제를 포함하세요. 아래 표는 실용적인 출발점을 제공합니다. 프로젝트와 청중에 맞게 조정하세요. 코인 백서 작성법을 고려할 때, 이 표는 기본적인 가이드라인을 제시합니다.

모든 주제에 동일한 비중을 둘 필요는 없습니다. 기술적인 독자는 구성 요소와 종속성에 대한 더 자세한 설명이 필요할 수 있습니다. 더 넓은 청중은 더 간단한 언어로 제품 여정과 토큰 목적이 필요할 수 있습니다. 어느 경우든 전문 용어는 처음 등장할 때 정의하세요.

기능이 아직 구축 중이라면 계획된 것이지 실제가 아니라고 말하세요. 토큰 수치가 확정된 것인지 제안된 것인지 명시하세요. 세부 사항이 문서의 목적 범위를 벗어난다면 독자가 추측하게 두지 말고 명확히 말하세요. 백서 및 라이트페이퍼 작성 페이지는 코인 백서 작성법에 대한 작성 지원이 문서 구성에 어떻게 도움이 되는지 설명합니다.

독자가 각 중요한 주장을 확인할 수 있나요?

중요한 진술에 명확한 상태와 출처가 있을 때 독자는 문서를 더 쉽게 평가할 수 있습니다. 초안 작성 중에 각 주장을 현재 사실, 설계 의도, 가정 또는 계획으로 표시하세요. 이 간단한 구분은 팀이 미래 작업을 이미 사용 가능한 것으로 제시하는 것을 방지하는 데 도움이 됩니다.

초안 옆에 작업 중인 주장 목록을 유지하세요. 각 항목에 대해 표현, 상태, 출처 및 확인 가능한 사람을 기록하세요. 제품 기능에 대한 진술은 데모나 제품 문서를 가리킬 수 있습니다. 시스템 동작에 대한 진술은 기술 담당자에게 문의해야 합니다. 토큰 설명은 팀의 현재 승인된 정보와 대조하여 확인해야 합니다.

다이어그램, 표 및 본문 텍스트에서 동일한 이름과 용어를 사용하세요. 중요한 주장에 출처가 없으면 팀이 다른 방식으로 이를 뒷받침할 수 있는지 물어보세요. 필수적이지 않다면 제거하세요. 여전히 불확실하다면 불확실성과 그 원인을 평이한 언어로 설명하세요.

두 번째 확인을 위해 작성 그룹 외부의 사람에게 요약을 읽은 후 프로젝트를 설명해 달라고 요청하세요. 그들이 멈추거나 다른 설명을 하는 부분을 주목하세요. 그 순간은 문서가 더 매끄러운 표현뿐만 아니라 더 명확한 설명이 필요한 부분을 보여줍니다.

큰 질문을 남기는 작은 초안 작성 함정

발견하기 가장 어려운 문제는 종종 섹션 간의 간격입니다. 최종 검토는 철자와 레이아웃뿐만 아니라 모순과 누락된 맥락을 찾아야 합니다.

• 모호한 목적: 독자는 제품이 누구를 위한 것인지 또는 무엇을 변화시키는지 알 수 없습니다.
• 사실로 쓰여진 계획: 미래 기능이 오늘 사용 가능한 것처럼 들립니다.
• 레이블 없는 토큰 세부 정보: 독자는 수치가 무엇을 설명하는지 또는 확정되었는지 알 수 없습니다.
• 확인되지 않은 주장: 설계, 보안 또는 성능에 대한 진술에 명명된 출처가 없습니다.

간단한 읽기를 시도해보세요. 프로젝트에 처음 접하는 사람에게 무엇이 실제이고, 무엇이 계획이며, 토큰이 어떻게 적합한지 설명해 달라고 요청하세요. 그런 다음 그들의 설명을 팀의 의도된 설명과 비교하세요. 혼란스러운 부분을 수정하고 관련 섹션에서 동일한 문제를 확인하세요.

백서는 프로젝트를 설명할 수 있지만, 법적 준수를 확립하거나 거래소의 승인을 보장할 수는 없습니다. 이러한 결정은 관련 고문과 플랫폼에 속하며, 그들의 검토와 요구 사항은 문서 작성자의 통제 범위를 벗어납니다.

작성 계획이 필요하다면 백서 작성 비용 가이드에서 관련 작업을 비교하여 어떤 지원이 적합한지 결정하세요.

프로젝트 변경에 맞춰 백서를 최신 상태로 유지하세요

게시된 백서는 누군가가 독자가 볼 수 있는 프로젝트와 일치하도록 유지할 때 유용합니다. 제품 기능, 토큰 세부 정보 또는 중요한 종속성이 변경될 때 이를 인지할 수 있는 담당자를 지정하세요.

명확한 버전 레이블을 유지하고 백서를 수정할 때마다 변경된 내용을 기록하세요. 산문과 함께 다이어그램, 참조 및 정의된 용어를 다시 확인하세요. 이전 버전이 계속 제공되는 경우 독자에게 버전 간 변경 사항을 이해하는 데 도움이 되는 간단한 메모를 제공하세요.

백서가 게시된 후 팀이 제품 흐름을 업데이트한다고 상상해보세요. 담당자는 새 흐름을 백서와 비교하고 이를 설명하는 모든 구절을 찾을 수 있습니다. 그런 다음 기술 담당자에게 대체 텍스트를 확인하도록 요청하세요. 이 확인은 유지 관리를 작성 계획의 일부로 만들고 사후 고려 사항이 아니게 합니다.

웹사이트 요약, 토큰 자료 및 런칭 커뮤니케이션을 백서의 설명과 일관되게 유지하세요. 다른 사람의 검토가 필요하다면 Brand Community에 현재 초안이나 메모를 보내주세요. 의도된 독자와 제품, 기술 및 토큰 세부 정보를 확인할 수 있는 사람의 이름을 포함하세요. 우리는 개요 검토부터 시작하여 초안 작성 전에 해결해야 할 질문을 식별할 것입니다. 더 실용적인 자료는 블로그에서 찾을 수 있습니다.

이용 방법

1. 독자와 목적 설정문서가 누구를 위한 것인지, 그들이 무엇을 이해해야 하는지 적으세요. 실제, 계획 또는 미결정 사항을 표시하세요.
2. 출처와 소유자 수집제품 노트, 기술 자료 및 승인된 토큰 세부 정보를 수집하세요. 각 주제를 확인할 수 있는 사람을 지정하세요.
3. 개요 정리독자의 주요 질문을 명확한 순서로 배열하세요. 초안 작성 전에 누락된 정보를 해결하세요.
4. 초안 작성 및 확인평이한 언어를 사용하고 가정에 레이블을 붙이세요. 관련 팀 구성원에게 출처 자료와 대조하여 자신의 주장을 확인하도록 요청하세요.
5. 수정 및 유지 관리의견을 해결하고, 용어를 확인하며, 승인된 버전을 기록하세요. 프로젝트 세부 사항이 변경될 때 백서를 검토할 사람을 지정하세요.