За пределами PDF: создание руководств, которые действительно работают

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

Вот почему важны примеры инструкций. Не как источник вдохновения по оформлению, а как рабочие модели. Хорошее руководство дает пользователю задачу, которую нужно выполнить, понятный маршрут и достаточно контекста, чтобы восстановиться, когда реальность не совпадает с «счастливым сценарием». Оно также дает бизнесу измеримый результат. HelpJuice рекомендует относиться к руководствам как к активам поддержки: задайте метрики успеха, например объем обращений в поддержку, ставки возвратов и удовлетворенность пользователей, а затем улучшайте документ со временем на основе этих сигналов и валидации реальными пользователями через наблюдаемое выполнение задач, используя только руководство (рекомендации HelpJuice по инструкциям).

Современные команды также не могут позволить себе писать каждое руководство с нуля. Лучший подход — привязать руководство к его роли в корпоративной функции, а затем стандартизировать процесс создания, проверки, тестирования и обновления. Этот сдвиг особенно важен в регулируемых и быстро меняющихся средах, где руководства должны быть ориентированы на пользователя, структурированы максимально ясно, проверены на ошибки и опубликованы вместе с продуктом, а не «задним числом» (рекомендации QIMA по инструкциям к продуктам).

Ниже — восемь примеров инструкций, которые закрывают основную работу, нужную большинству корпоративных команд.

Оглавление

• 1. Руководство по настройке и установке ПО

  • Что в этом примере сделано правильно

  • Как адаптировать под AI-процессы

• 2. Руководство пользователя по конкретной функции и how-to

  • Почему task-based руководства лучше широких мануалов

  • Как генерировать их быстрее

• 3. Стандартные операционные процедуры и документация процессов

  • Что включают сильные примеры SOP

  • Где команды чаще всего ошибаются с SOP

• 4. Руководство по устранению неполадок и технической поддержке

  • Начинайте с симптомов, а не с систем

  • Как сделать контент по устранению неполадок масштабируемым

• 5. Шаблон сценария продуктовой демо-презентации и enablement для продаж

  • Что отличает пригодный сценарий демо от плохого

  • Как AI помогает, не «сглаживая» подачу

• 6. Руководство администратора и IT-операций

  • Структура, которая работает в реальных админ-средах

  • Как сохранить его поддерживаемым

• 7. Шаблон модуля курса обучения и развития

  • Почему обучающие руководства должны быть больше, чем объяснения

  • Как собирать модули эффективно

• 8. Руководство по управлению изменениями и коммуникации обновлений продукта

  • Что включают эффективные руководства по обновлениям

  • Как создавать руководства по обновлениям на основе записей продукта

• Примеры инструкций: сравнение по 8 пунктам

• Автоматизируйте свои руководства — ускорьте бизнес

1. Руководство по настройке и установке ПО

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

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

Что в этом примере сделано правильно

Хорошие инструкции по настройке разбивают путь на точки принятия решений. Тем, кто читает quick-start, нужен самый короткий безопасный маршрут. Администраторам, которые настраивают SSO, права или правила сети, нужен полный путь внедрения. Смешивание обеих аудиторий в одном непрерывном потоке обычно приводит к сбоям.

Надежная инструкция по настройке включает:

• Сначала предпосылки: системные требования, права доступа, зависимости и допущения по среде должны появиться до первого шага.

• Видимые точки подтверждения: после каждого важного действия показывайте ожидаемый экран, сообщение о статусе или результат конфигурации.

• Инструкции по восстановлению: неудачные установки случаются. Шаги отката и руководство «начните заново безопасно» должны быть в руководстве, а не в ответе поддержки.

• Точечные визуальные материалы: скриншоты лучше всего работают, когда они указывают на одно поле, переключатель или кнопку за раз.

Практическое правило: каждый шаг установки должен отвечать на два вопроса. Что я делаю сейчас и как я понимаю, что это сработало?

Как адаптировать под AI-процессы

Это один из самых простых типов мануалов для генерации из записей продукта, потому что сам процесс обычно детерминирован. Запишите установку один раз в чистой среде, зафиксируйте каждое состояние экрана, а затем преобразуйте запись в черновик руководства с таймкодами и скриншотами. Для команд, которые создают повторяемые инструкции по настройке на основе walkthrough’ов, этот подход особенно полезен в связке с workflow по авто-генерации PDF-руководства пользователя из записанного product walkthrough.

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

2. Руководство пользователя по конкретной функции и how-to

Широкие руководства по продукту выглядят полными, но пользователи редко читают их от начала до конца. Обычно они ищут одну конкретную задачу. Поэтому feature-specific guides чаще лучше работают в библиотеках поддержки и центрах обучения клиентов.

