Как написать вайтпейпер, который поймёт даже скептик

Что читатель должен понять из документа?

Быстрый тест: дайте черновик человеку вне команды и попросите подчеркнуть каждое утверждение, которое он не может проверить. Вы сразу увидите, какие разделы требуют доказательств.

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

Напишите краткое резюме для команды перед началом работы. Включите:

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

Такое резюме — полезная проверка плана: если предлагаемый раздел не отвечает на вопрос читателя или не обосновывает утверждение проекта, удалите его или объясните, почему он нужен. Вайтпейпер не должен пытаться обслуживать все аудитории одинаково. Когда проекту нужен краткий обзор для первых бесед, лайтпейпер может быть лучшим дополнением; два документа могут иметь разные роли, а не повторять друг друга.

Структура, которую легко читать

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

Рассмотрите такой порядок:

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

Адаптируйте план под проект, а не наоборот. Документация протокола требует больше технических объяснений, чем обзор потребительского приложения. Добавляйте диаграммы только тогда, когда они проясняют взаимосвязь или процесс, и убедитесь, что текст объясняет их для читателей, которые не могут быстро интерпретировать визуал. Для чек-листа, сосредоточенного на информации о токене, см. как проверить эмиссию на CoinGecko; убедитесь, что собственные данные о эмиссии в вайтпейпере соответствуют записям проекта.

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

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

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

Уделите особое внимание этим областям:

• Архитектура: назовите компоненты и опишите, как информация или активы перемещаются между ними.
• Безопасность: укажите, что было проверено, а что нет; избегайте намеков на то, что проверка устраняет все риски.
• Роль токена: объясните функцию в продукте, а не полагайтесь на абстрактные описания.
• Эмиссия и распределение: покажите категории, сроки и любые условия, которые команда фактически утвердила.
• Управление: определите права принятия решений и опишите, как обрабатываются предлагаемые изменения.

Ведите таблицу доказательств в рабочем черновике с утверждением, источником, ответственным и статусом проверки. Таблица — это редакционный инструмент, а не доказательство само по себе. Для публичной версии переводите техническую терминологию там, где это возможно, и определяйте необходимые термины при первом использовании. Читатели должны мочь проследить утверждение, не гадая, что имела в виду команда.

Написание и рецензирование документа

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

Практическая последовательность:

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

Давайте рецензентам конкретные запросы, а не просите общего «взгляда». Например, попросите технического руководителя проверить описания компонентов, а ответственного за дизайн токена — проверить формулировки распределения на соответствие утвержденной модели. Храните один мастер-копию и фиксируйте, какие изменения приняты, отложены или не разрешены. Если вам нужна внешняя поддержка в написании, написание вайтпейперов и лайтпейперов может помочь превратить материалы проекта в готовый к чтению документ; подготовьте пакет исходных материалов и ответственных за решения до начала работы.

Ваш чек-лист по вайтпейперу из 7 пунктов

Проверьте каждый черновик по этим 7 пунктам, прежде чем кто-то вне вашей команды увидит его. Если ваш документ проходит все 7 пунктов, вам будет легче защищать его в вопросах и ответах и легче сократить до других форматов.

• Укажите читателя и цель на странице 1.
• Определите проблему в 3 предложениях или менее.
• Опишите продукт и технологию простыми словами.
• Объясните функцию, эмиссию и распределение токена.
• Добавьте раздел о рисках, который будет честным.
• Привяжите каждое число к источнику или контракту.
• Получите одобрение 2 рецензентов: одного технического и одного юридического.

Термины в одной строке

Вайтпейпер (простыми словами: длинный документ, объясняющий технологию, токен и план проекта).

Лайтпейпер означает краткое резюме вайтпейпера для читателей, которые хотят получить суть.

Ошибки, которые стоят доверия

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

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

Следите за этими проблемами во время рецензии:

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

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

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

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

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

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

Если вайтпейпер поддерживает заявку на биржу или платформу данных, согласуйте его фактические детали с представленными материалами проекта; сам документ не определяет результат проверки платформы. Смотрите отдельные руководства по листингу на CoinMarketCap и листингу на CoinGecko для этих процессов подачи заявок. Лаконичный и последовательный исходный документ облегчает команде объяснение проекта, но каждая платформа принимает собственные решения.

Когда лайтпейпер — лучший выбор?

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

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

Используйте эту проверку перед выбором формата:

• Нужна ли предполагаемому читателю детализация реализации, чтобы понять предложение?
• Подкреплены ли центральные утверждения проекта исходными материалами и проверкой ответственных?
• Готова ли команда поддерживать тот уровень детализации, который планирует опубликовать?
• Будет ли краткий обзор более полезен сейчас, а более глубокий документ последует позже?

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

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

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