Проблема коммуникации с заказчиком всегда в том что, всегда есть вероятность быть непонятым. Особенно что касается разработки сайтов. Например клиенту нужен второй «Вконтакте», но обьяснить это смог так что на выходе получился форум меломанов.
Ознакомившись с этой статьей, вы поймете, что, как и зачем нужно писать в техническом задании. Узнаете, что позволит получить толковое ТЗ.
Техническое задание — это документ с требованиями к сайту. Когда ТЗ составлено максимально четко и подробно, разработчикам будут понятны все условия и задачи по проекту.
А значит результат понравится обеим заинтересованным сторонам в проекте (заказчик-исполнитель). Вот почему необходимо грамотно составленное ТЗ.
1. Заказчик:
2. Исполнитель:
Грамотное ТЗ составляет исполнитель. Проект-менеджер или разработчик разбираются в создании сайтов больше владельцев бизнеса, которым этот сайт необходим. Однако клиент все-равно должен принимать живое участие в его создании.
Заказчик:
Клиент может написать свой вариант ТЗ. Это может лечь в основу профессионального конечного технического задания.
Миссия техзадания – максимально четко изложить все детали будущего проекта. Никаких прилагательных, которые не несут смысловой нагрузки или слишком общие для понимания. Например, такие слова как красивый и современный можно истолковать в силу собственного вкуса по-разному.
То же самое относится и к невнятным формулировкам. Например:
Обязательно проверяйте текст: в нем не должно быть неоднозначных формулировок. В противном случае ТЗ придется переписать. Все мысли следует сформулировать четко и точно. Например:
У всех участников проекта должно быть понимание того, чем занимается компания и кто целевая аудитория. Следует прописать это в начале ТЗ. А так же цель и общий функционал проекта.
Техническое задание необходимо понимать всем для кого оно создается. Будет лучше если сложные термины будут иметь сноски с толкованием.
К примеру вы месяц разрабатывали сайт, согласуя каждый этап с заказчиком. И вот на видеоконференции, показывая админку вы слышите возмущение заказчика: «А почему это Вордпресс? Я хотел ОпенКарт!»
Чтобы исключить подобные истории необходимо изначально обозначить инструменты, движки и библиотеки, а также требования к хостингу.
Готовый сайт должен работать в любом браузере и на всех устройствах. И при этом корректно отображаться. Это указывается в ТЗ.
Также нужно указать требования к следующим параметрам:
Первым делом создается и согласовывается структура сайта, именно этот скелет будет основой будущего дизайна и функционала.
Сначала нужно выяснить, что желает увидеть клиент. Собрать команду (разработчики, SEO-специалисты, маркетологи, главный редактор) и решить, какие именно страницы нужны на сайте и как их связать между собой.
Структуру можно показать списком или нарисовать в виде блок-схемы. Но она и является фундаментом будущего сайта. Сначала составляется скелет, потом на его основе делается прототип, и уже потом дизайн.
Заказчику нужно понимать назначение каждой страницы и ее элементов. Для демонстрации есть два способа.
1. Прототип. Самый наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прикладывает их к ТЗ. Заказчик увидит, как будет выглядеть интерфейс сайта, и сможет сказать, что ему понравилось, а что лучше изменить.
2. Перечисление элементов — ленивая альтернатива прототипу. Если вы выбираете этот вариант, нужно лишь составить список блоков, которые предполагается разместить на странице.
Если интерфейс будущего сайта будет нестандартным для иллюстрации поведения пользователя на сайте лучше составить простую схему сценария: действие пользователя - ответное действие сайта - результат. В случае стандартного функционала, сценарий прописывать нет смысла.
Некоторые создают сайты сразу с контентом (при его наличии у клиента) Другие ставят рыбу – стандартные текстовые заглушки. Кто-то предлагает написать тексты их специалистом за отдельную плату. Нужно согласовать какой именно сценарий подойдет заказчику и зафиксировать в ТЗ.
Объективных критериев оценки дизайна сайта нет. Если заказчик определился с цветовой палитрой это фиксируется ТЗ. При наличии брендбука (либо просто логотипа с фирменными цветами и шрифтами) прописывается и это.
Одинаковых техзаданий нет: для каждого проекта пишется уникальное ТЗ. Поэтому толковое техническое задание должно иметь: