Пользователь
0,0
рейтинг
18 марта 2011 в 12:09

Управление → Что такое проектирование сайта и почему его нужно делать

Проектирование — этот, возможно, ключевой этап создания интернет-сайта, отвечает нам на следующие вопросы:
  1. Каковы наши цели — зачем мы делаем сайт? Как мы реализуем поставленные цели?
  2. Как сайт будет выглядеть и работать?

О пользе проектирования


Проектирование даёт сайту очень много:
  1. Сильно повышает гарантию достижения результата.
    Только четко сформулировав задачи, определив целевую аудиторию сайта и её потребности, смоделировав взаимодействие сайта и его пользователей, мы можем быть уверены — мы получим то, что нужно.
  2. Экономит время и деньги.
    Исправить ошибку на этапе проектирования довольно просто: меняем несколько кусков текста и схем. Сделать это на этапе разработки дизайна или вёрстки будет уже дороже. Если ошибка обнаруживается на этапе программирования, её исправление может стоить многие тысячи (десятки, сотни тысяч) рублей и занять месяцы, а то и годы.
  3. Позволяет эффективно разделять работу.
    Проектное задание — это вполне самодостаточный документ. Получив его, клиент может сделать сайт своими силами или нанять другую команду, которая, по его мнению, лучше справится с непосредственно разработкой (у нас есть такой опыт, когда мы выполняли только проектирование, а клиент разрабатывал сайт своими силами).
Я бы не рекомендовал пренебрегать проектированием даже для самых маленьких сайтов; для самой распоследней одностраничной визитки это будет исключительно полезно. Потратьте хотя бы несколько дней — не пожалеете.

Исключение, пожалуй, составляют недорогие сайты — с бюджетом 5-15 тысяч рублей — где проектирование становится нерентабельным, увы.

Как проектировать сайт


Проектирование можно условно разбить на четыре основные части:
  1. Целеполагание,
  2. Исследование контекста,
  3. Создание концепции,
  4. Моделирование.

Целеполагание


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

В будущем они же помогают оценить успешность проекта.

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

Исследование контекста


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

Контекст проекта помогает нам понять целевую аудиторию и то, каким нужно сделать сайт: как его позиционировать, какая информация на нём должна быть и на каком языке он должен говорить с ЦА (это называют коммуникативной стратегией), как он будет отличаться от конкурентов (естественно, в выгодную сторону).

Кроме того, исследование погружает команду проекта в тему, позволяет где-то даже на подсознательном уровне видеть/принимать правильные решения.

Лучше всего, конечно, исследование помогает понять аудиторию:
  • Как с ней общаться: какие слова использовать в «разговоре» с ней, как называть свой продукт или услугу (возможно, нужно использовать профессиональный сленг, или наоборот, нарочито упрощённую терминологию), обращаться ли к ней на «вы» или на «ты».
  • Каковы её потребности: что приоритетно, что необязательно, но желаемо, что нельзя делать ни в коем случае.
Где брать данные

В идеале, данные о контексте мы должны получить от клиента, но если таких данных у клиента нет, то исследование контекста предстоит провести самим.

Для исследования я советую использовать два метода, которые лучше всего зарекомендовали себя на всех без исключения проектах, которые мы делали:
  • Исследование доступных источников — литература, Интернет-ресурсы и так далее.
  • Интервью с ключевыми действующими лицами — пользователями, экспертами.
Предвижу комментарии: дескать, самостоятельное исследование рядом не стояло с профессиональными маркетинговыми исследованиями — так зачем тратить время и ресурсы? На то есть несколько причин:
  • Без данных о контексте ваши шансы сделать хорошо пользователю стремятся к нулю.
  • Даже самостоятельное исследование даёт полезную информацию, пусть и в меньшем объёме, нежели профессиональное.
  • И даже если вы настолько неумело проводите исследование (что маловероятно), что не можете получить ответы на вышеобозначенные вопросы, вы всё равно погружатаетесь в контекст проекта и хотя бы подсознательно улавливаете что-то полезное.
