Составить тз


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

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

Для чего нужно техническое задание?

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

1. Экономия времени на оценку

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


2. Экономия денег

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

Плохо: На сайте должна быть рассылка на новости.

Хорошо: На сайте предусмотрена подписка на новости. Для этого слева под каталогом услуг размещается пользовательская форма для сбора e-mail.

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

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

Рассылка должна работать в ручном и автоматическом режимах (по дням, часам и т. д.).

0 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

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

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


3. Понимание цели проекта

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

Существует мнение, что требования к сайту можно выразить простой фразой: «Сделайте мне сайт как www.site_name.ru, в нем все устраивает, нравится дизайн, меню чуть изменим». Если студия действительно заинтересованы в качественной разработке, она попросит вас расширить и детализировать требования. Хорошие подрядчики не делают «такие же» сайты.

При составлении ТЗ важно четко понять и описать цель проекта, ради которой он создается, например:

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

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

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

Хорошее техническое задание должно содержать следующие разделы:

  • карта сайта;
  • технические требования;
  • требования к кроссбраузерности;
  • требования к CMS;
  • описание типовых разделов сайта.

1. Карта сайта

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

Карту сайта можно представить в виде иерархического списка:

  • Компания
    • О нас
    • Вакансии
    • Лицензии
  • Каталог
    • Вазы
      • Хрустальные вазы
      • Пластмассовые вазы
    • Бокалы
  • Бренды
  • Доставка и оплата
  • Дилерам
  • Контакты

Или в виде дерева:

1 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

Оба варианта равнозначны.

2. Технические требования

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

Пример требований:

  • платформа: Windows или *NIX;
  • язык разработки: PHP (версия 5.3 +);
  • web-сервер: Apache (версия 1.3 +);
  • сервер БД: MySQL (версия 5.0 +);
  • частота процессора: не менее 1 GHz;
  • оперативная память: не менее 384 Мб +;
  • место на диске: не менее3 Gb;
  • подключение к интернету с минимальной пропускной способностью канала 10 Мбит.

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

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

3. Требования к кроссбраузерности

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

Сайт должен корректно отображаться в браузерах:

  • Internet Explorer 8 и выше;
  • Mozilla Firefox 30 и выше;
  • Opera 10 и выше;
  • Google Chrome 35 и выше;
  • Safari 4 и выше.

Ниже приведены свежие >данные по статистике использования браузеров (по данным openstat.ru)

2 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg


Для взаимопонимания с техническими специалистами рекомендуем добавлять в этот пункт следующую фразу:

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

К тому же не стоит уделять много внимания устаревшим и неподдерживаемым версиям браузеров. Например, IE 6,по данным Open Stat, используют менее 1% пользователей, и его добавление в требования, возможно, будет плюсом, но увеличит время на верстку и тестирование, и, как следствие, повысит конечную стоимость разработки.

4. Требования к CMS

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

К слову, наиболее популярные CMS – это:

  • WordPress,
  • Joomla,
  • 1C-Битрикс,
  • DataLife Engine,
  • Drupal,
  • uCoz,
  • MODx,
  • NetCat,
  • UMI.CMS.

Но само собой, это не конечный перечень.

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


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

Редактирование содержимого разделов сайта должно осуществляться с помощью административного веб-интерфейса, доступного по логину/паролю и без применения навыков программирования. Пример административного раздела в 1С-Битрикс представлен на рисунке ниже.

3 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

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

4 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

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


5 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

В CMS должен быть предусмотрен механизм экспорта/импорта данных в универсальном формате. Сюда могут быть отнесены данные пользовательских форм, структура каталога, информационные свойства товаров, e-mail адреса пользователей сайта и т.д.

6 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

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

7 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

И так далее.

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

К примеру, в CMS «Битрикс» разграничение прав доступа уже реализовано, и не нужно специально указывать этот пункт в ТЗ.

4. Общие требования

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

Примерное содержание данного раздела:


    1. На всех страницах сайта присутствует навигационная цепочка (меню «хлебные крошки»).

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

    3. На всех пользовательских формах должны быть настроены капчи для проверки на автозаполнение.

    8 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

    4. Все данные форм должны храниться в отдельных инфоблоках.

    5. Все изображения должны содержать альтернативный текст и названия. Для защиты изображений от копирования на сторонних ресурсах должен быть реализован механизм вотермарок (водяных знаков).

    9 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg


    6. Все длительные процессы обработки информации должны быть визуализированы. На примере preloader’а.

    10 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

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

    8. Прочее.

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

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

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

5. Описание страниц и разделов

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


11 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

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

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

Пример прототипа в разработке представлен на рисунке ниже.

12 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

Пример описания главной страницы интернет-магазина по продаже спортивного питания из разработанного ТЗ представлен ниже.

13 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

Главная страница представляет собой динамическую страницу со следующей структурой:

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

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

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

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

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

Элементы блока «Хиты продаж»:

  • заголовок блока;
  • ссылка «все хиты»;
  • изображение малое (размер на усмотрение дизайнера);
  • название товара;
  • бренд;
  • цена;
  • кнопка «Купить».

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

