Как написать вайтпейпер: превратите факты проекта в читаемый документ

Что должно давать введение, чтобы читатель мог проверить?

Целевое утверждение в одном предложении даёт читателю критерий для оценки всего документа. Оно должно определять проект, его целевую аудиторию и решение или понимание, которое поддерживает документ. Делайте это утверждение конкретным для продукта, а не широким обещанием рынку.

Перед написанием выберите основного читателя. Разработчику могут понадобиться поведение компонентов и допущения по интеграции. Потенциальному пользователю — поток продукта и его текущие ограничения. Держателю токена — документированные функции токена и правила управления. Документ может обслуживать несколько групп, но назовите первую аудиторию и выстраивайте детали соответственно.

Составьте короткую вводную заметку с этими 4 вопросами:

• Какую проблему решает проект и для кого?
• Что пользователь или разработчик может сделать сегодня?
• Какие возможности остаются предложенными или в разработке?
• Что читатель должен иметь возможность оценить после прочтения?

Помечайте каждый ответ как: работает, протестировано, запланировано или не решено. Такая маркировка статуса помогает предотвратить восприятие пункта дорожной карты как доступной функции. Если проект на ранней стадии, укажите, что ещё неизвестно. Затем используйте целевое утверждение, чтобы удалить отрывки, которые не помогают названному читателю понять или оценить проект.

Какие части должны быть в карте документа вайтпейпера?

Структура из 7 частей может провести читателя от проблемы проекта до его открытых вопросов. Воспринимайте её как рабочую карту, а не обязательный шаблон. Добавляйте раздел только тогда, когда он объясняет что-то существенное для этого проекта.

Полезная последовательность:

• Резюме: проблема, подход и текущий статус разработки.
• Проблема и контекст: кто сталкивается с проблемой и что оставляют нерешённым существующие подходы.
• Продукт или протокол: компоненты, пользовательский поток и границы системы.
• Технический дизайн: релевантная архитектура, зависимости и допущения по безопасности.
• Дизайн токена, если применимо: функция, правила эмиссии, распределение и механизмы управления.
• Дорожная карта и ответственность: запланированные работы, ответственные за решения и зависимости.
• Риски и открытые вопросы: известные ограничения и нерешённые дизайнерские решения.

Не добавляйте токен-экономику в проект без токена. Для проекта с токеном не прячьте основные механики в приложение. Помещайте краткое объяснение перед специализированными деталями. Используйте приложение для материалов, которые поддерживают утверждение, но прерывают основное объяснение.

Для планирования запуска, выходящего за рамки документа, см. чек-лист токен сейла. Согласуйте его факты с вайтпейпером. Для отдельного обзора подготовки к листингу обратитесь к руководствам по листингу на CoinMarketCap и листингу на CoinGecko. Эти ресурсы решают разные задачи; их не следует использовать как доказательство того, что проект соответствует требованиям платформы.

Как читатели могут отследить утверждение до его источника?

Реестр утверждений показывает, какие утверждения требуют проверки до шлифовки текста. Создайте его для каждого значимого утверждения о поведении продукта, механике токена, допущениях по безопасности или статусе проекта. Запись делает пробелы видимыми, пока черновик ещё легко изменить.

Используйте 4 поля для каждой записи: точное утверждение, источник или заявленное допущение, статус и рецензент. Наша стандартная проверка использует 3 контрольные точки: соответствие источнику, соответствие статусу и подпись ответственного. Руководство по продукту может подтвердить описание пользовательского потока. Запись дизайна может объяснить архитектурное решение. Прогноз должен быть обозначен как оценка, а не представлен как наблюдаемый результат. Если подтверждающих материалов нет, уточните утверждение или удалите его.

Отрывки о токене требуют точных определений. Объясните, что означает каждый термин эмиссии и как работают правила распределения или разблокировки. Укажите, какие правила задокументированы, а какие могут измениться через управление или другой описанный процесс. Не подразумевайте, что владение токеном даёт права, если это не подтверждается условиями проекта.

Этот реестр также помогает будущим редакторам найти текст, затронутый изменениями продукта. Сравните его записи с текущими материалами проекта и с чек-листом токен сейла. В GeoMarketing Experts рецензент может вернуть размеченный черновик с вопросами, сгруппированными по ответственному. Для заказа написания см. написание вайтпейпера и лайтпейпера; для объёма оплачиваемой работы см. цены на крипто вайтпейпер.

Сколько технических деталей должно быть в основном документе?

Диаграмма системы и её подпись должны рассказывать ту же историю, что и текст. Используйте технические детали, чтобы показать, как компоненты взаимодействуют и на каких допущениях основано их поведение. Список сетей, контрактов или криптографических терминов недостаточен без этих взаимосвязей.

Начните с обзора системы на простом языке. Затем объясните каждый важный компонент через его роль, входы, выходы и зависимости. Для процесса с несколькими участниками укажите, кто начинает действие, что проверяет система и что происходит, когда зависимость недоступна. Определяйте специализированные термины при первом использовании. Держите один термин привязанным к одному значению на протяжении всего документа.

Используйте диаграммы для отображения потоков, границ доверия или перемещения данных. Добавьте подпись, которая указывает, что включает и исключает рисунок. Диаграмма не должна предполагать, что внецепочечный процесс обеспечивается смарт-контрактом. Ссылайтесь на более глубокую техническую документацию, когда читателям нужны детали реализации, выходящие за рамки цели документа.

