Мы часто сталкиваемся с тем, что техническое задание написано просто потому, что нужно. В итоге, оно либо написано слишком сложно, либо накладывает ненужные ограничения на проект. Важно также понимать, что техническое задание не дает гарантию отсутствия изменений в процессе разработки проекта. Поэтому, важно составить такое техническое задание, кот…
Комментарий недоступен
У нас был печальный опыт в этом вопросе, как с нашей стороны (отсутствие компетенций), так и со стороны заказчиков (непонимание процессов). В результате, мы хотели найти такое решение, которое бы обезопасило нас и клиента, но не усложняло никому жизнь. Об этом мы и попытались написать.
Две недели писать ТЗ — это пиздец, ребята :)
Если клиент не профи в разработке (а таких 99%), не разбирается в тонкостях ведения проекта и тем более не готов заказывать (что?), то даже самое подробное ТЗ не спасёт вас от фиаско и походов в суд.
К слову о судах, что мешает заложить в доп. соглашение на этап четкое кол-во итераций? А клиенту строго так, красненьким, сообщить, что если он хочет вносить правки, то ему надо хорошенько так подумать и выдать всё единым документом, аргументировано и без противоречия предыдущим этапам. Ну и конечно же, промежуточные акты на этап, что мешает их высылать и требовать подписать?
А про «заказчик должен ощущать, что исполнитель заебался» я вообще не понял. Какой смысл в этом? Показать, что вы лох и нихуя не умеете, что «эта» задача вызвала у вас жёпную боль и реки пота? ИМХО, весьма сомнительная «психологическая-уловка», которая скорее граничит с самодурством.
Клиенту нужен результат, рамки которого описываются в группе специальных документов, совокупно именуемых «техническим заданием». Если итог соответствует задуманному и решает поставленные бизнес-задачи, значит всё «ок», а если клиент хочет «поиграть со шрифтами», то это или отдельной задачей или в рамках этапа доработок (которые обычно оцениваются в 25% от общей стоимости), либо в ущерб сроков.
И мой опыт показывает, что бОльшая часть всех хотелок как-то сразу испаряется :)