Примеры — туториалы по базам данных в Notion, дизайн-walkthrough’ы в Canva и how-to по дизайн-системе в Figma. Каждый из них ориентирует пользователя на результат, а не на перечень функций. Это лучше соответствует тому, как люди учатся работать с ПО под давлением времени.

Почему task-based руководства лучше широких мануалов

Сильный how-to начинается с финишной точки. «Создайте базу данных», «спроектируйте пост в соцсети» или «поделитесь дизайн-системой» понятнее, чем «узнайте о базах данных», потому что читатель еще до старта понимает, как выглядит успех.

Лучшие примеры в этой категории обычно включают несколько ключевых приемов:

• Открытие, ориентированное на результат: сформулируйте, что пользователь завершит.

• Короткие процедурные дуги: разбейте поток на компактные шаги, чтобы пользователь не потерял место.

• Поддержка решений: ветвите сценарий, когда workflow меняется в зависимости от типа плана, роли или use case.

• Контекстные быстрые действия: добавляйте горячие клавиши, подсказки и типичные ошибки там, где они действительно важны.

Пользователям не нужен тур. Им нужен прогресс.

Как генерировать их быстрее

Feature guides идеально подходят для производства с AI-помощью, потому что продуктовые команды уже записывают walkthrough’ы для релизов, звонков по успеху клиентов и внутреннего обучения. Одна качественная запись может превратиться в несколько результатов: короткий how-to, статью для поддержки и обучающее видео. Команды, которые создают продуктовые материалы в масштабе, часто начинают с видеоруководств для SaaS-продуктов, которые реально используют клиенты, а затем извлекают письменные инструкции из того же источника.

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

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

3. Стандартные операционные процедуры и документация процессов

SOP-руководства не выглядят гламурно, но несут большую операционную нагрузку. Когда отдел продаж проводит корпоративное onboarding, когда поддержка эскалирует инциденты или когда маркетинг продвигает контент через проверку, SOP определяет, что именно означает «сделано правильно».

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

Что включают сильные примеры SOP

Хорошие SOP читаются как управляемые системы. Они определяют триггер, владельца, последовательность, путь исключения и выходной результат. В workflow с участием нескольких команд диаграммы swimlane помогают, но письменные шаги все равно важны, потому что людям нужны точные действия, а не просто карта.

Что стабильно работает:

• Явная ответственность: назовите, кто действует на каждом шаге.

• Понятные передачи: покажите, когда работа переходит от продаж к юристам, от поддержки к разработке или от ops к финансам.

• Рекомендации по исключениям: укажите, когда можно отклоняться, кто это утверждает и как документировать изменение.

• Контроль версий: датируйте каждый документ, отслеживайте правки и явно выводите из обращения устаревшие копии.

Где команды чаще всего ошибаются с SOP

Типичная ошибка — писать политику, замаскированную под процедуру. «Проверьте аккаунт на качество» — это не инструкция. Это ожидание. SOP должен уточнить, что именно проверять, где смотреть и как выглядит приемлемое завершение.

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

Если ваша команда записывает live workflow, эта запись может стать основой первого черновика SOP и сохранить реальные состояния экрана и точки принятия решений. Это особенно практично для руководителей операций, которые создают видеo SOP для команд производства и операций. Просто убедитесь, что кто-то отредактирует черновик до нужного стандарта. Запись экрана фиксирует поведение. Она не решает, правильное ли это поведение.

4. Руководство по устранению неполадок и технической поддержке

Руководства по устранению неполадок терпят неудачу, когда их пишут с точки зрения инженера. Пользователи не приходят с первопричинами. Они приходят с симптомами. «Приложение не синхронизируется», «не удалось экспортировать» или «значок подключения красный» — это правильная отправная точка.

Вот почему лучшие руководства поддержки больше похожи на деревья решений, чем на эссе. Apple Support, документация AWS, справочные материалы Windows и гайды по подключению в Slack работают лучше, когда они переходят от наблюдаемой проблемы к диагностическому действию и затем к наиболее вероятному решению.

Начинайте с симптомов, а не с систем

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

Эта структура хорошо работает:

• Заголовок симптома: «Не удается подключиться к рабочей области» лучше, чем «Проблемы с настройкой сети».

• Шаг проверки: попросите пользователя подтвердить по одному видимому условию за раз.

• Ожидаемое состояние успеха: скажите им точно, что изменится, когда исправление сработает.

• Путь эскалации: если путь не сработал, направьте их в следующую команду с информацией, которую они должны предоставить.

