Техническое задание на создание сайта образец: ТЗ на разработку сайта образец (пример) заказать | Техническое задание на создание сайта скачать

alexxlab

Содержание

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

Обновлено в 2021 году.

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика — потратил время впустую.

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

Статья будет полезна:

  • Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
  • Менеджерам проектов.
  • Руководителям диджитал-студий.
  • Предпринимателям, которые планируют заказать разработку сайта.

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

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

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

Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

  • Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет — без проблем поменять еще до начала разработки.
  • Увидеть компетентность исполнителя. Если техзадание понятное и четкое — доверие к разработчику повышается. Если там написана каша — возможно, стоит бежать и не оглядываться.
  • Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор — можно даже принудить через суд.
  • Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде — она втянется в работу в разы быстрее.
  • Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

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

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

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

Техзадание составляет исполнитель

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

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

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

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

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

Пишите однозначно и точно

Этот совет вытекает из главной цели техзадания — «Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое — с невнятными формулировками, которые ничего сами по себе не значат:

  • Сайт должен понравиться заказчику.
    А если у него будет плохое настроение?
  • Сайт должен быть удобным. Что это значит? Удобным для чего?
  • Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
  • Качественный экспертный контент. Ну, вы поняли.

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

  • Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
  • Большие нагрузки → 50 тысяч посетителей одновременно.
  • На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
  • Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

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

Поясните сложные термины

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

Опишите инструменты и требования к хостингу

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом — он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP — а у клиента сервер на .NET.

Перечислите требования к работе сайта

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

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

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

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

Это один из важнейших этапов работы на сайтом. Структура — это фундамент. Если она неудачная — сайт получится кривой.

Объясните, что будет на каждой странице

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

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

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

Распишите сценарии использования сайта

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

  • Действие пользователя.
  • Ответное действие сайта.
  • …
  • Результат.

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

Подробнее о сценариях использования читайте в «Википедии».

Определите, кто отвечает за контент

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

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

Указать, что весь контент должен быть уникальный, — это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

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

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

Вместо вывода: структура техзадания

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

  • Информация о компании и целевой аудитории, цели и задачи сайта.
  • Глоссарий терминов, которые могут быть непонятны клиенту.
  • Технические требования к верстке и работе сайта.
  • Описание используемых технологий и список требований к хостингу.
  • Подробная структура сайта.
  • Прототипы страниц или описания элементов, которые должны на них быть.
  • Сценарии использования нестандартного интерфейса (опционально).
  • Список контента, который делает разработчик.
  • Требования к дизайну (опционально).

Также рекомендую почитать

Комментарии разработчиков

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

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

Техническое задание на сайт / Хабр

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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


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

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

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

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

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

Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему.

И diff и ТЗ имеют свою стоимость, причем стоимость нужно понимать более широко, чем просто деньги. Это деньги, время, потраченные нервы, испорченные отношения и т.д.
Стоимость diff — это стоимость изначально неоговоренных доработок, стоимость ТЗ — это, собственно, стоимость ТЗ. Чем более подробное и детализированное техническое задание, тем выше его стоимость, но тем меньше величина и стоимость diff-а, и наоборот.

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

Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.

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

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

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

2. Что в нем должно быть и чего нет. Формулировки

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

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

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

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

Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы. В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно».

«Всё, что не оговорено, выполняется на усмотрение исполнителя» — не смотря на суровость этого заявления, эта фраза должна присутствовать в ТЗ. Она проистекает из самой сути задания: заказчик хочет получить некий продукт, но он не может и не должен указывать каким образом будет достигнут конечный результат. Этот пункт защищает от вмешательства в глубины работы (не хватало, чтоб заказчик начал рассказывать, как именовать функции в коде и какие пакеты использовать), но также перечеркивает возможность заказчика иметь любые хотелки. На мой взгляд, стоит идти на встречу заказчику в хотелках, пока это не выходит за рамки приличия. Когда же терпение лопается, нам и пригодится этот пункт. Как в песне поется: «Мы мирные люди, но наш бронепоезд стоит на запасном пути». (Фразу «что не оговорено — на усмотрение исполнителя», лучше всунуть под конец ТЗ, в начале она может быть встречена в штыки. Но если ТЗ нормальное и в конце стоит эта фраза, против неё не будут протестовать).

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

3. Разделы ТЗ

3.1 Общие слова

Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи. Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.

3.2 Эксплуатационное. назначение

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

3.3 Функциональное назначение

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

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

3.4 Термины и определения

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

Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.

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

3.5 Данные и списки

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

Данные

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

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

Для примера, та же самая новость:

  • Заголовок
  • Текст
  • Дата публикации

Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная.

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

Списки

Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.

Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.

Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра. И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е. тут нужно подробно описывать алгоритм по определению сходства статей. Пропустив этот пункт на этапе оценки сроков можно промахнуться достаточно сильно.

3.6 Страницы с описанием

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

Тут будет уместно описать не только, что отображается, но и как. Не в том смысле, что мы описываем дизайн: «Большими красными буквами отображается название новости», а в смысле, как работает: «Слева плавно выезжает окошко с предложением ввести логин и пароль». Или так: «при нажатии кнопки „Отправить комментарий“, комментарий появляется на странице без перезагрузки, с помощью AJAX».

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

Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:

Стоит следить, чтобы текстовое описание не вступало в противоречие с тем, что нарисовано в эскизе.
Т.е. если на иллюстрации новость имеет «Категорию новости», а в разделе «Данные и списки» новость не имеет ее, то это проблема. Очень высока вероятность, что изучая ТЗ, заказчик запомнит именно картинку с эскизом новостей, в которой есть категория, и если в готовом проекте не будет категории (в соответствии с текстовым описанием новости), он расстроится.

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

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

3.7 Требования к надежности

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

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

3.8 Требования к хостингу

Очевидно, что вполне может возникнуть, например, такая ситуация. Наша веб-студия делает красивые сайты, но пишет исключительно на Django. Заказчик нашел наш сайт, увидел красивые дизайны и сделал заказ. Приходит пора выкладывать сайт на хостинг, к другим десяти сайтам заказчика, а там, естественно PHP. И начинается, «а я думал что все на PHP делают…, у меня другого хостинга нет, надо переделывать на PHP».

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

Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.

3.9 Наполнение контентом

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

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

Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.

3.10 Сдача и приемка

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

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

Кстати, 100% оплата, я думаю, не должна означать окончание исправления багов. На мой взгляд, на баги должна даваться пожизненная гарантия, и исправляться они должны всегда и бесплатно. Хотя, думаю, тут будут и иные взгляды на эту проблему.

Заключение

Конечно, это ТЗ не охватывает все стороны сайта, но для очень большого числа проектов оно станет хорошим описанием.

Да, это ТЗ имеет пробелы, например, не сказано, как быть если у сайта должно быть API. Однако, имея хороший раздел «данные и списки», расширить ТЗ на эту область будет достаточно просто.

Буду рад услышать критику и, особенно, описание случаев, когда подобное ТЗ не подходит.

Техническое задание (тз) на разработку сайта

От автора: Как написать техническое задание (тз) на разработку сайта? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.

Итак, техническое задание на разработку сайта

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

Давайте проанализируем такой пример:

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

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

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