14 - Как составить четкое ТЗ и сделать так, чтобы вас все поняли.jpg

Ссылка «Все хиты» — переход на страницу с подборкой всех хитов.

Рейтинг фитнес-центров представляет собой блок с краткой информацией о фитнес-центре. Элементы блока:

  • название;
  • адрес;
  • изображение малое (размер на усмотрение дизайнера);
  • заголовок блока;
  • ссылка «Весь рейтинг»;
  • управляющие элементы блока.

По клику на изображение фитнес-центра реализован переход на страницу с полным списком фитнес-центров.

www.utlab.ru

Что такое техническое задание

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

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

  • разработке приложений;
  • проектировании дома;
  • написании текстов и другие.

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

Это интересно: Как составить коммерческое предложение

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

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

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

Как составить техническое задание

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

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

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

Опишите сайт

Расскажите, какой тип сайта нужен, кем он будет использоваться, для чего он вообще создается. Например, напишите, что вам нужен интернет-магазин, лендинг для продажи товара или сайт-визитка с 10 страницами. Укажите ориентировочное количество страниц, если не знаете точного числа.

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

Расскажите о структуре

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

  • Схемой
  • Таблицей
  • Списком

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

Структура сайта
Пример простейшей структуры в виде блок-схемы

Читайте также: Как составить продающую структуру лендинга

Опишите, что будет на каждой из страниц

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

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

Прототип сайта
Пример прототипа главной страницы сайта: все просто, удобно, понятно

Выдвините требования к дизайну

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

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

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

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

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими — нет. Опишите отдельным блоком:

  • На какой CMS должен находиться сайт — Вордпресс, Джумла, Модэкс и так далее
  • Какой язык программирования можно использовать — PHP, JavaScript, HTML, другие
  • На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
  • Какую программную платформу можно использовать — .NET, OpenGL, DirectX
  • И так далее

Если клиент не понимает ничего в используемых терминах — объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне .ru от домена в зоне .com. Вместе составьте требования так, чтобы они устроили клиента.

Это интересно: 10 лучших хостингов для сайта

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

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

  • Приемлемую для вас скорость загрузки сайтов или стандартное значение — 1–5 секунд
  • Кроссбраузерность — распишите, в каких браузерах сайт должен открываться
  • Адаптивность — укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
  • Устойчивость к нагрузкам — сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
  • Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Сценарий работы сайта
Пример простейшего сценария работы сайта

Уточните, кто занимается контентом.

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

  • Уникальности текста — не меньше 95% по Адвего, Текст.ру, Контент.Вотч
  • Тошноте (заспамленности)— не более 10% по Адвего иди 65% по Текст.ру
  • Баллам по Главреду — не менее 6,5 или 7 баллов

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

Укажите сроки

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

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

  • Цели и задачи — о том, для чего вообще вы создали ТЗ, что хотите сделать с продуктом
  • Каким должен быть продукт — описание в общих чертах
  • Технические требования — площадь дома, объем текста, функционал приложения и так далее
  • Сроки — они важны, чтобы исключить споры.

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования — ниже.

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

Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:

  • Линк
  • Название статьи
  • Лид-абзац

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

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

Сроки: до 15.09.2018.

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

internet-marketings.ru

Из чего состоит ТЗ?

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

Общие сведения (описание)

Здесь указываются:

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

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

  • Подготовительный этап;
  • Проработка концепции сайта;
  • Проектирование;
  • Создание дизайн-макета;
  • Разработка дизайна страниц;
  • Вёрстка;
  • Программирование;
  • Наполнение контентом;
  • SEO-оптимизация;
  • Тестирование;
  • Запуск.

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

Назначение и цели

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

Назначение сайта. Каких целей созданием сайта необходимо достичь? Для чего он нужен, какие задачи решает?

  • Реклама и привлечение новых клиентов;
  • Поддержка заказчиков и партнёров;
  • Демонстрация выполненных работ;
  • Ознакомление со списком услуг;
  • Создание и поддержание имиджа компании.

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

Целевая аудитория. Кто будет пользоваться сайтом, для кого он создаётся?

  • Веб-мастера, блогеры;
  • Владельцы интернет-магазинов;
  • Владельцы информационных порталов;
  • Рекламные студии;
  • Представители присутствующих в онлайн-пространстве фирм и компаний.

Требования

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

Тип. К какой категории принадлежит веб-ресурс?

  • Посадочная страница;
  • Сайт-визитка;
  • Корпоративный сайт;
  • Информационный портал;
  • Интернет-магазин.

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

  • Сайт должен быть минималистичным и при этом отражать род деятельности компании.
  • Основные цвета: зелёный и белый, по брендбуку или на усмотрение дизайнера.
  • В оформлении нельзя использовать анимацию, всплывающие окна, Flash-элементы, дизайнерские излишества.
  • Нельзя использовать шрифты с засечками (можно применять стандартные: Verdana, Arial, Tahoma и т. д.). Кегль должен обеспечивать максимальное удобство чтения (12-16 пт.).

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