Могу сказать по собственному опыту: нам исследование помогало всегда, в любом проекте.

Создание концепции сайта


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

Моделирование сайта


Моделирование — это создание модели сайта, которая описывает функциональные возможности и информационную структуру.

Функциональная часть модели

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

Информационная структура

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

Далее, прорабатываем схему раздела — это более глубоко и детально проработанная схема (по сравнению с информационной структурой сайта), показывающая навигацию по разделу, связи и переходы между подразделами. Схема раздела в идеале включает следующие элементы:
  • Задачи — какие из ранее поставленных задач решает раздел. Например, раздел «Фотографии» в социальной сети решает задачу обмена информацией между друзьями и последующего общения;
  • Сообщения — это в буквальном смысле сообщения, которые раздел или его часть передаёт посетителю. Например, сообщение приветствия «Привет, ты на портале ХХХ! Мы рады видеть тебя здесь» или «Эй, это наш лучший товар — попробуй, закажи сейчас и убедись в этом сам!».
    Сообщения бывают разных типов; наиболее часто встречающиеся: рекламные, призывы к действию, уведомления и имиджевые сообщения.
  • Функциональные элементы — элементы интерфейса, дающие возможность посетителю выполнить какую-то операцию. Например, функциональным элементом является форма для ввода сообщения, позволяющая отправить сообщение, или кнопка в интерфейсе, сохраняющая сделанные изменения.
  • Варианты поведения посетителя — предположения о том, что посетитель сайта может или должен сделать после изучения интерфейса или отдельных его частей.
Мы обычно делаем такие схемы в виде mind maps — очень удобно, надо сказать.

Резюме


Как обычно, краткие выводы:
  1. Обязательно проектируйте любой сайт. Если не умеете, то самое время начать учиться.
  2. Проектирование полезно: оно повышает качество сайта, экономит время и деньги.
  3. Проектирование — это, прежде всего, правильная постановка задачи, а затем вытекающие из неё исследование, концептуальное и инженерное моделирование.
P.S.: Статья эта, очевидно, обзорная, для затравки, поскольку тему проектирования раскрыть в одной статье нереально. Практически любая мысль из этой статьи была неоднократно подтверждена нашим личным опытом, и обо всём мы расскажем позже, подробнее и с примерами.