Что мы имеем. Исполнитель пункт тз выполнил, а вы хотели совсем иное. Вроде все в соответствии, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги.

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит техническое задание?

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

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

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

Поехали по пунктам.

Описание

Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.

Далее тут указываем:

для кого — целевую аудиторию:

потенциальные покупатели

продавцы продукции (магазины, интернет-магазины)

сервисные центры

партнеры (фирмы)

потребители продукции (тот, кто уже купил)

…

Для чего нужен сайт:

Для повышения имиджа компании

Для увеличения продаж

Для удобства клиентов

…

Тип:

Корпоративный

Сайт – визитка

Интернет магазин

…

Языковые версии:

Английский

Русский

…

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.

Цели и задачи

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

Потенциальные покупатели продукции.

Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи:

Дать качественную, исчерпывающую информацию о продукции, дополнительных услугах, гарантии, сервисе, методах выбора.

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули.

Функционал сайта

Для того чтобы перечислить функционал, нужно решить что ему необходимо:

Нужны ли новости

Нужен ли рекламный блок

Нужна ли регистрация

Нужен ли закрытый раздел (только для зарегистрированных пользователей)

Нужна ли форма обратной связи

Нужен ли скрипт рассылки

И т.д. и т.п.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала

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

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

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

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

Далее может идти вкладка «новости». Подпункты могут быть «события», «акции», «новое».

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

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

о компании

история компании

контакты

отзывы

новости

события

акции

новое

продукция

каталог продукции

релизы

отзывы о продукции

сервис

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

Как стать сервисным центром

Часто задаваемые вопросы

партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

Примерно так описывается общая логика работы.

Теперь в нашем тз на разработку сайта, подробно описываем каждый обозначенный блок сайта. Например «Новостная лента».

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

В данной статье я не стремился показать, что именно так составляется тз и никак иначе. Делайте так и проблем не будет. Составить качественное техническое задание на разработку сайта – это скорее вопрос опыта. На первых парах составить грамотное техническое задание получиться далеко не у всех.

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

И не забывайте про задание!

Автор: Бернацкий Андрей

E-mail: [email protected]

«Киберсант-вебмастер» — самый полный курс по сайтостроению в рунете!

P.S. Хотите опубликовать интересный тематический материал и заработать? Если ответ «Да», то жмите сюда.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Хотите узнать, что необходимо для создания сайта?

Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!

Смотреть

Техническое задание на разработку сайта (ТЗ, бриф)

Техническое задание – это основа, от которой необходимо отталкиваться при разработке любого сайта. Оно может быть сформулировано в нескольких словах, если это простой сайт на подобие сайта-визитки без какого-либо функционала, а может достигать и 50 страниц формата А4 для крупных сайтов портального типа. Именно поэтому точную стоимость создания сайта и сроки можно сказать только после прочтения технического задания на разработку и его анализа менеджером и тех. специалистами.

Что должно содержать техническое задание на разработку сайта?

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

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

3. Тип сайта. То есть указать, это будет сайт-визитка, промосайт, интернет-магазин, портал, каталог, блог, форум, инфосайт, корпоративный сайт или landing page (читать, чем отличаются эти типы сайтов).

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

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

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

6. Дизайн. Этот пункт во многом перекликается со структурой, точнее ее визуализацией. Здесь требуется указать «декоративные» элементы, которые должны присутствовать на сайте: слайдер, карусель, всплывающие окна, баннеры, как ведет себя меню при навигации и пр. Цветовая гамма дизайна во многом определяется логотипом сайта, но можно вносить корректировки как тоновые, так и дополнять дизайн другими цветами.

7. Верстка. Отдельным пунктом идет ТЗ на верстку, так как этим занимается отдельно выделенный человек – верстальщик(и). Здесь нужно указать, как видится работа конкретных элементов сайта при наведении, нажатии или активации формы/кнопки/ссылки, так как, возможно, для их работоспособности потребуется подключение скриптов.

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

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

Именно в этой пункте описывается основная работа программистов.

9. Описание внутренних страниц сайта. Если в пункте «структура сайта» требовалось только перечислить все требуемые типы страниц, то здесь необходимо дать им полное описание как по дизайну, так и по функциональности.

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

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

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

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

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

+375 (17) 2-220-220
+375 (17) 2-220-120
+375 (29) 3-073-545
+375 (29) 8-073-375

Вернуться назад

Статьи по теме:

Узнаем как составить грамотное техническое задание на разработку сайта? Пример ТЗ

Создание сайта – дело нехитрое, если использовать онлайн-конструкторы. Но все они такие однотипные, что солидным фирмам приходится искать веб-мастеров или обращаться в ИТ-компании. На этом этапе создания ресурса крайне важно конкретизировать работу мастера, то есть составить техническое задание на разработку сайта.

Зачем на это тратить время?

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

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

Мудрость прошлого

Если перед заказчиком стоит задание разработки технического задания, ему не обязательно изобретать велосипед, лучше обратиться к истокам, что проверены многолетним практическим опытом. То есть необходимо написать образец технического задания на разработку сайта по ГОСТу. Казалось бы, нереально применять стандарты 1978 года к современным сайтам, но в Советском Союзе некоторые вещи умели отлично делать, и разработка стандартов не является исключением, кроме того они все еще актуальны. Особое внимание стоит уделить таким стандартам:

  1. Требования к содержанию и оформлению (ГОСТ 19.201-78).
  2. Техническое задание на создание автоматизированной системы (ГОСТ 34.602-78).

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

  • Введение, где указывается наименование фирмы-заказчика или ресурса, его краткая характеристика и сфера применения.
  • Основания для создания. Здесь нужно обозначить тематику, указать документы, подтверждающие необходимость создания ресурса, название организации, что утвердила этот документ. К примеру, результаты маркетинговых исследований показывают, что большинство пользователей ищет товары через Интернет, это и будет основанием для создания сайта.
  • Назначение. Указывается функциональное предназначение ресурса. Информирование, продажа и т. д.
  • Требования к ресурсу. Это самый большой раздел, где заказчик расписывает все свои пожелания относительно будущего веб-продукта. Здесь нужно указать функциональность, определить уровень надежности, описать условия эксплуатации, информационного наполнения, дизайна и т. д.
  • Требования к программному обеспечению.
  • Технико-экономические показатели. То есть указываются пожелания относительно уровня конверсии, преимуществ перед конкурентами, экономическая эффективность.
  • Этапы разработки. Заказчик устанавливает сроки выполнения задания.
  • Контроль. Указываются виды проверки.

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

Особенности составления ТЗ

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

Чаще всего при составлении примера технического задания на разработку сайта основными считаются такие моменты:

  • Информация о заказчике. Нужно кратко описать сферу деятельности, историю фирмы, составить список основных конкурентов. Эта информация вряд ли пригодится программистам, но для дизайнеров и копирайтеров она нужна.
  • Цель сайта. В этом блоке должна быть сосредоточена ключевая информация, позволяющая понять структуру будущего ресурса, функциональные возможности и общее направление дизайна. Здесь также дается характеристика основной целевой аудитории.
  • Требования к ресурсу. Самый большой раздел, в котором нужно указать свои пожелания относительно структуры, функционала, дизайна, программного обеспечения, хостинга и т. д. Сюда же необходимо вложить эскизы страниц и схему сайта.
  • План действий. Любой шаблон технического задания на разработку сайта должен включать в свое описание этапы разработки, перечень работ, которые будут проводиться на определенном этапе и сроки выполнения заказа.
  • Контроль и прием работы. В образце технического задания на разработку сайта должно быть четко описано, каким образом будет проверяться соответствие готового сайта указанным требованиям. Важно внимательно подходить к выполнению данной работы во избежание недоразумений с заказчиком.

Подробно проработав все эти пункты, можно быстро усвоить, как грмотно составить техническое задание на разработку сайта.

Кто должен этим заниматься?

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

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

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

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

Точность и однозначность

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

Другие нюансы

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

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

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

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

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

  1. Действие пользователя.
  2. Ответ сайта.
  3. Результат.

Контент и дизайн

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

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

Шаблон технического задания на разработку сайта

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

  • IP-адрес.
  • www (world wide web).
  • Административная часть ресурса, администратор.
  • Альтернативная подпись рисунка.
  • Веб-интерфейс.
  • Ссылка, линк.
  • Дизайн сайта, дизайн-шаблон страницы.
  • Динамическая и статическая страница.
  • Доменное имя.
  • Мета-тег.
  • Контент.
  • Общедоступна часть ресурса.
  • Бэкап, базы данных, файловая структура.
  • Хостинг.
  • Система управления сайтом.

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

  1. Назначение документа. Техническое задание на разработку сайта – это основной документ, что регламентирует процесс создания и приема ресурса.
  2. Данные заказчика. Указываются следующие координаты: название компании, контактные данные, юридический адрес, фактический адрес, электронная почта, сайт (если делается его ребрендинг), контактное лицо, контактный телефон.
  3. Краткие сведения о компании. Для образца технического задания на разработку сайта рассмотрим компанию ООО «Фортуна». ООО «Фортуна» производит (товар) для рынка Новосибирска. Компания тщательно следит за гигиеной производства, чистотой сырья и качеством производимой продукции. На фирме проводится сертифицированный контроль за качеством и безопасностью производимых товаров на базе принципов международной системы ХАССП.
  4. Основание для разработки. Основанием для разработки технического задания является Договор №__.

Цели и назначение ресурса

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

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

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

Технические требования к сайту

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

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

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

  • Посетители – имеют доступ исключительно к общедоступной части сайта.
  • Редактор – имеет возможность вносить поправки в материалы разделов.
  • Администратор – может назначать редакторов, добавлять или удалять разделы.

Доступ к административной части сайта следует защитить логином и паролем.

Технический функционал должен соответствовать рекомендациям поисковых систем. Во-первых, страницы должны иметь одинаковую кодировку. Во-вторых, переходы по ссылкам нужно реализовать при помощи тега «А». В-третьих, в HTTP-заголовках необходимо указать кодировку, а при обращении к сайту по ссылке site.ru нужно установить редирект 301 на домен www.site.ru .

Ресурс должен функционировать во всех современных браузерах, поэтому необходимо провести тестирование в:

  • IE 11.
  • Safari & Chrome for iOS 9.0-9.2.
  • Chrome 48.
  • Firefox 44.
  • Safari 9.
  • Edge 13.
  • Opera 34.

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

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

Хостинг, контент, структура

Дальше описываются необходимые системные требования, указывается язык разработки (PHP с базами данных или обычный HTML с CSS).

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

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

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

Дизайн и функциональные требования

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

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

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

Контент и порядок приема работы

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

Основаниями для приема сайта являются:

  • Соответствие ТЗ.
  • Тестирование на корректное отображение картинок.
  • Тестирование функциональности.

В конце каждого ТЗ необходимо написать порядок и сроки реализации проекта. В целом все работы можно условно поделить на 3 этапа:

  1. Разработка дизайна, утверждение, верстка эскиза.
  2. Программная разработка.
  3. Наполнение сайта информацией.

Возле каждого из этих пунктов указывается срок выполнения в днях. В соответствии с Договором срок может меняться. Если это не предусмотрено, изменение времени дедлайна проводится по письменному соглашению сторон.

Польза

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

SEO аудит сайта при создании или делаем техническое задание на разработку сайта правильно

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

Зачем нужен SEO аудит сайта и что это такое?

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

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

Цель SEO аудита

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

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

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

SEO аудит сайта vs SEO аудит на создание сайта: в чем разница?

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

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

В этом и скрывается настоящая ценность SEO аудита на создание сайта — шанс значительно сэкономить, изначально разработав сайт корректно.

Какие проблемы решает аудит на разработку сайта?

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

Ошибки в выборе типа сайта

Критичная ошибка может образоваться еще до того, как сайт начнет разрабатываться. Стоит лишь ошибиться и неправильно выбрать тип сайта. Далее ошибки собираются по накатанной: неправильно выбран тип сайта — неправильно подобран движок — сайт не соответствует бизнесу. В таких случаях доработки обходятся либо космических денег, либо вообще невозможны, и заказчики их избегают. Как вариант, вам может быть рекомендовано поменять движок сайта, чтобы он соответствовал бизнесу. А это фактически разработка сайта с нуля. SEO-аудит исключает такую вероятность.

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

Вы — владелец ремонтной мастерской для мотоциклов и хотите заказать собственный сайт. Вы предоставляете услуги только по ремонту и не планируете продавать детали для мотоциклов в Интернете. Одни используют CMS интернет-магазина для продажи услуг, а другие обычную контентную (например, WordPress). И вы не знаете, какое решение подойдет лучше именно вам. Не все разработчики сайтов вам смогут корректно помочь в этом вопросе.

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

Проблемы в структуре и меню

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

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

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

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

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

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

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

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

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

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

Проблемы с функционалом сайта

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблемы в технических SEO требованиях к сайту

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

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

Вы — главный врач клиники и далеки от SEO и разработки сайтов. Для своей клиники вы заказываете сайт у программиста-фрилансера и принимаете, в виду своих знаний, сайт лишь по визуальному оформлению. Собственно, подобное делает множество заказчиков сайтов, которые незнакомы с разработкой. Однако вам не повезло и, несмотря на эстетическую красоту, сайт очень долго загружается (более 10 секунд идет загрузка страницы и из них 6 секунд — это время отклика сервера). В итоге большая доля пользователей так и не дожидается загрузки страницы, покинув сайт. Для SEO продвижения показатель скорости загрузки страницы является критичным. И в итоге вам рекомендуют вносить правки.

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

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

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

Проблемы в перелинковке

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

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

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

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

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

Вы приходите на продвижение и вам в любом случае будут рекомендовать доработку сайта в подобном направлении. А это в любом случае лишний бюджет.

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

Проблемы с уникализацией и шаблонами метаданных

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

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

Вы — владелец интернет-магазина для парикмахеров. У вас ассортимент товаров в магазине в 4000 наименований. Вы наполнили магазин через экспорт информации из 1С Бухгалтерии и пришли на продвижение. Сейчас у вас Title на всех страницах сайта совпадает с h2 и полностью отсутствует информация в тегах Description на страницах, так как этой информации не было в бухгалтерской программе. Ваши страницы в поиске среди конкурентов выглядят не очень презентабельно.

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

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

