Техническое задание на сайт: подводный камень или спасательный круг?
При обращении заказчика с веб-студию по вопросу разработки сайта, после проведения предварительных переговоров, составляется техническое задание (далее - ТЗ). Чем подробнее будут прописаны в ТЗ нюансы будущего сайта, тем меньше вопросов и непонимания возникнет в отношениях заказчика и разработчика в будущем. Так, ТЗ, подробнейшим образом описывающее будущий продукт, вплоть до каждого "винтика", не дает возможности заказчику в будущем сказать, что что-то работает не так как нужно, ибо все прописано в ТЗ.
С другой стороны, ТЗ, составленное разработчиком в общих фразах со слов не имевшего опыта в области разработки сайтов заказчика, позволяет недобросовестному разработчику создав на обе ноги хромающий прототип сайта сказать, что большее не было прописано в ТЗ.
Итак, чем же все-таки является ТЗ: спасательным кругом обеих сторон в решении споров по поводу созданного продукта, либо подводным камнем в отношениях неопытного заказчика с недобросовестным разработчиком? Отсюда вопрос: кто составляет ТЗ, и кому оно больше надо?
Во-первых, ТЗ нужно для понимания заказчиком что же ему всё-таки нужно
Во-вторых, ТЗ может меняться в ходе выполнения
В-третьих, идеальный вариант - ориентироваться исполнителю на основную идею в рамках бюджета. Но так не каждый и не с каждым может.
А если заказчик знает, что на форуме ему нужен WYSIWYG-редактор в формах подачи комментариев. В ТЗ прописано коротко, например, "форма подачи комментария на форуме выполнена в виде WYSIWYG-редактора". Как в случае такой размытой формулировки на практике определяется его функционал? Ведь в головах у заказчика и исполнителя WYSIWYG-редактор существует в виде двух совершенно разных образов. И тут-то и возникает вопрос заказчика: "а где в редакторе автоматическая очистка форматирования вставляемого текста", на который появляется ответ разработчика: "это не прописано в ТЗ, надо бы доплатить за усовершенствование".
0. ТЗ = ["...нужен сайт, более-менее, как там вот... и добавить...."]
1. Список работ от исполнителя по ТЗ (+трудозатраты)
2. Этапность
3. Составление ТЗ
4. Максимальная глубина уровней вложений подразделов в ТЗ: DEEP
5. DEEP>3: ТЗ+1 = [текст раздела одного из верхних уровней ТЗ], GOTO п.1
PS: Вообще, ТЗ для того, чтобы приносить взаимопонимание, а не конфликты...
Заказчик сам, как правило, не способен составить грамотное ТЗ. ТЗ должен составлять технически грамотный специалист, полностью учитывая все пожелания заказчика и возможности разработчика. Если ТЗ составлено правильно(и добросовестно выполняется), то впоследствии никаких вопросов не возникнет. А вот по поводу отдельной платы за доработки: клиент не всегда точно может представить себе, что он хочет, потому плату необходимо требовать только за реально крупные переделки. Если, конечно, исполнитель хочет по итогу остаться в индустрии.
@IoannGrozny То есть, например, в ТЗ заложена реализация рейтинговой системы. Рейтинг начисляется за разные действия. По результатам недели набравшие больше всего за определенное действие (а действий много) пользователи награждаются. Так вот, по факту рейтинг начисляется, награждение победителей производится через админку вручную. Так, вот за то чтобы показать в админке историю рейтингов по пользователям (иначе не поймешь кого и за что награждать) разработчик просит денег, мол не прописано в ТЗ. Это же абсурд, правильно я понимаю?
Простой