Если вам эта статья показалась полезной, отпишите в комментариях, о каких этапах проектирования вы хотели бы узнать подробнее.
Алексей Ёжиков @Heath
карма
220,1
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (44)

  • 0
    Спасибо за четкую концепцию! Ранее уже пользовался проектированием, но описать для себя было лень.
  • +4
    Пример бы готового документа по этому плану.
    • +3
      Спасибо за вопрос.

      По соображениям NDA мы не можем выкладывать реальные проекты, но мы как раз готовим шаблон проекта для вымышленного шоу-рума женской одежды «XXX», упоминавшегося в предыдущей статье в шаблоне видения.

      Это будет тем более полезно, что будет заметно реальное отличие видения, короткого пред-проекта для оценки задачи, от реального проекта — постановки задачи.
      • 0
        Ну можно же имена там заменить, цели и сроки поменять, сделать пример, в общем.
        • 0
          А мы так и делаем.
  • +1
    >Если вам эта статья показалась полезной, отпишите в комментариях, о каких этапах проектирования вы хотели бы узнать подробнее.

    Создание концепции сайта подробнее не помешало бы. Как вы ее проводите? Какими инструментами или технологиями пользуюутесь? есть какой-либо шаблон или план создания ??? Ну в общем поподробнее с практической точки зрения хотелось бы рассмотреть, чтобы перенести на себя какие-то моменты
  • 0
    LIAL,

    Принято. Напишу об этом отдельно.
  • +2
    Все правильно, однако реалии таковы, что часто приходится демпинговать с конкурентами по срокам, и времени на все эти анализы не остается. К тому же, большинству клиентов нельзя заявить «мы ваших конкурентов будем неделю анализировать и писать отчет, а вы нам за это будете много платить» — клиент откажется от такой услуги, у него нет понимания зачем это, многие даже элементарно за ТЗ отказываются платить, заявляя «я у вас сайт покупаю, а ваше ТЗ не моя проблема» — приходится каждый раз воевать с ними.
    Все это работает только с крупными заказчиками, которые понимают зачем им проектирование, которые готовы много платить и долго ждать, но таких мало.

    И да, очень хорошо, если клиент хотябы к моменту завершения сроков по написанию ТЗ определится какие вообще разделы будут у него на сайте. Я к последнему клиенту уже 3 раза ездил, 4 раза переписывался и 3 раза напоминал по телефону. За это время мы родили только 70% основных разделов. А надо еще подразделы, т.к. некоторые из них будут на главной и дизайнеру нужно знать сколько их там будет. Невозможно что-то проектировать в таких условиях.
    • +1
      Какой отличный комментарий. Давайте-ка по пунктам:

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

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

      3. Уважаемый Alexx_ps, клиент НЕ должен определяться, какие разделы у него будут на сайте. Это должны определять вы и только вы в процессе проектирования. Вы должны родить 100% разделов и подразделов, детально их описать по предложенной нами или другой схеме, а клиент должен это утвердить.
      • 0
        С третьим пунктом не согласен. Мы можем только частично предложить разделы, которые работают для любого бизнеса. По остальному — мы не знаем специфики бизнеса клиента, не знаем что важно, а что второстепенно при выборе покупателем «насосов взрывобезопасных» и заказе услуги по рытью колодцев.
        • +1
          Если вы не знаете специфики бизнеса-клиента, её надо узнать. Как можно делать сайт, не зная, как работает бизнес клиента?!
          • 0
            Кому вы предлагаете ее узнать? Эккаунт-менеджеру, который постоянно в разъездах и в офисе бывает 2 часа в день? Менеджеру проекта, который лично с клиентом не взаимодействует, пока тот не соизволит сам приехать в офис и все нам рассказать? Дизайнеру, которому вообще пофиг?
            • +1
              Менеджеру проекта, который лично с клиентом не взаимодействует, пока тот не соизволит сам приехать в офис и все нам рассказать? Дизайнеру, которому вообще пофиг?

              Вот это грустно. Это неправильно поставленный процесс создания сайта. Менеджер проекта — первый, кто должен с клиентом взаимодействовать.
      • 0
        Ну и опять же 8 из 10 клиентов среднего размера не читают наш договор на 12 страниц и ТЗ на 32 страницы, а только пролистывают. Не знаю где вы берете клиентов, которые все понимают, читают и даже вносят правки.
        Какая у вас минимальная цена на сайт?
        У нас по городу средняя 60 000р. и начинается все с «ну мы же в 15 уложимся?» — заявляет крупная компания с офисами в 5 регионах.
        • 0
          Боюсь, что администрация воспримет этот как рекламу. Напишу в личку.
  • +1
    я вот дизайнер, работаю в фирме небольшой и мне дали один проект, заказчик там дурной на всю голову, ну не знает он, что ему нужно, я уже третий макет сделал, а ему все не нравится, у него такая политика, что я должен предоставлять разные макеты пока ему не понравится, и главное мое начальство молчит по этому поводу. Что вот тут делать с такими паршивыми заказчиками?
    • +2
      Аркадий,

      Вам нужно заниматься своим делом, а проектировать должен проектировщик до того, как вы приступите к работе. Если же вы и есть проектировщик, то не начинайте рисовать до создания проекта сайта.
      • –1
        Заказчику нужен уже результат, а не какой то проект.
        • 0
          В вашем случае уже трудно что-то сделать, поскольку вы уже работаете над проектом и, видимо, долго. Естественно, сейчас заказчику проект уже не нужен.
          • 0
            Я к тому, что зачастую заказчики не хотят не заполнять никакие брифы, не втыкать в какие-то проекты, а хотят сразу сайт. Если даже им объяснять, для чего это нужно и т.д. они просто могут забить и уйти в другую студию, а клиента же терять не хочется, поэтому приходится прогибаться и т.д. Вот у вас же наверняка были такие случаи…
            • +1
              Надо объяснять и, лучше всего, если не понимают, не работать. Не надо прогибаться: сделаете плохой сайт, клиент останется недоволен, ничего не заработаете, потратите время и нервы.

              У нас были такие случаи, но нам почти всегда удавалось объяснить клиенту, зачем нужно проектирование. В тех редких случаях, когда не удавалось, отказывались работать.
    • 0
      А Ваша компания заключала договор? Лучше вписать в договор, что Исполнитель обязуется нарисовать N вариантов дизайна, а все остальное Заказчик оплачивает дополнительно. Это в идеале. А по сути такие вопросы должен решать менеджер проекта.
  • 0
    И заказчики сайта-визитки согласны за это платить? В какой стране вы работаете, в России? Серьезно, несколько дней седеть и проектировать сайт из пяти статичных страниц?
    • 0
      Мы работаем в России. И проектируем несколько дней, несколько недель или месяцев — столько, сколько нужно.

      Насчёт сайтов-визиток: размер сайта не играет роли. Проектирование нерентабельно только в проектах с очень маленьким бюджетом — 10-20 тысяч рублей. Да и то, можно сократить проектирование хотя бы до уровня, который есть в видении, и результат уже будет лучше.
      • 0
        Значит вы очень крутые. У меня на работе этим не занимаются. Описывают задачу дизайнеру, программисту и делаем. Проговариваем сложные вопросы и всё. Правда, ничего не записывается, есть тз. Может это оно и есть?

        Я просто серьезно не представляю как подойду к менеджеру и скажу «а давайте попроектируем этот сайт», он спросит «а что там проректировать? Три странички с текстом?», и мне нечего будет ответить.
        • 0
          А вы менеджеру нашу схему предложите, попробуйте и сразу всё поймёте — что проектировать и какой результат на выходе.
  • 0
    Статья понравилась, хотя, на мой взгляд, слишком общо. Хотелось бы на конкретном примере получить информацию об общих принципах проектирования схемы раздела, особенно с точки зрения взаимодействия с пользователем и «защиты от дурака».
    • 0
      Я как раз в «P.S.» указал, что статья для затравки и описывает в целом процесс проектирования. Детали будут позже в отдельных топиках. Ваше пожелание я учёл.
  • +3
    Пока в головах сайтостроителей есть мысль о том, что можно сделать сайт за 5-15 тысяч рублей, у нас не будет ни денег, ни хороших сайтов.
    Мне выгоднее курьером работать, чем сайты клепать за такие деньги.
    • +1
      Спасибо, Георгий. Бальзам на раненую душу.
  • +1
    Ждём примеров. Мне было бы интересно подробнее ознакомиться с каждым этапом проектирования, т.к. опыта в этом нет.

    А может это сделать в виде блога на конкретном примере? Т.е. берется задача — сделать сайт. Выбирается тематика, придумывается легенда, моделируется заказчик и пр. И на примере его разработки описываются все этапы, на выходе будет готовый сайт. Получится неплохой обучающий материал + наглядный пример этапов вашей работы для клиентов.
    • +1
      Александр,

      Мы уже придумали заказчика, выбрали легенду — вот здесь можно посмотреть — и как раз занимаемся проектированием. Выложим отдельно описание каждого этапа проектирования, начиная с целеполагания и исследования.
  • 0
    Как вы определяете стоимость сайта и на каком этапе?
    • 0
      Александр,

      Общий алгоритм определения стоимости сайта прост как пареная репа: все затраты + ожидаемая прибыль. А вот как определить все затраты — это уже интереснее.

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

      1. Если это простой сайт, то мы можем прикинуть его стоимость +10%, включая проектирование, и заявить её клиенту.
      2. Если это сложный сайт, то мы вынуждены отказываться от работы без предварительного проектирования. Увы, корректная оценка без проектирования часто просто невозможна.
      • 0
        Ох, вы разложили все по полочкам, все то, что у меня так не получалось. И позвольте еще спросить. Если после проектирование, вы или клиент решает остановить дальнейшую разработку. Выходит у нас есть клиент с проектом сайта и допустим он с ним обращается к другим разработчикам. И меня беспокоит, согласятся ли другие разработчики работать по вашему проекту? Ведь они могут отказаться, а клиент получается потратил деньги только зря. Можно ли как то избежать таких неприятностей?
        • 0
          Да, такое может произойти, но в принципе другим разработчикам боятся хорошего проекта, сделанного чужими руками, не стоит. Проект даёт им ту информацию, которая им всё-равно понадобится.

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

          Есть другая проблема — иной взгляд на проект. Это когда другой разработчик смотрит на проект и думает, что он бы сделал всё (или половину) иначе. Что же, он имеет право так думать, но клиент с проектировщиком работали над проектом и, видимо, не просто так его утвердили. Значит, он действительно соответствует целям клиента и предлагает правильные решения. В таком случае клиенту нужно найти разработчика, который конструктивно посмотрит на проект, возможно, дополнит его и возьмётся за работу.

          Приятная особенность проекта в том, что он не прописывает мелкие детали и оставляет определённую степень свободы разработчику.
  • 0
    Стоит добавить, что если клиент планирует в будущем продвигать свой сайт (SEO), то необходимо и это учитывать при проектировании. Как минимум предусмотреть оптимальные точки входа (страницы) по основным группам запросов.

    В целом из статьи ничего нового не узнала. Очевидные вещи для разработчика с головой.

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

    Или про разработку больших проектов (если есть опыт), где только этап исследования занимает от 2-3 месяцев.
    • 0
      Конечно, любое продвижение учитывается в задачах.

      Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…

      Про исследования подробнее будет в следующей статье, но только не про особенности, а про методику с примерами. Особенности поведения пользователей в каждой области свои или вовсе от области не зависят. Возможно, если будет интересный материал касательно конкретной области, опубликуем.

      Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.
      • +1
        Про большие проекты: интересно как не увязнуть в цифрах и бумагах и перейти во время к разработке.
        Т.е. какой объем и детализацию на этапе проектирования/ТЗ можно считать достаточной для перехода к следующим этапам разработки.

        Попробую пояснить.
        При разработке больших проектов достаточно сложно сразу спроектировать и предусмотреть всё, вплоть до мелочей. Во-первых, это может занять слишком много времени. Во-вторых, данные могут потерять актуальность в процессе работы. В-третьих, на выходе можно получить такое многотомное ТЗ, что ни заказчик, ни прочие участники проекта, не смогут в нем разобраться.
        Но без ТЗ начинать работу нельзя.
        Где золотая середина?:)

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

        • 0
          Светлана, я понял ваш вопрос. Изумительно, что вы это спросили.

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

          Вообще, наш опыт говорит, что пытаться прописать всё и максимально детально на этапе проектирования, а иногда даже ТЗ — это потеря времени, причём! это относится не только к большим проектам, но к ним в большей степени. Гораздо эффективнее управлять изменениями в процессе работы над проектом. Но это не означает, что проект должен быть на 3 страницах и содержать только общие слова. Важна золотая середина, о которой вы упомянули. К сожалению, словами её определить трудно; в отсутствии примера (мы его готовим), я не могу вам сейчас продемонстрировать это наглядно, но обещаю, что это будет сделано.

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

          Резюмирую: углубляться в детали на уровне проекта не стоит, а какой объём данных можно считать достаточным для перехода к разработке интерфейсов и программированию — это лучше показать на примере реального проекта.
  • +1
    Вот отличная статья на эту тему — uxmovement.com/thoughts/the-web-design-process-everyone-should-follow

    Но вы, наверное, ее уже читали.
    • 0
      Я эту статью не читал, но она действительно неплохая.
  • 0
    Молча положу тут ссылочку: http://webmascon.com/
  • 0
    Хороший текст, скажу я как PM. Всем, кто изучает тему, посоветовал бы A Practical Guide to Information Architecture (pdf 20 mb www.mediafire.com/?o0qdcxcb0dwx3q3)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.