Даже если вы решились на подобное внесение информации на сайт, но Title и Description можно и, иногда, даже нужно корректировать по мере изменения УТП магазина, измений правил поисковых систем и т.п. И вы каждый раз будете готовы тратить время контент-менеджера на подобные корректировки?

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

Проблемы в соответствии дизайна к SEO-требованиям

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

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

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

Мало того, вам при разработке сайта необходимо было внедрить 3 кнопки: «Купить», «Купить в рассрочку», «Купить в 1 клик». На этом этапе вы с дизайнером решили, что оптимально будет реализовать подобное в виде одинаковых по размеру кнопок с разными цветами:

При маркетинговом и SEO-анализе выяснилось, что функционал текста в карточке товаров нужно доделывать и он должен иметь возможность размещения картинок в описании, как тут:

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

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

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

Стоимость и сроки выполнения СЕО аудита

Работа специалиста может занимать от 14 дней до 3 месяцев в зависимости от сложности проекта. При этом вы должны понимать, что сам процесс и его результат стоит потраченных вами денег. SEO техническое задание на разработку сайта (ТЗ на разработку интернет-магазина, сайта-визитки, услуг, посадочной страницы, блога, инфорпортала) может стоить от 200$, но при этом вы значительно экономите на дальнейшей разработке и продвижении сайта, полностью исключив образование даже малейших ошибок, устранение которых может обойтись в несколько раз дороже.

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

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

С чего начинается техническое задание на создание сайта?

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

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

С чего начинается разработка технического задания

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

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

Важная ремарка для клиента

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

Что указывается в ТЗ на создание сайта?

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

Общие технические рекомендации

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

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

Структура сайта и меню

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

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

По итогу данного этапа клиент получает на согласование Mind-карту с изображением будущей структуры сайта, текстовую версию структуры в Word и рекомендации по ее реализации на сайте.

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

Модули перелинковки

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

Описание сквозных элементов

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

Микроразметка

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

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

Метаданные

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

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

Подробное описание страниц

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

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

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

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

Дополнительные разделы по запросу клиента

Дополнительно в техническое задание по запросу клиента могут быть внесены дополнительные разделы: технические задания на тексты для копирайтера, рекомендации по подбору домена, покупке SSL сертификата для подключения https протокола и чистовой вариант семантического ядра без мусорных слов. Или ссылочный анализ конкурентов с рекомендацией стратегии роста проекта.

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

Техническое задание на изготовление сайта составлено. Это всё?

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

Согласование с клиентом

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

Согласование с разработчиком

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

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

Проверка работы разработчиков

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

В общей сложности за весь этап разработки сайта таких проверок может быть несколько (2-3). Они бесплатны и входят в стоимость первоначального аудита. При этом нужно понимать, что если из 20 рекомендаций было реализовано только 10%, не следует присылать сайт специалисту, так как это считается израсходованной проверкой, ведь проверяется весь аудит в целом, а не его часть. Каждая проверка занимает время у СЕО-специалиста, в том числе на общение с разработчиками. Поэтому если необходимо выполнить больше положенных бесплатных проверок, заказчик должен заплатить за них. На данном этапе желательно все-таки присылать проект уже практически готовый, который находится на этапе наполнения и закрытый для индексирования. В этом случае большинство рекомендаций уже реализовано и то, что пропустил разработчик, будет четко указано.

Когда лучше заказать SEO аудит сайта —  на этапе разработки или до него?

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

[forms ID=37]

Следующий проект:Как разработать идеальный футер сайта? Подробное руководство с примерамиПредыдущий проект:Какой должна быть главная страница сайта? Советы по наполнению главной страницы, которая сможет продавать

Образец ТЗ на разработку сайта: каким оно должно быть?

Здравствуйте, уважаемые читатели! Эта статья адресована не только тем, кто собирается заказать создание сайта, но и веб-студиям, которые этими вещами, собственно, и занимаются. Речь пойдёт о техническом задании. Этот термин прочно вошёл в лексикон всех веб-разработчиков, программистов, дизайнеров и прочих тружеников интернет-тыла, сократившись до понятного всем «ТЗ».

Куда бы вы ни обратились (к фрилансерам или в компанию по созданию веб-проектов), с вас будут требовать техзадание. Некоторые «умудрённые опытом» специалисты без него даже разговаривать с вами не будут.

Где же взять образец ТЗ на разработку сайта? В Интернете, если порыться, можно найти много примеров заданий на создание проектов по разным тематикам. Вот только доставляет ли заказчикам удовольствие заполнять все эти нудные документы? Большинство разработчиков не думают об этом и… теряют клиентов.

Нужно ли вообще ТЗ?

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

Таким образом, ответ здесь однозначен: ТЗ необходимо!

Кто должен составлять техзадание?

Теперь мы подошли к более неоднозначному вопросу – кто должен заниматься составлением ТЗ?

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

Представьте: вы решили повысить продажи своей компании путём дополнительной рекламы в Интернете. Для этого вам необходим сайт-визитка или, возможно, интернет-магазин. Вы начинаете искать подрядчика, готового выполнить ваш проект за приемлемые деньги. Обзваниваете десяток веб-студий, и в пяти из десяти вам говорят: «Пришлите нам ТЗ, и тогда мы скажем вам стоимость».

Вы находите в Интернете шаблон техзадания и видите там множество пунктов:

  • Выбранный домен.
  • Предполагаемая возрастная аудитория.
  • Какие страницы должны быть.
  • Основные ключевые слова.
  • И так далее…

Скажите, ну откуда вам, ранее не сталкивавшемуся с понятиями «сайт» и «домен», знать ответы на эти вопросы. Итог – выбор другой студии, которая не требует ТЗ, а сама помогает в его составлении.

Вывод: ТЗ предпочтительнее составлять тем людям, кто будет вести работу над проектом. И выглядеть оно должно совсем по-другому…

Каким должно быть ТЗ?

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

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

Никаких заполненных бланков я не требую. Всё, что мне нужно – это знать:

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

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

Домен и хостинг – это детали, которые обсуждаются достаточно быстро. Цветовую гамму есть смысл обсуждать только на стадии рисования дизайна.

Я работаю по такой схеме уже давно, и она показала свою состоятельность.

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

Приношу свои извинения тем, кто планировал найти и скачать в этой статье готовое ТЗ. Это не мой метод.

Возникли вопросы? Отвечу на них в комментариях!

С уважением, автор блога Сергей Чесноков

Шаблон технического задания на проект

(ТЗ)

Техническое задание (ТЗ) содержит изложение предыстории, задач и цели предлагаемого проекта. Шаблон ТЗ включает ряд критериев, необходимых для принятия стратегических решений по проекту. Этот документ определяет действия, которые необходимо выполнить, и указывает проблемы, бюджет и знания, связанные с проектом. В следующем шаблоне технического задания на проект представлен обзор ключевых разделов документа ТЗ.В этой статье я описываю определение и содержание ТЗ. Шаблон доступен для платной загрузки в виде файла .doc.

Скачать бесплатно шаблон технического задания
(файл DOC, 48Kb)

Определение и цель ТЗ

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

Целью ТЗ является определение объема и типа работ, которые должны быть выполнены в рамках проекта. Это руководящий документ, который устанавливает и определяет отношения между всеми участниками проекта. Техническое задание разрабатывается после определения, определения и планирования проекта.

