Тз пример оформления на программу

Ориентировочная структура ТЗ на создание сайта/веб-приложения

24.12.2020 • Время чтения 7 Минут • Разработка

1. Главная
2. Блог
3. Разработка
4. Образец технического задания на разработку сайта

Техническое задание на разработку сайта/веб-приложения

Аннотация

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

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

1. Цели создания сайта

Здесь приводится описание основных целей и задач проекта.

2. Целевая аудитория

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

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

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

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

3.2. Ролевая модель

Описание основных ролей, их возможностей и полномочий

Пример оформления ТЗ на тестовое продвижение

Таблица 1 – Ролевая модель

• Взаимодействие с публичной частью сайта
• Регистрация

• Взаимодействие с публичной частью сайта
• Авторизация
• Взаимодействие с личным кабинетом пользователя

3.3. Функциональные требования к публичной части

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

1. Просмотр каталога товаров.
2. Добавление товара в корзину.
3. Заказ обратного звонка.
4. Регистрация.
5. и т.д.

Для каждого функционального требования также должно быть конкретизированы детали, например, какие сведения должен указать пользователь при регистрации: Имя, телефон, email и т.д.

3.4. Функциональные требования к личному кабинету клиента

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

3.5. Функциональные требования к панели управления (администрирования)

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

3.6. Требования к структуре сайта

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

3.6.1. Структура публичной части сайта

Структура разделов публичной части сайта приведена на рисунке ниже.

Рисунок 1 – Структура публичной части сайта

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

• Просмотр статьи
• Возможность фильтрации статей по дате и теме
• Голосование за статью
• Возможность оставить комментарий (только для авторизованных пользователей)

3.7. Архитектура сайта

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

Фишки для написания ТЗ

Рисунок 2 – Архитектура сайта

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

3.8. Требования к интеграциям

Приводится список систем, с которыми должна быть выполнена интеграция, а также приводятся ссылки на описание API/модулей для интеграции с данными системами или сервисами.

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

Указываются технические требования, такие как:

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

3.10. Требования к дизайну

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

3.11. Требования к контенту

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

3.12. Требования к внутренней SEO оптимизации

В данном разделе приводятся требования по внутренней SEO оптимизации сайта.

3.13. Требования к к системам аналитики

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

3.14. Дополнительные требования

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

3.14.1. Поисковые подсказки

При поиске по товарам/услугам пользователю должны предлагаться варианты поисковых запросов, соответствующих введенному запросу.

Пример поисковых подсказок приведен на рисунке ниже.

Рисунок 3 – Умный поиск

3.14.2. Требования к уведомлениям

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

• Регистрация пользователя;
• Формирование заказа;
• Изменение статуса заказа;
• Отправка обращения через форму обратной связи;
• Начисление бонусов;
• Новые товары.

3.14.3. Требования к управлению изменениями

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

4. Требования к документации

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

5. Стадии и этапы разработки

В данном разделе приведена последовательность этапов реализации проекта (состав этапов зависит от конкретного проекта).

5.1. Прототипирование

На данном этапе необходимо выполнить:

• Создание интуитивно понятного и удобного интерфейса для требуемых типов устройств;
• Проектирование и разработка прототипа;
• Usability-тестирование прототипа.

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

5.2. Создание дизайна

На данном этапе необходимо выполнить:

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

• UX/UI дизайн проекта (макеты основных видов сайта для заданных разрешений).

5.3. Верстка и разработка

На данном этапе необходимо выполнить:

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

• Полнофункциональная версия сайта.

5.4. Тестирование

На данном этапе необходимо выполнить:

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

Выполняются следующие виды тестирования:

• Unit тестирование;
• Интеграционное тестирование;
• UAT тестирование;
• Нагрузочное тестирование;
• Тестирование безопасности.

• Работоспособный сайт(веб-приложение), прошедший испытания и готовый к эксплуатации.

5.5. Документирование

На данном этапе необходимо выполнить:

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

• Программная и эксплуатационная документация.

5.6. Обучение

На данном этапе необходимо выполнить:

• Обучения персонала Заказчика работе и администрированию сайта.

• Обученный персонал Заказчика.

Источник: uncore.ru

Как грамотно составить ТЗ для программиста

193

• 1. Назначение, цели ТЗ
• 2. Общие рекомендации по написанию ТЗ
• 3. Общая структура ТЗ. От абстракции к конкретике

Назначение, цели ТЗ

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

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

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

Общие рекомендации по написанию ТЗ

• Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
• Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
• В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
• Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
• Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
• Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

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

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

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

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

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

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

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

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

• Поле «Ваш имя»;
• Поле «Ваш е-mail»;
• Поле «Ваш вопрос»;
• Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.

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

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

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

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

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

Подписаться на рассылку

• HTTP-заголовки, которые влияют на SEO Скорее всего, вы знаете, что при открытии страницы любого сайта происходят действия на сервере, которые не видны пользователям. Однако эти данные обрабатывают поисковые системы. И.
• Детальное руководство по файлу Sitemap В этом путеводителе мы рассмотрим следующие вопросы: Что такое Sitemap Для чего нужна карта сайта HTML- VS XML-карта сайта Другие форматы Sitemap Требования Google и.
• ТЗ на разработку сайта. Коротко о главном Несмотря на то, что обычно идея создать сайт приходит одному человеку, на деле создание сайта — это коллективное творчество. В данной статье рассмотрим принципы создания.
• Как оптимизировать страницы пагинации на сайте Настройка SEO пагинации Рекомендации поисковиков Актуальные способы настройки пагинации Настройка каноникала на первую страницу Настройка каноникала каждой из страниц на себя Оптимизация каждой страницы пагинации.
• Технические ошибки, которые допускают оптимизаторы Небольшие заметки, рассмотренные в статье, помогут вам улучшить свой сайт. Мы показываем примеры технических ошибок владельцев ресурсов/оптимизаторов и варианты их исправления, рассказываем, как лучше использовать.

Источник: siteclinic.ru

Как написать техническое задание: правила и требования

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

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

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

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

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

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

Зачем составлять техническое задание

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

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

Польза технического задания для заказчика:

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

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

На каком этапе составлять ТЗ

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

• исследования
• SEO-проектирования
• проектирования интерфейса
• подготовки контента
• разработки дизайн-концепции

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

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

Исполнитель

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

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

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

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

Представим наглядно, как это будет выглядеть в ТЗ.

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

Заказчик

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

Совместная работа

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

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

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

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

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

Точность

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

Детальное описание

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

Пример описания элемента главной страницы из ТЗ по одному из наших проектов:

Оформление

На изображении ниже — часть содержания ТЗ по одному из наших проектов. Документ оформлен в Google Docs, навигация по нему реализована через заголовки.

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

Примеры

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

Примеры могут быть и текстовые. Если вам понравился tone of voice какого-либо блога, прикрепите его как пример. Ценными будут и антипримеры в духе «как делать не надо».

Объем

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

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

Что включает в себя техническое задание

Сложные термины

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

Пример описания терминов из ТЗ по одному из наших проектов:

Общие положения

Здесь надо кратко и конкретно рассказать о компании, ее продукте или услуге:

• название
• девиз, если есть
• направление деятельности
• история компании
• услуги и/или продукция по категориям
• УТП
• достижения компании
• ссылка на сайт, если есть
• ссылки на соцсети
• партнеры
• конкуренты и их сайты

Назначение и цели создания сайта

Исполнительная команда должна знать ЦА и род деятельности компании, чтобы понимать, для кого и зачем они разрабатывают сайт.

Цели создания сайта:

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

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

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

Основные целевые действия пользователя на сайте:

1. Совершить покупку
2. Оставить заявку на звонок/выезд специалиста
3. Подписаться на рассылку
4. Связаться с менеджером
5. Запросить каталог товаров

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

1. Какое действие клиент совершает на сайте?
2. Какой ответ сайт дает на это действие?
3. Какой конечный результат всей цепочки?

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

Пример описания сценариев функции «Поиск» из ТЗ по одному из наших проектов:

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

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

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

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

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

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

Примеры основных разделов:

• главная;
• о компании;
• кейсы;
• каталог;
• контакты;

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

Языковые версии сайта

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

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

Описание прототипов каждой уникальной страницы

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

Например, так выглядит прототип страницы, который мы создали для сайта курорта «Яровое».

Навигация по сайту

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

Навигация бывает нескольких видов:

1. Основная. Ссылки из основного меню или с главной страницы.
2. Глобальная. Линки, доступные с любой страницы.
3. Языковая. Переключает языковые версии сайта.
4. Рекламная. Кликабельные рекламные блоки.
5. Тематическая. Ссылки на страницы с похожей тематикой.
6. Поисковая. Ввод информации в строку поиска.

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

Несколько вариантов улучшения навигации по сайту:

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

Пример навигации по разделам на сайте «Ярового»:

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

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

Что может понадобиться на сайте:

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

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

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

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

Пример технического требования из ТЗ по одному из наших проектов:

Чем вредит неверно составленное ТЗ?

Очевидный минус непроработанного ТЗ — постоянные правки и доработки во время проекта. За этим следует:

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

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

1. Никаких дедлайнов. Нужно указывать сроки разработки, чтобы у команды и заказчика было понимание о том, как двигается проект и когда он будет завершен.
2. Потерянные данные доступа. У клиента обязательно должны остаться данные для доступа на сайт. Они пригодятся, если на сайте что-то пойдет не так.
3. «Пусть разработчик разберется». Каким бы прокачанным не был специалист, лучше не отдавать ему создание проекта «на свой вкус» — клиенту может просто не понравиться результат. Лучше обсуждать все заранее.

Вывод

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

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

Источник: atwinta.ru