Техническое задание на сайт: подводный камень или спасательный круг?
При обращении заказчика с веб-студию по вопросу разработки сайта, после проведения предварительных переговоров, составляется техническое задание (далее - ТЗ). Чем подробнее будут прописаны в ТЗ нюансы будущего сайта, тем меньше вопросов и непонимания возникнет в отношениях заказчика и разработчика в будущем. Так, ТЗ, подробнейшим образом описывающее будущий продукт, вплоть до каждого "винтика", не дает возможности заказчику в будущем сказать, что что-то работает не так как нужно, ибо все прописано в ТЗ.
С другой стороны, ТЗ, составленное разработчиком в общих фразах со слов не имевшего опыта в области разработки сайтов заказчика, позволяет недобросовестному разработчику создав на обе ноги хромающий прототип сайта сказать, что большее не было прописано в ТЗ.
Итак, чем же все-таки является ТЗ: спасательным кругом обеих сторон в решении споров по поводу созданного продукта, либо подводным камнем в отношениях неопытного заказчика с недобросовестным разработчиком? Отсюда вопрос: кто составляет ТЗ, и кому оно больше надо?
Во-первых, ТЗ нужно для понимания заказчиком что же ему всё-таки нужно
Во-вторых, ТЗ может меняться в ходе выполнения
В-третьих, идеальный вариант - ориентироваться исполнителю на основную идею в рамках бюджета. Но так не каждый и не с каждым может.
А если заказчик знает, что на форуме ему нужен WYSIWYG-редактор в формах подачи комментариев. В ТЗ прописано коротко, например, "форма подачи комментария на форуме выполнена в виде WYSIWYG-редактора". Как в случае такой размытой формулировки на практике определяется его функционал? Ведь в головах у заказчика и исполнителя WYSIWYG-редактор существует в виде двух совершенно разных образов. И тут-то и возникает вопрос заказчика: "а где в редакторе автоматическая очистка форматирования вставляемого текста", на который появляется ответ разработчика: "это не прописано в ТЗ, надо бы доплатить за усовершенствование".