ТЗ проекта содержит четкое описание следующей важной информации:

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

Содержание TOR

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

  • Предварительное технико-экономическое обоснование и анализ осуществимости
  • Оценочная деятельность
  • Разработка и мониторинг договоров на выполнение
  • Оценочные исследования
  • Отчетность и аудит
  • Прочие консультационные услуги, необходимые на любой стадии проекта

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

Общий формат содержимого Технического задания проекта предлагается ниже:

  • Предпосылки проекта
  • Цели проекта
  • Проблемы, которые необходимо изучить и проанализировать по определенным критериям
  • Применяемая методология внедрения
  • Требуется экспертиза
  • Требования к отчетности
  • Рабочий план, включая графики работ

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

1. Предпосылки

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

Раздел «Предпосылки» в шаблоне ТЗ обычно включает несколько параграфов, в которых рассматриваются следующие вопросы:

  • Опишите проект в контексте бизнес-потребности
  • Укажите общую роль заинтересованных сторон в выполнении проектной деятельности
  • Выделите краткий обзор проекта на сегодняшний день
2.Цели

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

Раздел «Цели» шаблона технического задания должен описывать желаемые достижения на разных этапах жизненного цикла проекта. В нем также должны быть указаны основные цели проекта, которые должны быть достигнуты после успешного завершения проекта.Вот пример того, как это должно выглядеть.

Вид работ / Стадия проекта

Общая цель

Завершение проекта Увеличить продажи продукта «А» на 15% за 3 месяца
— Технико-экономическое обоснование Предоставить лицам, принимающим решения, достаточную информацию, необходимую для принятия или отклонения предложенного проекта
— Мониторинг Предоставить лицам, принимающим решения, достаточную информацию, необходимую для вынесения обоснованного суждения о выполнении проекта
— Аудит Чтобы проект оставался актуальным и разумным с юридической, экономической и технической точек зрения
3.Проблемы

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

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

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

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

Раздел «Методология» шаблона технического задания проекта должен включать описание следующих элементов:

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

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

В разделе «Экспертиза» шаблона технического задания проекта должно быть указано следующее:

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

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

Раздел «Требования к отчетности» шаблона технического задания должен четко определять требования к процессу отчетности и может включать в себя следующие сведения:

  • Содержание отчетов по проекту
  • Правила составления приложений
  • Шаблоны отчетов
  • Язык отчетов
  • Используемые компьютерные программы
  • Даты подачи
  • Лица, ответственные за отчетность и утверждение
  • Другая достаточная информация, такая как количество создаваемых копий, обязанности по составлению и представлению отчета и т. Д.
7. Рабочий план

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

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

  • Анализ проблем с точки зрения критериев оценки
  • Предлагаемая методика внедрения
  • Требования к отчетности
  • Финансовые ресурсы, выделенные на проект.

Разработка технического задания

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

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

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

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

Лучшая практика для технического задания

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

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

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

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

Разработка технического задания (ToR)

Техническое задание (ToR) или запрос предложений (RFP) — это четкое изложение ресурсов, ролей и обязанностей оценщиков и комиссара по оценке или менеджера, включая:

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

GeneraTOR
Щелкните здесь, чтобы перейти к информации о GeneraTOR от BetterEvaluation: бесплатное программное обеспечение, которое поможет вам в написании различных разделов ToR / RFP.

Шаг 2 уже помог подготовить большой объем информации, поэтому написание ТЗ в основном сводится к объединению необходимой информации в этом документе.

Для внутренней оценки, проводимой персоналом организации, ТЗ часто называют «краткой оценкой» или «соглашением об оценке».Большинство элементов формального технического задания или TFP для внешних оценщиков актуально для включения в краткий отчет / соглашение о внутренней оценке.

Помимо специфики проекта или программы и их контекста, оценка — цель, объем, ключевые вопросы оценки и методология оценки (или то, как они должны быть разработаны) — ТЗ / RFP должны также включать требования к отчетности, этапы или результаты, сроки и соответствующие договорные требования.

Хотя ТЗ или Запрос предложений для любого процесса оценки должны быть адаптированы к особенностям этого исследования и соответствовать требованиям организации, существуют элементы, которые должны включать все ТЗ / Запрос предложений:

  1. Фон
  2. Цель / задачи / обоснование оценки
  3. Предполагаемый (-ые) пользователь (-и) и использование (-и) оценки
  4. Ключевые вопросы оценки
  5. Принципы и подход, которыми будет руководствоваться оценка
  6. Методология
  7. Роли и обязанности различных участников
  8. Требования к отчетности (см. Непосредственно ниже)
  9. Хронология и вехи
  10. Любые особые требования

Некоторые организации включают ориентировочный или максимальный бюджет.

Требования к отчетности для оценки (упомянутой выше как раздел 8 ТЗ) могут включать:

  • Желаемый формат (ы) (например, устный, письменный, видео и т. Д.)
  • Материалы для распространения (такие как резюме, сводки, презентационные материалы, информационный бюллетень и т. Д.)
  • Целевая аудитория
  • Области содержимого
  • Желаемая длина отчета
  • Должен ли отчет включать конкретные рекомендации
  • Следует ли возвращать наборы данных, такие как заполненные анкеты, опросы, записи интервью, записи и т. Д.)
  • Вид поставки
  • Любые особые ограничения или необходимые разрешения для публикации информации из или на основе оценки

Как цитировать то, что вы нашли на веб-сайте, в стиле APA

Челси Ли

Пожалуй, самый частый вопрос, который мы получаем об APA Style: «Как мне процитировать веб-сайт?» или «Как мне процитировать то, что я нашел на веб-сайте?»

Во-первых, чтобы процитировать веб-сайт в целом, а не конкретный документ на этом веб-сайте, см. Этот FAQ.

Когда вы достигли уровня цитирования определенной страницы или документа, ключом к написанию записи в списке ссылок является определение того, какое содержание содержит страница. Руководство по публикациям Справочные примеры в главе 7 сортируются по типу контента (например, журнальная статья, электронная книга, газетный рассказ, сообщение в блоге), а не по расположению этого контента в библиотеке или в Интернете. Руководство Manual показывает как печатные, так и сетевые ссылки для различных типов контента.

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

Шаблон стиля APA для ссылок на веб-сайты

Содержимое в этой области яичного белка может показаться запутанным при цитировании, но шаблон для ссылок из этой области на самом деле очень прост, всего четыре части (автор, дата, название и источник):

Автор А. (дата). Название документа [Описание формата]. Получено с https: // URL

В тексте: (Автор, год)

Это описание формата в скобках используется только в том случае, если формат является чем-то необычным, например сообщением в блоге или заметками к лекциям; в противном случае в этом нет необходимости.Некоторые другие примеры описаний форматов перечислены на странице 186 Публикации Publication Manual .

Разрешается оставлять гиперссылки активными в записях списка литературы.

Пример ссылки на веб-сайт со всей информацией

Вот пример (сообщение в блоге), в котором у нас есть все четыре необходимых элемента информации (также см. Руководство , пример №76 ):

Примеры ссылок на веб-сайты с отсутствующей информацией

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

Вот пример, когда в этой новостной онлайн-статье не указан автор (заголовок перемещается на позицию автора):