Проведите 2 проверки каждой важной диаграммы: убедитесь, что её подписи соответствуют тексту, затем попросите технического рецензента проверить описанное поведение. Запишите 4 поля для каждой диаграммы: цель, компоненты, границы и рецензент. Помечайте компоненты как протестированные, прошедшие аудит или предложенные только тогда, когда это подтверждается доказательствами проекта. Эти описания не взаимозаменяемы. Если дизайн меняется, укажите, какие детали являются предварительными, вместо того чтобы записывать их как установленные факты.

Какие редакторские проверки выявляют пробелы в крипто вайтпейпере?

Противоречие между описанием токена и дорожной картой — это дефект содержания, а не стиля. Проверяйте статус, определения и доказательства до того, как тратить время на шлифовку предложений. Эти проверки облегчают оценку черновика:

• Обещания без механизма: описывайте систему и её зависимости вместо того, чтобы утверждать результат.
• Планы, написанные как реализация: помечайте будущую работу и отличайте её от доступной функциональности.
• Неопределённая функция токена: объясните, что токен делает в системе.
• Неопределённые цифры или термины: укажите, на что ссылается каждое значение или метка.
• Техническая лексика без контекста: определите термин и объясните, почему он важен.
• Конфликтующие названия или правила: сравните описания эмиссии, роли управления и метки статуса по разделам.
• Общие отрывки: удалите язык, который не описывает дизайн или обязанности этого проекта.

Для каждого раздела спросите, что внимательный читатель сможет проверить по его содержанию. Добавьте источник, уточните допущение или пересмотрите утверждение, когда ответ неясен. Затем проведите отдельную редакторскую проверку последовательности и читаемости. Разделение проверки фактов и корректуры снижает риск того, что более гладкая формулировка скроет нерешённое утверждение.

Как рецензенты должны фиксировать изменения перед выпуском?

Журнал изменений даёт команде запись того, что изменилось и почему. Назначайте рецензирование по темам: инженеры проверяют описания системы, ответственные за токен — механику, а редакционные рецензенты — структуру и согласованность. Юристы должны проверять язык, требующий правовой оценки.

Используйте эту последовательность:

• Заморозьте план и соберите текущие исходные материалы.
• Напишите объяснения и сопоставьте материальные утверждения с доказательствами.
• Направьте каждое утверждение лицу, ответственному за его проверку.
• Разрешите комментарии и запишите причину существенных изменений.
• Проверьте ссылки, диаграммы, термины и метки версий на соответствие финальному тексту.

Размеченный документ с вопросами, сгруппированными по ответственному, даёт следующей редакции чёткий путь. Это помогает основателям решать вопросы объёма и статуса, в то время как технические рецензенты сосредотачиваются на описаниях системы. Ведите журнал изменений до публикации, чтобы рецензенты могли видеть, какие утверждения переместились и почему.

Для коммуникации проекта за пределами вайтпейпера сравните документ с руководством по криптомаркетингу и текущими техническими материалами проекта. Не используйте ни то, ни другое как замену проверки исходных фактов. В GeoMarketing Experts рецензия черновика сопоставляет материальные утверждения с их доказательствами и возвращает вопросы по ответственному. Отправьте текущий план, документацию по продукту, материалы по токену, если применимо, и любые утверждения, требующие проверки, для обсуждения поддержки написания вайтпейпера.

Что опубликованный вайтпейпер оставляет недоказанным?

Метка версии и назначенный ответственный помогают читателям определить, какой документ они читают. Обеспечьте путь от документа к текущей документации проекта. Пересматривайте документ при изменении существенной функции, правила токена, процесса управления или статуса проекта. Если он больше не отражает проект, обновите его или пометьте как устаревший.

Формальный документ не может установить, что реализация ведёт себя как описано, или подтвердить безопасность. Условия токена и управления также остаются подчинёнными задокументированным правилам проекта. Укажите допущения и нерешённые зависимости в документе, затем обратитесь за квалифицированной технической и юридической проверкой по вопросам, которые эти материалы не могут решить.

Перед публикацией проверьте, что финальный текст согласуется с продуктом и учредительными документами. Подтвердите, что диаграммы, терминология, метки версий и ссылки соответствуют проверенному черновику. Назначьте названного члена команды ответственным за будущие обновления, а не предполагайте, что документ останется актуальным сам по себе.

Чтобы начать черновик, соберите план, текущую документацию по продукту, материалы по токену, если применимо, и список утверждений, требующих проверки. Отправьте эти элементы в GeoMarketing Experts. Следующий шаг — проверка утверждений на соответствие источникам, за которой следует список пробелов для лиц, ответственных за разрешение каждого вопроса.

Как мы работаем

1. Определите читателя и цельНазовите основную аудиторию и то, что документ должен помочь ей оценить. Отделите эту задачу от маркетинга, юридических условий и подробной технической документации.
2. Соберите и промаркируйте текущие фактыСоберите материалы по продукту, архитектуре, токену и дорожной карте. Пометьте каждый элемент как: работает, протестировано, запланировано или не решено.
3. Составьте карту разделов и утвержденийВыстройте план вокруг потребностей читателя. Запишите источник и рецензента для каждого значимого утверждения.
4. Напишите объяснениеОбъясните систему простым языком, прежде чем добавлять детали реализации. Подпишите диаграммы и укажите их ограничения.
5. Проверьте и поддерживайте документНаправьте утверждения соответствующим рецензентам, устраните противоречия и назначьте ответственного за будущие обновления.