Техническое задание на разработку сайта – что это и зачем нужно?

— Вы строите дома?

— Да, мы уже давно этим занимаемся и построили много домов

— Отлично, постройте мне дом!

— С радостью, а какой дом вы хотите?

— Ну, обычный. Такой с комнатами и красивый.

— Хорошо, давайте составим с вами проект дома. Я сейчас задам вам некоторые вопросы и на основании ответов сформируем итоговое задание для строительства.

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

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

— Ну причем тут летние домики, мне нужен дом. Обычный в котором можно жить круглый год. Что не понятного я говорю?

— По этажности у вас есть предпочтения?

— Я еще не решил

— По системе отопления что-то планировали?

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

— Ок, а где расположен участок, на котором хотите строить?

— За городом

— Газ там подведен? Электричество?

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

Занавес

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

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

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

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

Оформление и внешний вид

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

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

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

Объем технического задания или сколько вешать в граммах?

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

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

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

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

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

Какие разделы должны быть в техническом задании?

Самым основным выделяют два момента – это внешний вид и функционал.

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

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

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

Что делать если читаешь техзадание, но ни слова в нем не понимаешь?

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

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

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

Все по ГОСТу или дайте мне больше и больше стандартов!

Как ни странно, но существуют ГОСТы как писать техническое задание на создание автоматизированной системы (ГОСТ 34 и ГОСТ 19). Эти стандарты, кроме всего прочего, определяют состав документа по разделам, которые необходимо написать.

Ориентируясь на ГОСТ 34 должна быть, следующая структура документа:

1. Общие сведения

2. Назначение и цели создания (развития) системы

3. Характеристика объектов автоматизации

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

5. Состав и содержание работ по созданию системы

6. Порядок контроля и приемки системы

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

9. Источники разработки

Этот стандарт утвержден в 1990 году. Его более ранний собрат ГОСТ 19 от 1980 года описывает следующие разделы техзадания:

1. Введение;

2. Основания для разработки;

3. Назначение разработки;

4. Требования к программе или программному изделию;

5. Требования к программной документации;

6. Технико-экономические показатели;

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

8. Порядок контроля и приемки;

9. Приложения.

Стоит ли следовать данным ГОСТам? Если у вас не госзаказ, тогда потребности в этом нет. Однако, если ваш проект имеет более-менее крупный масштаб (например, планируете создавать онлайн сервис), то общие идеи и некоторые элементы по структуре можно с пользой оттуда позаимствовать.

Резюме

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