А вот пример веб-страницы, на которой обозначено без даты (буквы без даты , которые обозначают без даты , заменяются вместо года):

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

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

Спасибо за чтение!

Примеры общего справочного списка

— Справочный лист

Что касается юридических справок, APA следует рекомендациям The Bluebook: A Uniform System of Citation , поэтому, если у вас есть какие-либо вопросы помимо примеров, приведенных в APA, поищите и этот ресурс.

Решения суда

Справочный формат:

Имя против имени, страница томного репортера (дата суда). URL

Образец справочной записи:

Браун против Совета по образованию, 347 U.S. 483 (1954). https://www.oyez.org/cases/1940-1955/347us483

Образец цитирования:

В деле Браун против Совета по образованию (1954 г.) Верховный суд признал расовую сегрегацию в школах неконституционной.

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

Устав

Справочный формат:

Название закона, название Источник § Номер раздела (год). URL

Образец справочной записи для федерального закона:

Закон об образовании лиц с ограниченными возможностями, 20 U.S.C. § 1400 и след. (2004). https://www.congress.gov/108/plaws/publ446/PLAW-108publ446.pdf

Образец справочной записи для государственного статута:

Закон о медсестринской практике штата Миннесота, Миннесота.Стат. §§ 148.171 и след. (2019). https://www.revisor.mn.gov/statutes/cite/148.171

Образец цитаты: Медсестры из Миннесоты должны иметь текущую регистрацию, чтобы практиковать (Закон Миннесоты о медсестре, 2010 г.).

Примечание. Символ § означает «раздел». Используйте §§ для разделов (множественное число). Чтобы найти этот символ в Microsoft Word, выберите «Вставить» и нажмите «Символ». Найдите подмножество Latin 1-Supplement.

Примечание: U.S.C. расшифровывается как «Кодекс Соединенных Штатов.«

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

Примечание. Сначала укажите главу, а затем раздел или ряд разделов.

Незаконченные законопроекты и постановления

(Те, кто не прошел и стал законом)

Справочный формат:

Название [если есть], номер счета или постановления, xxx Cong.(год). URL

Образец справочной записи для законопроекта Сената:

Закон о борьбе с фишингом, S. 472, 109-я конг. (2005). https://www.congress.gov/bill/109th-congress/senate-bill/472

Образец справочной записи для резолюции Палаты представителей:

Закон о борьбе с фишингом, HR 1099, 109-я Конг. (2005). https://www.congress.gov/bill/109th-congress/house-bill/1099

Образец цитирования:

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

Это три области права, которые вы, возможно, наиболее склонны цитировать в своей научной работе. Дополнительные примеры и объяснения см. В APA 7, глава 11.

Как цитировать веб-сайт — APA, MLA & Harvard

1. APA

Как цитировать весь веб-сайт в формате APA

Основной формат цитирования всего веб-сайта, а не отдельной страницы:

Пример всего веб-сайта

Менделей, Дж. А., Томсон, М., & Coyne, R.P. (2017, 16 января). Как и когда обращаться к . Получено с https://www.howandwhentoreference.com

.
Как цитировать веб-страницу в формате APA

Основной формат веб-страницы немного отличается от формата веб-сайта:

Примечание: этот формат одинаков для онлайн-статей; Заголовок страницы заменяется заголовком статьи, а заголовок веб-сайта заменяется заголовком контейнера.

Пример веб-страницы

Митчелл, Дж. А., Томсон, М., и Койн, Р.П. (25 января 2017 г.) Цитирование APA. Как и когда обращаться к . Получено с https://www.howandwhentoreference.com/APAcitation

Как цитировать сообщение в блоге в формате APA

Основной формат цитирования сообщения в блоге следующий:

Пример сообщения в блоге

В этом примере ссылка будет:

Дефео, К. (2017, 4 августа). Новый веб-семинар по исследовательской карьере [Запись в блоге].Получено с https://blog.mendeley.com/2017/08/04/new-webinar-on-research-careers/

.
Как цитировать твит в формате APA

Основной формат цитирования твита следующий:

Ручка автора твита. (Год, месяц, дата твита). Полный текст твита [твита]. Получено с URL

Пример твита

В этом примере ссылка будет:

Mendeley_com. (2017, 17 мая). Мы аплодировали нашему последнему выступлению на @pintofscience и нам стало грустно.Но мы буквально отскочили от #atomstogalaxies, и это был прекрасный финал [Tweet]. Получено с https://twitter.com/mendeley_com/status/864947989797896194

Как цитировать сообщение в Facebook в формате APA

Основной формат статуса Facebook следующий:

Пример статуса Facebook

В этом примере ссылка будет:

Mendeley. (2017, 16 мая). На исследователей всегда оказывается давление, чтобы они финансировали свою исследовательскую карьеру [обновление статуса в Facebook].Получено с https://www.Facebook.com/mendeley/photos/a.10150156999648611.291608.42920143610/10154866770358611/?type=3

Как цитировать онлайн-видео в формате APA

Формат цитирования онлайн-видео или видео на YouTube следующий:

YouTube, пример

В этом примере ссылка будет:

[Mendeley]. (2014, 3 апреля). Начало работы с Mendeley [видеофайл]. Получено с https://www.youtube.com/watch?v=Gv6_HuCYExM

.

Примечание: слово «Mendeley» в названии пишется с заглавной буквы, потому что это существительное собственное.

Для более полного охвата правил цитирования APA ознакомьтесь с нашим руководством по цитированию APA.

Вернуться к началу

2. MLA

Как цитировать весь веб-сайт в формате MLA

Основной формат цитирования всего веб-сайта в формате MLA:

Пример всего веб-сайта

Митчелл, Джеймс А. и Марта Томсон. Как и когда обращаться к . 25 января 2017 г .: https: //www.howandwhentoreference.com / APAcitation .

Как цитировать веб-страницу в формате MLA

Это очень похоже на ссылку на веб-сайт с добавлением заголовка страницы в кавычках перед заголовком сайта:

Фамилия, имя. «Заголовок страницы». Название сайта. Спонсорское учреждение / издатель. Дата публикации, число, месяц, аббревиатура. год, URL.

Пример веб-страницы

Томсон, Марта. «Цитирование АПА». Как и когда обращаться к . 2 февраля 2017 г .: https: // www.howandwhentoreference.com/APAcitation .

Как цитировать сообщение в блоге в формате MLA

Основной формат цитирования сообщения в блоге в MLA следующий:

Пример сообщения в блоге

Если использовать пример сообщения в блоге в разделе сообщения в блоге APA, ссылка будет выглядеть так:

Дефео, Кристиан. «Новый веб-семинар по исследовательской карьере». Блог Mendeley. 4 августа 2017 г., https://blog.mendeley.com/2017/08/04/new-webinar-on-research-careers/ .

Как цитировать твит в формате MLA

Основной формат цитирования твита:

Пример твита

Если использовать пример твита в разделе твитов APA, ссылка будет выглядеть следующим образом:

Mendeley_com. «Мы аплодировали нашему последнему выступлению на @pintofscience и нам было грустно. Но мы буквально взлетели с #atomstogalaxies, и это был прекрасный финал ». Twitter , 17 мая 2017 г., 13:57, https://twitter.com/mendeley_com/status/864947989797896194 .

Как указать статус Facebook в формате MLA

Базовый формат ссылки на статус в Facebook очень похож на формат твита:

Facebook Пример

Используя пример статуса, использованный в разделе APA FFacebook, ссылка будет:

Mendeley. Объявление о финансировании Mendeley. Facebook , 16 мая 2017 г., 11:05, https://www.facebook.com/mendeley/photos/a.10150156999648611.291608.42920143610/10154866770358611/?type=3 .

Как цитировать онлайн-видео в формате MLA

YouTube / онлайн-видео

YouTube, пример

Используя пример в разделе YouTube APA, ссылка в MLA будет:

«Начало работы с Mendeley». Youtube , загружено Mendeley 3 апреля 2014 г., https://www.youtube.com/watch?v=Gv6_HuCYExM

Для более полного охвата правил цитирования MLA 8 ознакомьтесь с нашим руководством по цитированию MLA 8.

Вернуться к началу

3.Гарвард

Как цитировать весь веб-сайт в гарвардском формате

Основной формат ссылки на весь веб-сайт в стиле Гарварда выглядит следующим образом:

Пример веб-сайта

Митчелл, Дж. А. и Томсон, М. (2017). Как и когда ссылаться на [Online]. Доступно по адресу: https://www.howandwhentoreference.com/APAcitation (дата обращения: 21 августа 2017 г.).

Как цитировать веб-страницу в гарвардском формате

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

Фамилия (и) автора, инициалы.(Год издания). Название страницы [Online]. Название сайта. Доступно по адресу: URL (дата обращения: день месяц год)

Пример веб-страницы

Томсон, М. (2017). APA citation [Online]. Как и когда ссылаться. Доступно по адресу: https://www.howandwhentoreference.com/APAcitation (дата обращения: 21 августа 2017 г.).

Как сослаться на сообщение в блоге в гарвардском формате

Ссылка на сообщение в блоге в MLA по структуре схожа со ссылкой на веб-страницу:

Пример сообщения в блоге:

Используя сообщение в блоге, упомянутое в разделе сообщения блога APA, ссылка на Гарвард будет:

Дефео, К.(2017). Новый веб-семинар по исследовательской карьере [Блог] Блог Mendeley . Доступно по адресу: https://blog.mendeley.com/2017/08/04/new-webinar-on-research-careers/ (дата обращения: 21 августа 2017 г.).

Как цитировать твит в Гарвардском формате

Основной формат цитирования твита в гарвардском стиле следующий:

Дескриптор Twitter. (Год издания). Текст твита [Twitter]. Твит дня месяца был опубликован. Доступно по адресу: URL (дата обращения: день месяц год).

Пример твита

Если использовать пример твита из раздела твитов APA, ссылка Гарварда будет:

Mendeley_com. (2017). Мы аплодировали нашему последнему выступлению на @pintofscience и нам стало грустно. Но мы буквально увеличили масштаб с #atomstogalaxies, и это был прекрасный финал [Twitter]. 17 мая. Доступно по адресу: https://twitter.com/mendeley_com/status/864947989797896194 (дата обращения: 21 августа 2017 г.).

Как указать статус Facebook в Гарвардском формате

Это то же самое, что и ссылка на Twitter, за исключением того, что дескриптор Twitter заменяется на имя автора / название группы, текст твита заменяется текстом сообщения, а [Twitter] заменяется на [Facebook]:

Пример статуса Facebook:

Используя пример статуса из раздела APA Facebook, ссылка в Гарварде будет:

Mendeley.(2017). На исследователей всегда оказывается давление, чтобы они финансировали свою исследовательскую карьеру [Facebook] . 16 мая. Доступно по адресу: https://www.facebook.com/mendeley/photos/a.10150156999648611.291608.42920143610/10154866770358611/?type=3 (дата обращения: 21 августа 2017 г.).

Как цитировать онлайн-видео в гарвардском формате

Основной формат для цитирования онлайн-видео следующий:

Имя пользователя. (Год публикации). Название [Онлайн-видео].День месяца размещен. Доступно по адресу: URL (дата обращения: день месяц год).

YouTube, пример

Используя пример видео YouTube из раздела YouTube APA, ссылка на Гарвард будет:

Mendeley. (2014). Начало работы с Mendeley [Онлайн-видео]. 3 апреля. Доступно по адресу: https://www.YouTube.com/watch?v=Gv6_HuCYExM (дата обращения: 21 августа 2017 г.).

Для более полного охвата правил цитирования Гарварда ознакомьтесь с нашим Гарвардским справочником цитирования.

Вернуться к началу

4. Устранение неполадок

A. Что делать, если в вашей ссылке нет автора:

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

B. Как узнать дату публикации веб-страницы:

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

.

  1. Найдите URL-адрес страницы, дату публикации которой вы хотите найти в Google, указав перед ней «inurl:».

  1. Скопируйте адресную строку браузера в адресную строку новой вкладки и добавьте в конец «& as_qdr = y15».Например, если бы мой поисковый URL был https://www.google.co.uk/search?q=inurl%abcd , я бы поставил https://www.google.co.uk/search?q = inurl% abcd & as_qdr = y15 в адресную строку новой вкладки.

  1. Нажмите Enter, и результаты поиска покажут дату публикации страницы.

Чтобы получить полное руководство по каждому из этих типов цитирования, ознакомьтесь с нашими справочными руководствами APA, MLA 8 и Harvard. Они содержат общие правила для каждого типа цитирования, а также конкретные примеры, охватывающие книги, статьи, видео и многое другое.Или посетите нашу полную шпаргалку, чтобы увидеть все форматы цитирования и источники в одной простой в использовании таблице.

Вернуться к началу

