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

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

1858
Время чтения: 16 минут
Содержание
Попробуйте OkoCRM бесплатно
CRM-система, управление проектами и задачами, общение с клиентами и каналы продаж — всё внутри OkoCRM. 7 дней бесплатно.
На страницу OkoCRM

Знаете, как работает закон подлости (он же закон Мерфи и закон бутерброда)? Если вас можно понять неправильно — вас обязательно поймут неправильно. Это работает и при разработке сайтов. Заказчик просил второй Инстаграм, а получил Одноклассники. Исполнитель не угадал с хотелками клиента — потратил время зря, оба недовольны.

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

Что такое техзадание и зачем оно нужно

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

Зачем мне это. Фиксация условий и требований к сайту в ТЗ подтвердит: стороны правильно поняли друг друга. Заказчик знает, что хочет — исполнитель знает, что делать. А еще по ТЗ будут принимать готовый сайт. Претензии, не основанные на требованиях техзадания, не принимаются.

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

Пользы от составления ТЗ много. И для заказчика, и для исполнителя.

Что ТЗ даёт заказчику

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

2. Оценку навыков разработчика. Если в ТЗ все ясно, понятно и четко — это баллы в копилку исполнителя. Обычно заказчик сильно хуже разбирается в технической части проекта, ему важен результат. ТЗ помогает доступно объяснить, над чем работаем. Если же в ТЗ каша и ничего не понятно, возможно, вам нужен новый разработчик.

3. Страховку. Когда сайт готов, его проверяют на соответствие условиям ТЗ. Что-то не так? Исполнитель обязан все поправить. Или дорабатывай, или возвращай предоплату. Не забывайте вносить такие условия в договор с разработчиком и он точно не отвертится.

4. Возможность поменять исполнителя. Бывает, что заказчик и исполнитель не сработались и разбежались. Проект застынет, сроки реализации сорвутся. Если есть грамотное ТЗ, новой команде будет сильно проще вникать в суть дела — проект запустят в разы быстрее.

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

Техническое задание гарантирует, что заказчик получит то, что хотел. Если исполнитель не готов следовать ТЗ, с ним всегда можно попрощаться и забрать предоплату

Что ТЗ даёт исполнителю

1. Понимание, чего хотят. В ТЗ пакуют все пожелания клиента. Ему задают 100 вопросов (или больше), показывают 30 разных вариантов, советуют возможные решения. Потом записывают и согласовывают. Если заказчику нравится — отлично, исполнитель понял, чего от него хотят. Можно браться за работу.

2. Страховку. Заказчики с внезапными хотелками — боль исполнителя. «А у конкурентов не так — давайте делать как у них» или еще хуже «Фу, что за дизайн такой страшный. Давайте переделывать. И бабочек добавьте...». Согласованное ТЗ помогает избегать таких вещей. «Хотите переделать? Давайте вносить правки в ТЗ — за отдельную плату». Если что, справедливость и правда всегда на вашей стороне.

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

4. Дополнительный доход. Подготовка ТЗ — сложный и длительный этап работы над сайтом. Никто не хочет тратить время и силы бесплатно. А вдруг клиент сбежит с ТЗ? Поэтому обычно разработчики берут за его составление деньги — или включают в общий прайс, или считают как отдельную услугу.

5. Упрощение задачи. В ТЗ собирают структуру сайта, фиксируют функционал, элементы интерфейса, управления и дизайна. Все наглядно и понятно. Разработчику останется только задизайнить, все сверстать и собрать движок.

ТЗ страхует исполнителя от внезапных хотелок заказчика. Если они возникают, всегда можно сослаться на ТЗ и доказать свою правоту

Кто составляет ТЗ для сайта

Мы встречаем две позиции и, обычно, обе они зависят от точки смотрения:

Первая — заказчик. ТЗ на разработку сайта — зона ответственности клиента. Мол, ты о своем проекте на начальном этапе знаешь гораздо больше, чем агентство или разработчик-фрилансер. Давай тогда и ТЗ составляй. Напиши все свои хотелки, а мы посмотрим и подумаем, как их можно воплотить. Потом посмотришь — сделаем красиво.

Вторая — исполнитель. Мол, разработчик куда лучше разбирается в создании сайтов, чем предприниматель или управляющий партнер адвокатского бюро. Поэтому пусть он и описывает проект. А мы потом посмотрим, посоветуемся с сыном маминой подруги (он учился на курсах верстки сайтов) и все согласуем.

Третья — правильная. В разработке ТЗ на сайт должны участвовать обе стороны. Понятно, что менеджер или разработчик лучше разбираются в создании сайтов. Идеально, если сайт будут проектировать при участии маркетологов (SEO-специалиста + интернет-маркетолога). Поэтому формально составлять ТЗ будет сторона исполнителя. Справедливо, что за это она попросит вознаграждение, соразмерное проведенным работам и потраченному времени. Но без активного участия заказчика — все в пустую.

Заказчик не может самоустраниться. У него одна из главных ролей в процессе создания сайта. Клиенту точно придется:

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

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

Попробуйте OkoCRM бесплатно
Мощная система для автоматизации продаж, ведения базы и общения с клиентами. В одном окне все каналы продаж, мессенджеры, чаты, клиентская база и сделки.
Что умеет OkoCRM

Основные разделы ТЗ для сайта

Заказчику, который никогда не сталкивался с разработкой, сложно представить структуру ТЗ. Обычно она состоит из 10–12 разделов и еще стольких же подразделов с уточнения. Это большой и емкий документ на 15–30 страниц в зависимости от сложности сайта. Настоящий реферат. В нем точно должны быть:

  1. Информация о проекте
  2. Технические особенности проекта
  3. Структура сайта в виде блок-схемы или иной визуализации
  4. Детальное описание сущностей
  5. Функциональные особенности
  6. Дизайн
  7. Описание контента и определение ответственного за него
  8. Сценарии использования сайта

Пожалуйста, заполняйте ТЗ однозначно и точно

В грамотном ТЗ не может неоднозначных прилагательных, вроде «красивый», «надежный», «модный», «полезный». Их нельзя корректно понять и воспроизвести. У каждого свои представления о пользе и красоте.

Исключайте невнятные формулировки:

  • Сайт должен быть удобным. Для кого и чего?
  • Должен выдерживать нагрузки. Это какие?
  • Нужен убедительный контент. Это какой? И кого он должен убедить?

Используйте только цифры и однозначные метрики:

  • Сайт должен выдерживать наплыв пользователей → Ожидаемая посещаемость — 25 тысяч одновременно
  • Быстрая загрузка → скорость ответа сервера в Яндекс.Вебмастер по каждой странице — не более 20 миллисекунд
  • Убедительный контент → информационные статьи с алгоритмами, инструкциями и схемами

Объясняйте сложные формулировки:

  • CMS — это система управления сайтом. Через нее можно управлять контентом
  • Контент — это тексты, иллюстрации, видео, анимации и любое другое наполнение сайта
  • Подвал — это блок внизу каждой страницы. В нем отображаются основные разделы и важные ссылки

Информация о проекте

Начало любого ТЗ — описание проекта. Исполнитель должен понимать, с какой компанией работает, какие она цели преследует и какие продукты продает. Поэтому в техническом задании точно должны быть:

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

Обычно эти особенности узнают в процессе интервью. Проект-менеджер приглашает заказчика в офис, проводит опрос и все фиксирует. Не стоит отдавать этот раздел заказчику: - «Это заполняете вы, а остальную часть ТЗ мы берем на себя». Есть риск упустить важные детали и тонкости.

Технические особенности проекта

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

Адаптивность. Понятно, что любой современный сайт должен корректно отображаться на мобильных устройствах. Вопрос в том, как он должен отображаться. Это нужно уточнять. Например:

Адаптивность (доступные размеры:

настольный монитор — 1600 х 992 px;

ноутбук — 1280 х 802 px;

планшет — 768 х 1024 px;

смартфон — 1920 х 1080 px)

Кроссбраузерность. Уточняйте, в каких минимальных версиях браузера должен отображаться сайт. Это важно, потому что браузерные требования (особенно для старых браузеров вроде Internet Explorer 7) сильно урезают возможности разработки. Не забывайте уточнять. Например:

Кроссбраузерность: Internet Explorer 9+, Opera 10+, Safari 4+, Chrome 1+

Управление сайтом. Представьте, что вы 3 месяца собирали сайт, все согласовали — клиент доволен. Показываете заказчику админку а он: «Вордпресс? Я думал вы сделаете сайт на Joomla!». Чтобы такого не произошло, все инструменты, библиотеки и движки уточняют в техзадании на разработку сайта. Заодно уточняйте и хостинг. Вдруг, вы пишите сайт на PHP, а заказчик купил хостинг на .NET?

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

Структура сайта

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

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

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

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

  1. Шапка. Верхний прикрученный блок. Обычно на нем располагаются контакты, лого, навигация по сайту, строка поиска, кнопки регистрации и авторизации, иные элементы в зависимости от направленности сайта
  2. Подвал. Нижний блок, закрывающий каждую страницу. Обычно в нем повторяется часть шапки, размещаются важные кнопки, разделы и и ссылки
  3. Сайдбары. Это боковые вертикальные панели, на которых собраны наборы функциональных блоков и виджетов. Например, боковая панель Вконтакте, где собраны кнопки «Новости», «Друзья», «Сообщества», «Музыка», «Игры» и другие прикрученные элементы
  4. Формы и окна. Интерактивные элементы, которые появляются при взаимодействии или произвольно. Например, всплывающее окно чата с оператором

Уникальные страницы. Обычно сложность и сроки разработки упираются в количество уникальных страниц и разделов, которые нужны сайту. Поэтому каждую такую страницу или сайт нужно зафиксировать в ТЗ и подробно описать.

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

Каждую такую уникальную страницу в ТЗ подробно описывают. Это можно сделать словами — перечислить элементы, или в виде прототипа. Мы считаем, что лучше рисовать прототипы — так нагляднее. Но многим удобнее и проще текстом.

  1. Перечисление элементов. Вариант для лентяев. Просто перечисляем основные блоки на странице и описываем их функции. По такому описанию можно только представить, как будет выглядеть сайт. Например:

    БЛОГ (основной раздел)

    • заголовок первого уровня
    • список постов блога в виде ФОТО + заголовок + анонс на один абзац
    • кнопки для постраничной навигации. 1 страница вмещает не более 10 постов
    БЛОГ (боковая колонка)
    • список категорий блога (маркетинг, интернет-маркетинг, аналитика, разработка, инструменты, кейсы)
    • форма подписки на рассылку
    • кнопки для перехода в наши соцсети: Вконтакте, Инстаграм и Фэйсбук
  2. Прототип. Продвинутая штука, которую используют профессионалы. Однозначно и наглядно демонстрирует, как будет выглядеть будущая страница. Это эскизы интерфейса страниц, которые разработчик рисует и прикладывает к заданию. Клиент посмотрит, как будет выглядеть его сайт и скажет, что ему нравится, а что нужно переделать
    Прототип сайта для официального дилера грузовиков в Краснодаре. Заказчик может заранее увидеть интерфейс своего будущего сайта, оценить его визуальное восприятие, предложить исправления и дать свои рекомендации

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

  • Типовая текстовая страница. Обычно это шаблон для страниц, которые не подпадают под описание уникальных. В таких страницах предусматривают весь необходимый функционал для размещения текста: заголовки первого-шестого порядка (Н1-Н6), списки, таблицы, иллюстрации, инструменты выравнивания, шрифты и т.д.
  • Страница результатов поиска. Люди часто ищут что-то на сайтах через поиск. От того, насколько будет удобной страница поисковой выдачи, зависит конверсия. Поэтому обычно такие страницы не рекомендуют перегружать
  • Вход и регистрация. Если предполагается, что люди будут логинится на вашем сайте, позаботьтесь о простоте заполнения форм — опишите, а лучше покажите в ТЗ, как должна выглядеть хорошая и простая форма. Если она будет сложной, люди не захотят регистрироваться
  • Страницы 404. Это те страницы, на которые сайт приводит пользователей, если что-то пошло не так. Кажется, что это простая техническая страницы. Но нет — пользователям часто придется сталкиваться с ошибками и видеть эти самые 404. Чем креативнее и заботливее они будут оформлены, тем больше лояльности заработает сайт

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

Детальное описание сущностей

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

Чтобы было понятно: все рыбы имеют плавники. У каждой рыбы плавники имеют разную форму, но все они выполняют одну функцию — помогают рыбе передвигаться. Плавник — это сущность. С элементами-сущностями на сайте примерно так же.

Пример.

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

  • автомобиль — марка и модель, описание характеристик, фотография, класс, стоимость аренды, условия получения; и т.д.
  • город — название населенного пункта, количество автомобилей, минимальная и максимальная стоимость, фото и т.д.

Эти сущности будут постоянно повторяться на сайте и иметь разное описание, но в пределах определенного набора параметров. Набор параметров сущности нужно прописать в ТЗ.

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

Функциональные особенности

Иногда определенные особенности функционала не удается отнести к той или иной категории. В таких случаях лучше создать под них специальный раздел и детально всё описать. Всё, что выходит за рамки стандартного функционала. Например:

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

Дизайн

Его тоже обычно фиксируют в ТЗ. По крайней мере, стараются зафиксировать. Проблема в том, что дизайн (визуал, НЕ интерфейс) — это про вкус и эстетику. А значит все субъективно, прописать объективные критерии оценки почти невозможно. Если о чем то все-таки удалось договориться — фиксируйте это в ТЗ. Хорошо, если у заказчика есть брендбук — будет проще согласовать:

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

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

Сценарии использования

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

Составить сценарии использования не проблема. Используйте простую схему:

Действие пользователя → Ответ системы … → Результат

Простой пример:

СЦЕНАРИЙ ОФОРМЛЕНИЯ ЗАКАЗА НА САЙТЕ:

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

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

Определение ответственного за контент

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

  1. Студия-разработчик — под ключ. Обычно, когда заказывают сайт под ключ, предполагается его наполнение всем необходимым контентом — текстами, иллюстрациями, видео. Это уже входит в стоимость, сайт на приемку отдают в готовом виде
  2. Студия-разработчик — за отдельную плату. Справедливо, если разработчик отказывается наполнять сайт в рамках услуги по созданию сайта. Это отдельный вид работ, которым занимается отдельная команда (редактор, корректор, копирайтер, графдизайнер, иллюстратор и т.д.). Качественное наполнение — это долго и дорого, поэтому создание контента вписывают в договор как отдельную услугу
  3. Заказчик или нанятые им подрядчики. Разработчик может подготовить «рыбу» — «скелет» контента, на основе которого заказчик или нанятые им подрядчики будут создавать контент. Часто это выгоднее, чем заказывать у студии-разработчики. Кроме гонорара копирайтеров и дизайнеров, в прайс включается еще и накрутка студии

Если за частично или полностью отвечает исполнитель, это должно быть прописано в ТЗ.

Пример

КОНТЕНТ

Исполнитель должен создать и разместить уникальные (ранее не используемые в интернете) текстово-графические материалы, включая заголовки Title и мета-теги Description для:

  • Главной страницы
  • Раздела «О компании»
  • Всех страниц раздела «Услуги»
  • Страницы «Политика конфиденциальности»

Проверка уникальности текстового контента осуществляется с помощью сервисов Текст.РФ и Адвего. Уникальным считается контент, уникальность которого выше 90%. Остальные страницы заказчик наполняет контентом собственными силами.

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

Пример ТЗ

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

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

Коротко: как составить ТЗ на разработку сайта

  1. Скачайте шаблон. В нем подробно опишите основную информацию о проекте: вид деятельности, особенности бизнеса, ЦА и ее потребности, цели и задачи, потребности, которые должен закрывать сайт
  2. Опишите технические особенности проекта: адаптивность, кроссбраузерность, особенности управления сайтом, потенциальную нагрузку, скорость загрузки страниц и т.д.
  3. Опишите структуру сайта: необходимые сквозные элементы, уникальные и иные технические страницы. Попробуйте визуализировать структуру в виде блок-схемы, а элементы страниц в виде прототипов
  4. Составьте список и описание сущностей с набором параметров, которым они должны соответствовать. Для функциональных особенностей, которым не нашлось места ни в одной из категорий, посвятите отдельный раздел
  5. Опишите критерии дизайна: цветовые стили, шрифты, палитру кнопок, иные особенности визуального оформления, которые удалось согласовать
  6. Составьте сценарии использования сайта, если на нем планируется размещать интерактивные элементы. Определите ответственного за контент и составьте контент-план
  7. Согласуйте ТЗ с заказчиком
Управляйте командой из OkoCRM
Таск-трекер для командной работы внутри CRM. Ставьте задачи, отслеживайте дедлайны и организуйте совместную работу над проектами.
Попробовать
Получайте статьи почтой. Самое важное и дважды в месяц. Иногда смешно, но не сильно
Наверх
Мы используем cookie для вашего удобства. Используя сайт, вы соглашаетесь с этим. Подробнее - в политике конфиденциальности.
Я согласен