Руководство по устранению неполадок должно снижать панику до того, как проблема будет решена.

Как сделать контент по устранению неполадок масштабируемым

В этом разделе важнее, чем в большинстве других руководств, ветвление по версиям. Одна и та же проблема может иметь разные причины на десктопе, в мобильной среде, в облаке или при self-hosted. Создавайте блоки контента, которые можно заменять или переиспользовать в зависимости от релиза, модели развертывания или операционной системы.

Одна из недооцененных областей в публичных рекомендациях — измерение. Многие примеры инструкций фокусируются на читаемости и оформлении, но корпоративным командам обычно нужно понимать, снижает ли документ количество ошибок, нагрузку на поддержку, время обучения или переделки. Общие рекомендации по документации также указывают на оценку, которая поддерживает последовательные решения, ревизии и воспроизводимые результаты — то есть качество руководства следует оценивать по эффективности процесса, а не только по внешнему виду (California design documentation guidance).

На практике лучшие руководства по устранению неполадок обновляются на основе данных тикетов. Если поддержка продолжает отвечать на один и тот же вопрос «все еще не получается», значит, руководство еще не завершено.

5. Шаблон сценария продуктовой демо-презентации и enablement для продаж

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

Плохая версия звучит как заученный текст. Хорошая версия дает структуру, но не «уплощает» подачу. Корпоративные демо Salesforce, материалы enablement от HubSpot, enterprise walkthrough’ы в Figma и демо платформы Stripe работают лучше всего, когда сценарий защищает общий поток, но оставляет место для живого исследования.

Что отличает пригодный сценарий демо от плохого

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

Практичный сценарий демо обычно включает:

• Открытие с учетом сегмента: разные формулировки для команд operations, IT, finance или product.

• Пути по времени: короткая версия для ранних звонков и более глубокая — для сессий оценки.

• Подсказки для аудитории: вопросы, которые приглашают потенциального клиента подтвердить приоритеты прямо в моменте.

• Опциональные блоки расширения: дополнительные секции, которые презентатор может развернуть, если покупатель вовлекается.

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

Как AI помогает, не «сглаживая» подачу

AI может подготовить базовый сценарий по записанному демо, определить переходы между экранами и превратить live walkthrough в повторяемые тезисы для разговора. Это экономит время, особенно когда у одной платформы есть несколько вариантов под разные персоны. Команды, которые создают такие материалы, часто выигрывают от переиспользуемых шаблонов видео демо для продаж B2B SaaS, потому что демо и письменный сценарий должны иметь одну и ту же «нарративную ось».

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

6. Руководство администратора и IT-операций

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

Документация по настройке Okta, материалы по развертыванию Microsoft Entra ID, руководства по настройке админки Zendesk и гайды по инфраструктуре Datadog показывают, что работает лучше. Разбивайте руководство по админским задачам, а не только по областям продукта. Управление пользователями, настройки идентичности, аудит, управление интеграциями и процедуры отката должны существовать как отдельные блоки.

Структура, которая работает в реальных админ-средах

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

Хорошо работающие администраторские руководства обычно включают:

• Точки входа под задачу: одно руководство для настройки SSO, другое — для управления жизненным циклом пользователей, третье — для просмотра логов.

• Состояния «до и после»: покажите текущую конфигурацию и ожидаемую конфигурацию после изменения.

• Заметки по безопасности прямо в тексте: не прячьте последствия для прав в приложениях.

• Устранение неполадок под конкретные интеграции: универсальные советы редко помогают в корпоративных средах.

Как сохранить его поддерживаемым

Эта категория выигрывает от дисциплины проектирования под аудиторию. ClickHelp отмечает, что руководства должны учитывать знакомство аудитории, контекст, контент, дизайн и структуру, и подчеркивает базовый, но часто игнорируемый момент: оглавление необходимо для навигации. TechSmith также согласуется с более общим паттерном — лаконичные, последовательные, проверенные пользователями инструкции, о которых говорилось ранее. Эти практики особенно важны для IT-операций, потому что админы часто врываются в узкую секцию под давлением, а не читают документ линейно.

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

7. Шаблон модуля курса обучения и развития

Обучающие руководства разваливаются, когда они только объясняют. Люди чувствуют себя информированными, но не могут выполнять. Этот разрыв особенно заметен в onboarding, сертификациях и внутренних программах enablement, где обучаемому нужно применять материал позже, без надзора.

Salesforce Trailhead, HubSpot Academy, Google Cloud Skills Boost и похожие системы работают, потому что упаковывают обучение в модули с четкой целью, направляемыми шагами и какой-то формой практической задачи. Это отличается от справочного руководства. Модуль курса должен менять поведение, а не просто отвечать на вопросы.

Почему обучающие руководства должны быть больше, чем объяснения

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

Что обычно хорошо работает:

• Маршруты обучения по ролям: менеджеры по продажам, агенты поддержки и администраторы не должны проходить один и тот же путь через материал.

• Упражнения на основе сценариев: поместите обучаемого в реалистичный контекст принятия решений.

• Слои справки: держите подсказки по работе, глоссарии и ссылки на поддержку доступными, не прерывая поток модуля.

• Моменты оценки: попросите обучаемого сделать что-то, а не просто читать дальше.

Как собирать модули эффективно

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

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

8. Руководство по управлению изменениями и коммуникации обновлений продукта

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

Гайды по редизайну рабочих пространств Slack, объяснения обновлений функций в Notion, материалы по внедрению Microsoft Teams и документация по миграции в Jira работают лучше, когда они описывают изменения через влияние на пользователя. Руководство должно снижать неопределенность, а не просто объявлять о новизне.

Что включают эффективные руководства по обновлениям

Сильное руководство по обновлениям начинается с выгоды, а затем быстро переходит к поведению «до и после». Что переместилось, что осталось прежним, кому нужно действовать и что произойдет, если ничего не делать. Разным стейкхолдерам нужны разные версии. Конечные пользователи заботятся об изменениях в workflow. Администраторы — о настройках, порядке развертывания и рисках. Руководители — об адаптации и возможных сбоях.

Полезные элементы включают:

• Сообщения с фокусом на выгоду: объясните, почему изменение важно, прежде чем перечислять изменения интерфейса.

• Визуальные материалы «до и после»: по возможности показывайте старый путь и новый путь рядом.

• Подсказки по стабильности: расскажите пользователям, что не меняется, чтобы они не предполагали полный сброс.

• Шаги отката или минимизации последствий: критические изменения должны иметь «страховку».

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

Как создавать руководства по обновлениям на основе записей продукта

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

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

Примеры инструкций: сравнение по 8 пунктам

Автоматизируйте свои руководства — ускорьте бизнес

Лучшие примеры инструкций не просто выглядят аккуратно. Они решают реальную операционную проблему. Инструкция по настройке снижает трение в onboarding. Учебник по функции помогает пользователям быстрее добраться до ценности. SOP создает единообразие между командами. Руководство по устранению неполадок снижает зависимость от поддержки. Администраторское руководство защищает рискованные изменения в системе. Обучающий модуль превращает документацию в развитие навыков. Руководство по изменениям помогает людям внедрять новые workflow без путаницы.

Это и есть более крупный сдвиг в работе с документацией. Руководства больше не статичные deliverables. Это живые активы поддержки, которым нужны структура, тестирование, ревизии и измеримые результаты. Команды, которые по-прежнему воспринимают руководства как разовые PDF, обычно платят за это позже — через повторяющиеся запросы в поддержку, неравномерное выполнение и медленный onboarding.

Хорошая новость в том, что эти типы руководств не живут в отдельных мирах. Это вариации одних и тех же строительных блоков: аудитория, последовательность задач, ожидаемый результат, обработка исключений, визуальные материалы и процесс обновления. Как только вы стандартизируете эти элементы, вы сможете генерировать документацию быстрее и поддерживать ее согласованность между функциями. Запись продукта может питать инструкцию по настройке, статью поддержки, сценарий демо, SOP и обучающий модуль — если ваш workflow построен вокруг переиспользования.

И именно здесь AI становится практичным, а не декоративным. Он полезен, когда убирает повторяющуюся производственную работу. Захват скриншотов, черновая подготовка шагов, организация заголовков, сегментация workflow и превращение одного walkthrough в несколько форматов руководств — все это задачи, которые выигрывают от автоматизации. Человеческая проверка все еще важна. Кто-то должен подтвердить терминологию, пограничные случаи, формулировки по соответствию и то, что руководство отражает задуманный процесс, а не то, что произошло в одной сессии записи.

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

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

Смысл не в том, чтобы создавать больше документации. Смысл — в том, чтобы создавать руководства, которыми можно пользоваться, которые можно обновлять и которым можно доверять.

Если ваша команда застряла в поддержке разрозненных PDF, устаревших SOP и разовых walkthrough’ов, Trupeer Inc. стоит рассмотреть. Она создана, чтобы превращать одну запись экрана в видео, руководства, SOP и поисковые активы знаний — это помогает продуктовым, поддерживающим, enablement и операционным командам держать документацию актуальной без того, чтобы каждый раз перестраивать ее с нуля.