Образец технического задания (ТЗ) для консультантов по ГЧП

  • Глобальный / неспецифический |
    Global |
    Энергия и мощность |

    ToR — советник по транзакциям IPP

    Техническое задание (ТЗ) на услуги консорциума опытных консультантов по сделкам для оказания помощи правительству… подробнее

  • Глобальный / неспецифический |
    Global |
    Транспорт |

    Контрольный список ТЗ Возможные задачи для юридического консультанта Транспортный проект

    Ниже излагаются области работы для технического задания (ТЗ) по назначению юридических советников для оказания помощи… подробнее

  • Глобальный / неспецифический |
    Global |
    Телекоммуникации и ИКТ |

    ТЗ консультанта по вопросам реформы законодательства о телекоммуникациях

    Введение 1.В рамках подготовки к будущей либерализации приватизации действующего оператора связи, [… подробнее

  • Глобальный / неспецифический |
    Global |
    Телекоммуникации и ИКТ |

    ТЗ консультанта по вопросам реформы законодательства о сотовых телефонах в сфере телекоммуникаций (на французском языке)

    TERMES DE REFERENCE DES CONSULTANTS POUR LA MISE EN PLACE DU CADRE JURIDIQUE ET REGLEMENTAIRE ET POUR L’OCTROI D’UNE… подробнее

  • Глобальный / неспецифический |
    Global |

    Подразделение ГЧП — Образцы должностных инструкций и квалификаций для ключевого персонала

    Должностные инструкции и квалификация для следующего ключевого персонала: Директор компании Операционный директор… подробнее

  • Турция |
    Global |

    Полат Энерджи

    Дополнительные материалы по теме см. В разделе «Энергетические лицензии и процедуры лицензирования». Номер для отслеживания: Polat Enerji_2008_English

  • Франция |
    Европа и Центральная Азия |
    Энергия и мощность |
    Закупки

    Cahier des charge de l’appel d’offres portant sur deoliennes de production d’électricité en mer en France métropolitaine

    Номер для отслеживания

    : Технические характеристикиBiomass_2013_French Узнайте больше на ГЧП в сфере энергетики и энергетики и на ГЧП, не влияющих на климат Изображение… еще

  • Глобальный / неспецифический |
    Global |
    Энергия и мощность |

    ToR — Консультационная приватизация по сделкам с энергией

    Для получения дополнительной информации об этом секторе, пожалуйста, посетите Государственно-частное партнерство в области энергетики и энергетики.

  • Глобальный / неспецифический |
    Global |
    Транспорт |

    Юридический советник по легкорельсовому транспорту TOR

    Техническое задание для юридических консультантов по проекту легкорельсового транспорта — Объем работ

  • Глобальный / неспецифический |
    Global |
    Телекоммуникации и ИКТ |

    ТЗ консультанта по вопросам законодательства в области электросвязи и нормативной реформы

    Юридическое консультирование по осуществлению правовых и нормативных реформ в сфере телекоммуникаций Цель консультации The… подробнее

  • Глобальный / неспецифический |
    Global |
    Телекоммуникации и ИКТ |

    ТЗ консультанта по консультированию по вопросам законодательства в области электросвязи и регуляторной реформы (на французском языке)

    LE CADRE GENERAL D’ASSISTANCE PAR CONSULTANTS POUR L’ELABORATION ET LA MISE EN OEUVRE D’UN CADRE LEGAL APPROPRIE POUR… подробнее

  • Глобальный / неспецифический |
    Global |

    ТЗ консультанта для обзора и комментариев по существующему закону о приватизации

    ТЗ для консультанта по обзору и комментариям по существующему закону о приватизации

  • Глобальный / неспецифический |
    Global |

    Проект ТЗ для Консультации по ГЧП для помощи в разработке блока ГЧП

    Проект ТЗ на консультации по ГЧП

  • Global |

    Руководство по развитию проектов малой энергетики

    Дополнительные материалы по теме можно найти в Соглашениях о закупке электроэнергии (PPA) и Соглашениях о покупке энергии (EPA). Отслеживание… подробнее

  • Глобальный / неспецифический |
    Global |
    Энергия и мощность |

    Круг ведения для консультационных услуг по сделкам для участия частного сектора в развитии новых генерирующих мощностей, соответствующей передачи и развития [LIGNITE FIELD]

    КОНСУЛЬТАЦИОННЫЕ УСЛУГИ ПО СДЕЛКАМ УЧАСТИЯ ЧАСТНОГО СЕКТОРА В РАЗВИТИИ МОЩНОСТЕЙ НОВОГО ПОКОЛЕНИЯ, СВЯЗАННЫХ С… подробнее

  • Глобальный / неспецифический |
    Global |
    Энергия и мощность |

    ТЗ для регулирования электроэнергетического сектора — Техническая помощь — Консультационная компания по коммунальным предприятиям и юридический советник

    Разрешив частному сектору инвестировать в электроэнергетику и управлять ею, Министерство энергетики ожидает… подробнее

  • Глобальный / неспецифический |
    Global |
    Транспорт |

    TOR Обзор концессии на модель платной дороги и переработанный проект

    [КРАТКАЯ ИНФОРМАЦИЯ О ПРОЕКТЕ] 1.Объем работ [СОВЕТНИК] будет исполнять обязанности [ПРАВИТЕЛЬСТВА]. Инструкции будут поступать от… подробнее

  • Глобальный / неспецифический |
    Global |
    Телекоммуникации и ИКТ |

    ТЗ консультанта для консультирования по реформе закона о мобильной связи в сфере телекоммуникаций и подготовке проекта лицензий и пакета предложений

    II. Цель консультации Правительство обращается за технической помощью к международно квалифицированному юристу… подробнее

  • Глобальный / неспецифический |
    Global |
    Водоснабжение и канализация |

    Техническое задание для юридического или другого технического советника по реформе регулирования водных ресурсов (выдержка из Инструментария Всемирного банка / PPIAF по найму и управлению советниками)

    Чтобы узнать больше об этом секторе, посетите Государственно-частное партнерство по водоснабжению и санитарии.

  • Глобальный / неспецифический |
    Global |

    ТЗ консультанта по разработке закона о ГЧП (с учетом существующей правовой среды)

    ТЗ на консультанта по разработке закона о ГЧП (с учетом существующей правовой среды)

  • Глобальный / неспецифический |
    Global |

    ToR for a Project Office Legal Task Manager

    ToR для менеджера юридических задач Project Office

  • Шри-Ланка |
    Южная Азия |
    Энергия и мощность |
    Climate-Smart

    Экологический аудит субпроектов после завершения — Техническое задание консультанта

    Цели проекта включают (а) обеспечение доступа к электроэнергии домашним хозяйствам через домашние солнечные системы и независимые… подробнее

  • Глобальный / неспецифический |
    Global |
    Водоснабжение и канализация |

    Техническое задание на проверку экономических выгод деревенской гидроэнергетики / ветра / биомассы для консультанта (проект RERED)

    Это критический показатель успеха проекта RERED в контексте экономического развития сельских районов.Найти… подробнее

  • Глобальный / неспецифический |
    Global |
    Энергия и мощность |

    ТЗ — Юридические и нормативные консультационные услуги для участия частного сектора в развитии новых генерирующих мощностей

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

  • Глобальный / неспецифический |
    Global |
    Энергия и мощность |

    ТЗ на реформу электроэнергетического сектора — Техническая помощь (выдержка из Инструментария Всемирного банка / PPIAF по найму и управлению советниками)

    Техническая помощь (выдержка из Инструментария Всемирного банка / PPIAF по найму и управлению советниками)

  • Глобальный / неспецифический |
    Global |
    Транспорт |

    ТЗ для предложения по пилотному проекту ГЧП в железнодорожном секторе и проект тендерной документации

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

  • Глобальный / неспецифический |
    Global |
    Телекоммуникации и ИКТ |

    ТЗ консультанта по вопросам реформы законодательства о телекоммуникациях (французский)

    Le Gouvernement [ПЛАТИТ] заявление о возобновлении политики защиты почты и телекоммуникаций.… Подробнее

  • Глобальный / неспецифический |
    Global |
    Водоснабжение и канализация |

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

    Вариант участия частного сектора для улучшения и расширения услуг водоснабжения и канализации в городе.… Еще

  • Глобальный / неспецифический |
    Global |

    ТЗ для консультантов по оказанию помощи в создании подразделения государственно-частного партнерства (ГЧП)

    С самого начала экономического кризиса изменения в экономических профилях, структуре правительства и социальных… подробнее

  • Глобальный / неспецифический |
    Global |
    Энергия и мощность |

    Проект экономического развития сельских районов (RERED)

    Дополнительные материалы по теме можно найти в Фондах электрификации сельских районов.

    • Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *