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