Специалисты делятся на ярых сторонников технических заданий, и тех, кто забивает на них огромный болт и делает проекты без лишней писанины. Кто прав?
Без техзадания вполне очевидно, что может возникнуть конфликт мнений между разработчиком, менеджером, дизайнером, клиентом. Каждый одну и ту же задачу может трактовать по-своему и без однозначного описания будет сложно найти компромисс.
Но и детально прописанное ТЗ не спасает от всех бед. Чем больше проект и на более долгий срок описывается функционал, тем больше это превращается в Точку Зрения конкретного человека. Его долгосрочное выдумывание того, как должно быть. Когда же команда начинает разрабатывать описанный достаточно давно участок ТЗ и тем более после запуска проекта в люди, текст ТЗ очень часто кардинально теряет свою актуальность. Особенно это касается релиза MVP стартапов.
Как решить эту проблему? Найти золотую середину: описать проект кратко и минимально достаточно для однозначного трактования общего функционала. Далее разбить проект на итерации и описывать каждую итерацию детальнее по мере приближения. Также очень часто техзадание приходится переписывать после утверждения дизайна интерфейсов. Чтобы этого не было, на многих проектах разумнее написать техническую часть после утверждения дизайна.
