Все зависит от организации работы в конкретной конторе и конкретного разработчика, но лично у меня работает следующий подход:
1. Пишем начальное тз, минимальный необходимый перечень.
2. Говнокодим на основание п1 по принципу - "сделать быстро и чтобы работало по тз".
3. Пушим п2 в гит и разворачиваем сайт (или компонент на сайте).
4. Записываем фидбэк о компоненте, что не работает, как хотелось бы чтобы работало итп. Если это не критические замечания (безопасность или что то основное не работает), то откладываем изменения на месяц, квартал или год.
5. При накопление критической массы замечаний в п4 (ну или у Вас просто не осталось задач на настоящий момент) - добавляем рефакторинг п3 в очередь задач.
6. Повторяем 3-6 пункты до бесконечности.
При данном режиме работы решается сразу 3 задачи:
- Не требуется детальное тз на старте, в котором все равно не удастся предвидеть все наперед, соответственно сокращается общее время разработки и его стоимость.
- Сайт или компонент сайта выпускается в релиз очень быстро, а значит решает задачу бизнеса так же быстро.
- Прозрачный и прогнозируемый по срокам и стоимости режим релизов.
Важное уточнение!
Схема с минимальным ТЗ и говнокодом работает лишь с теми заказчиками, которым Вы подробно разъяснили, почему сроки и стоимость ниже, почему за каждую "хотелку" не указанную в тз придется доплачивать, и почему необходим рефакторинг.
Идеальный вариант, донести до заказчика мысль, что проект будет требовать постоянного финансирования (в определенном ежемесячном объеме) на разработку новых или рефакторинг старых компонентов. В таком случае у Вас всегда будет под рукой разработчик, который сможет оперативно и за привычную стоимость решить поставленную задачу, который уже привык работать в таком режиме и ему не нужно лишний раз объяснять одно и то же.
Простой
