>В этом случае ТЗ необходимо для того, чтобы договориться о том, на какие параметры можно забить для получения этой самой экстремальной дешевизны.
Не забывайте, что ТЗ само по себе стоит денег.
>>3) Заказчик не может сформулировать требования потому что сам пока не понимает что ему надо.
>
>Распространена практика, когда ТЗ пишет разработчик на основании общих пожеланий заказчика. Потом идет согласование конкретных положений и подписание документа.
А потом заказчик говорит "я трактовал это совсем не так" или "я вашего птичьего языка не понимаю и просто доверился Вам". Дело в том, что многие заказчики могут понять "то это или не то чьл я хочу" только "потрогав руками" а для этого нужен прототип или хотя бы макет. Вот вместо бумажного ТЗ и занимаются прототипированием. Просто метод сбора требований такой, побочным результато мимеющий готовый продукт минуя стадию составления "бумажного" ТЗ.
>Но без ТЗ разработано будет непонятно что, в результате в зависимости от того, кто лучше обладает даром "убеждения", или заказчик заплатит за то, что его не устраивает
Еще бывает, что разрабочик опытный/умный, а заказчик - не очень и разработчик лучше понимает, что будет нужно заказчику в конечном итоге.
> , или разработчик ничего не получит за свои труды.
Если разработчик состоит в штате заказчика - за труды он получает. Если не состоит, но контракт оплачивается по принципу "время + материалы", например почасовая оплата, то тоже получает.
>>В этом случае ТЗ необходимо для того, чтобы договориться о том, на какие параметры можно забить для получения этой самой экстремальной дешевизны.
>
>Не забывайте, что ТЗ само по себе стоит денег.
Как правило это относительно дешевый этап проекта.Финансовые риски на нем меньше, чем на остальных.
>А потом заказчик говорит "я трактовал это совсем не так" или "я вашего птичьего языка не понимаю и просто доверился Вам".
Это говорит лишь о том, что ТЗ плохо составлено. Правда как вариант о том, что Заказчик его толком не читал.
Но нормальный подряжчик, как и заказчик, включают ТЗ в договор. В этом случае разобраться кто и что кому должен гораздо проще.
>Дело в том, что многие заказчики могут понять "то это или не то чьл я хочу" только "потрогав руками" а для этого нужен прототип или хотя бы макет.
Прототип стоит как правило заметно дороже ТЗ, если речь не идет о доработки готовой системы под нового заказчика.
>Еще бывает, что разрабочик опытный/умный, а заказчик - не очень и разработчик лучше понимает, что будет нужно заказчику в конечном итоге.
Это очень редко, просто потому что заказчик лучше знает свою область работы.