Большинство проблем в разработке начинается не на этапе дизайна, верстки или интеграций. Они зарождаются намного раньше — в момент, когда требования описаны туманно. Вроде бы все обсудили, архитектор кивает, менеджер уверяет, что понял задачу, вы довольны… а через месяц вы смотрите на прототип и понимаете: это не то. Вообще не то. Причина проста. Требования были сформулированы не конкретно. И команда услышала ровно то, что услышала — каждый по-своему. Чтобы этого не происходило, ТЗ должно быть ясным и измеримым...

«Нам нужен сайт как у конкурентов, только лучше» — это не техническое задание. Это приглашение к недопониманию, затянутым срокам и переделкам за дополнительные деньги. ТЗ — не бюрократический документ, который нужен студии для отчётности. Это договорённость на берегу: что именно делаем, для кого, как это должно работать и как мы поймём, что результат достигнут. Хорошее ТЗ защищает вас от ситуации, когда студия сдаёт «всё по договору», а вы смотрите на сайт и не понимаете, как это вообще должно продавать...