Тех. задание - это электронный документ [doc, txt, odt], который упрощает разработку, помогает прокалькулировать стоимость и сроки выполняемых работ. Основное требование к ТЗ: простота и структурность.
Простота при формировании задач, заключается в описании задачи максимально детализировано простым языком:
Программист:
Вам нужно создать абстракцию класса для реализации бизнес-логики по паттерну MVC с использованием технологии ajax ?
Вы:
Нет, мне нужно ещё одну вот ТАКУЮ страничку, что бы ТАМ, все работало как ТУТ но без березагрузки страницы
...полторачасовой диалог...
Что в итоге написано в ТЗ:
п. 2.7 Реализовать дополнительную страницу, для отображения «Новинки» по аналогии функциональности со страницей «Акция», с условием отображения блоков товаров по последним добавленним в магазин, переключение между страницами (pagination) сделать по технологии ajax (без перезагрузки страницы)
Само техническое задание для шоп-мейкера разбивается на несколько разделов, где каждый раздел, отдельно прорабатываться, а именно:
1. Техническое задание для программиста
В данном разделе необходимо указать основные требования для будущего шопа, функциональные фишки, особенности. На этом этапе, кодер реализовывает архитектуру будущего шопа или подбирает оптимальную CMS именно после формирования пожеланий в данном разделе, так же, после понимания основного каркаса на ядре магазина, наращивает функциональность как раз описанную в данном разделе
2. ТЗ для дизайнера
Внешний вид сайта, его юзабилити не только на домашнем PC но и на мобильных и планшетах, оботражение элементов, простота, быстрота, чистота разметки - вот что нужно описать именно в этом разделе, что и как реализовать в прототипе, как сделать интуитивно понятным размещение основных целей и призывов к действие, а именно - закрытияю конверсии, цветовая палитра, и удобство - все описываем тут, что относиться к визуальному виду (фантику) вашего шопа (конфетки)
3. Тех. задание для семантиста (сеошника)
Перед наполнением магазина товарами\разделами, моя команда всегда предлагает дополнительно проконсультироваться с семантистом - заказчика, так как грамотная структура иерархии в магазине - залог быстрого и успешного продвижения и удержания в ТОП-е, подбор и создание метаданных, снипетов, микроразметки, кластеризация запросов, создание вложенности, перелинковка - вот что надо описывать в этом разделе, для успешной раскрутки шопа в поисковиках
Кто должен создавать ТЗ ?
Очень сложный вопрос, ответ на который не одно поколение шоп-мейкеров пробует ответить. С одной стороны, у мастера шоп-мейкера есть немалый опыт по составлению ТЗ, с которым ему привычно работать и он может его составить, в процессе общения с заказчиком. С другой стороны - составление ТЗ - не входит в стоимость услуг и обычно находится на сайте в виде «БРИФ», который можно скачать и заполнить, по типу анкеты, но в большинстве случаев, если деловой человек
понимает какой бизнес он хочет представить в сети, как должны выглядеть его товары на витрине он-лайн магазина, какие службы доставки и какие платёжные шлюзы должны быть установлены - знает он сам, описывает по своему видению и потом можно составить, или уточнить текущее, полное тех. задание вместе с шоп-мейкером.
Моё экспертное мнение:
ТЗ - это документ, в котором заинтересованы обе стороны: исполнитель - что бы понять сложность выполняемых задач, указать сроки выполнения и назвать сумму за проект, заказчик - что бы понимать, что будет проделано, срок дедлайна, понять структуру своего магазина.
Если остались какие то вопросы не открыты, или информация была недостаточно расписана, прошу к комментариям, с радостью уточню и опишу все моменты с ТЗ и примерами, с Вами был ALarik, дабра и любви.
P.S. По многочисленным запросам от учеников, выкладываю такое уточнение как: «Детализированное ТЗ» - которое может быть в многих ситуациях своеобразной ловушкой для начинающего шоп-мейкера, составленное нехорошими человеками, о которых расскажу чуть позже, а по сути детализированного ТЗ - то сразу прошу обращать внимание на все пункты и любые детали, не просмотрев или упустив и не выполнив которые, заказчик может отказаться от оплаты услуг, так что просьба детально перечитывать и уточнять все непонятные предложения по реализации, что бы не оказаться у разбитого кода...