Языковые требования. Носители какого языка смогут посещать ресурс? Какие языковые версии сайта должны быть?

  • Русский;
  • Английский;
  • Эсперанто.

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

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

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

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

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

Структура и навигация. Какие разделы, подразделы и отдельные страницы будет содержать проект?

  • Главная страница
  • Услуги
  • Копирайтинг
  • Рерайтинг
  • SEO-коперайтинг
  • Корректура
  • Транскрибация
  • Контент-менеджмент
  • Контент-маркетинг
  • Портфолио
  • О нас
  • Контакты

Сделайте и краткое описание каждой страницы, дайте определения. Например, что подразумевается под страницей «Контакты»? Она должна содержать адрес, телефон и электронную почту в текстовом виде? Или там должна присутствовать форма обратной связи? А может, нужно встроить код Яндекс Карт? Или же на странице контактов должно размещаться всё перечисленное, да ещё и ссылки на представительства в социальных сетях?

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

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

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

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

Главная страница. Формулировка задачи может быть в следующем виде.

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

  • Шапка — логотип, название фирмы;
  • Меню навигации;
  • Информация об акциях и скидках;
  • Кнопка заказа;
  • Рекламный текст;
  • Блок с пятью лучшими работами и ссылкой на раздел портфолио;
  • Отзывы клиентов;
  • Штат студии;
  • Блок партнёров компании;
  • Информация о тарифах;
  • Дублирующий блок скидок и кнопка заказа;
  • Карта ссылок;
  • Кнопки социальных сетей.

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

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

Прототип сайта

Сюда же можно поместить схемы (или схему) страниц.

Схематичная структура страниц сайта

Кстати, эти прототипы сделаны с помощью программы Balsamiq Mockups, который довольно прост в освоении.

Описание функциональной части

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

При нажатии кнопки «Заказать» открывается форма заказа с раскрывающимся списком выбора услуги, полями: Имя, Телефон, Комментарий, возможностью прикрепить файл и кнопкой Отправить, нажатие которой приведёт к созданию и отправке письма на e-mail администратора.

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

Если какой-то функционал не описан, то обычно делается так, как это предусмотрено в стандартной модификации CMS.

Заключение

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

www.seostop.ru

В чем разница технического задания и описания объекта госзакупки

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

Напомним, что с 11.01.2018 в правилах описания предмета госзаказа произошли изменения:

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

Делать это будет не обязательно:

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

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

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

Правила составления ТЗ по 44 ФЗ

Самый простой и быстрый способ сформировать техническое задание — образец по ФЗ 44 разработать на основе официального издания Единой системы документации национальных стандартов.

Скачать

Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с каталогом товаров, работ, услуг (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 08.02.2017 № 145.

При наличии описания закупаемой продукции в КТРУ заказчик обязан:

  • описывать объект закупки так, как это предусмотрено КТРУ;
  • включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).

Утвержденными ПП от 05.06.2015 № 555 Правилами предусмотрена обязанность заказчика указывать наименование предмета закупки в процессе обоснования.

Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:

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

Что указать в техническом задании

Содержание ТЗ необходимо основывать на положениях 44-ФЗ, также обязательно соблюдать нормы гражданского, бюджетного и антимонопольного законодательств и отраслевых нормативных актов.

В качестве рекомендации, как составить техническое задание по 44 ФЗ, можно предложить разбить документ на основные разделы:

  • общая информация;
  • информация о закупаемом объекте;
  • требования к поставщикам;
  • условия исполнения контракта;
  • приложения (допускается по усмотрению заказчика).

Этапы составления технического задания

1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.

2. Предоставить полную информацию о заказчике:

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

3. Предусмотреть в информации о закупке сведения:

  • совместная закупка или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
  • централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
  • привлечение экспертов, порядок их работы.

4. Перечислить сведения о госзакупке:

  • способ определения поставщика (ч. 1 ст. 24);
  • обоснование выбранного способа определения поставщика (ч. 5 ст. 24).

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

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

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).

10. Указать источник финансирования.

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

12. Определить условия нормирования госзакупки (ч. 1 ст. 19).

13. Указать наименование и обоснование объекта госзакупки.

14. Максимально точно и детально описать объект госзакупки (ст. 33).

15. Определить экологические особенности закупаемого объекта.

16. Уточнить объем закупаемых товаров, а также периодичность и срок поставки.

17. Определить гарантийный срок и объем предоставляемых гарантий.

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

19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.

20. Определить расходы на эксплуатацию.

21. Определиться, нужны ли монтаж и наладка.

22. Установить порядок поставки и приемки.

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

Образцы техзаданий для товаров, работ, услуг в 2018 году

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

Ниже представлен образец технического задания на поставку товара по 44-ФЗ.

Скачать

Также образец техзадания на выполнение работ по ФЗ-44 вы можете найти в нашем материале о техзадании на проектирование и обслуживание пожарной сигнализации или системы видеонаблюдения.

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

goscontract.info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Правила составления Software Requirements Specification. SRS — следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
  • Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

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

texterra.ru


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.