Спасибо за вашу позицию!
Вы совершенно правы, что ТЗ не стоит превращать в формальность!
И вы вдвойне правы, что нельзя исключать этап тестирования и отладки из процесса разработки сайта. В нашей практике этот этап собирает наибольшее количество вопросов, и позволяет решить «все эти мелочи и детали».
Важно, чтобы на этом этапе не возникло внезапного вопроса о смене CMS, например, или требований к нагрузке… Это не мелкое допиливание, а полная переделка. И именно от таких ситуаций защищает ТЗ!
Ответ в том, что чем больше прописано и подписано заказчиком — тем лучше. Если заказчик в брифе не в состоянии прописать необходимые технологии, то это должен сделать разработчик (обсудив с заказчиком задачи, и выявив потребности). Но потом нужно прописать, что сайт будет разработан на с применением определенного флеш-аякса, нацеленого на такую-то скорость перезагрузки страниц и с такой-то нагрузкой на сервер. И это все прописывается в ТЗ уже вами, и подписывается…
А то выяснится внезапно, что заказчик планировал на своем корпоративном сайте через год сделать отраслевую социальную сеть, и ваш движок к этому как-то не приспособлен… Кто будет виноват? ;)
Вы совершенно правы, что ТЗ не стоит превращать в формальность!
И вы вдвойне правы, что нельзя исключать этап тестирования и отладки из процесса разработки сайта. В нашей практике этот этап собирает наибольшее количество вопросов, и позволяет решить «все эти мелочи и детали».
Важно, чтобы на этом этапе не возникло внезапного вопроса о смене CMS, например, или требований к нагрузке… Это не мелкое допиливание, а полная переделка. И именно от таких ситуаций защищает ТЗ!
А в ваше рабочее ТЗ какие пункты входят?
А то выяснится внезапно, что заказчик планировал на своем корпоративном сайте через год сделать отраслевую социальную сеть, и ваш движок к этому как-то не приспособлен… Кто будет виноват? ;)