История изменений

Если проект сложнее hello world, то нет таких ресурсов, иначе всех менеджеров уже давно бы заменили приложениями)

Дело в следующем.

Обычно проект развивается от прототипа до конечного продукта поэтапно, т.е. разбит на «стадии проектирования». Количество и качество результата таких стадий зависит от выбора методики проектирования.

Т.е. продукт начинается с самого простого макета, м.б. даже эскиза карандашом на листе бумаге. Когда понимание на этапе эскиза достигнуто переходят к рабочему проекту и тд. В противном случае все скатиться в диалог слепого с глухим(

В этом смысле, ТЗ как раз тот документ, который формализует взаимоотношения заказчика и исполнителя с т.з. стадий проектирования, т.е. то, кто, когда, что, кому и в каком виде должен предоставить.

ТЗ, вопреки устоявшемуся мнению, как правило не содержит детальных требований к функциональности, ссылаясь в этой части на другие документы (ПЗ, ТУ, РП, ПИ и тп)

Т.е. потенциального исполнителя должно бы волновать, как закрыть текущий этап и открыть следующий. А не как сделать все и сразу, переоценивая при этом свои возможности уложиться в сроки - самая распространенная ошибка «фрилансеров».

Еще, пмсм, стоит разделять фрилансеров и работников на удалении. Первые зарабатывают тем, что выполняют быстро и качественно _типовую_ работу, которая д.б. предельно формализована, именно поэтому они могут сразу оценить сроки и цену своего участия в проекте. Если работа не типовая или не формализована в достаточной мере - нужны спецы на удалении с повременной оплатой, ну и чем меньше «удаление» - тем лучше)

Если проект сложнее hello world, то нет таких ресурсов, иначе всех менеджеров уже давно бы заменили приложениями)

Дело в следующем.

Обычно проект развивается от прототипа до конечного продукта поэтапно, т.е. разбит на «стадии проектирования». Количество и качество результата таких стадий зависит от выбора методики проектирования.

Т.е. продукт начинается с самого простого макета, м.б. даже эскиза карандашом на листе бумаге. Когда понимание на этапе эскиза достигнуто переходят к рабочему проекту и тд. В противном случае все скатиться в диалог слепого с глухим(

В этом смысле, ТЗ как раз тот документ, который формализует взаимоотношения заказчика и исполнителя с т.з. стадий проектирования, т.е. то, кто, когда, что, кому и в каком виде должен предоставить.

ТЗ, вопреки устоявшемуся мнению, как правило не содержит детальных требований к функциональности, ссылаясь в этой части на другие документы (ПЗ, ТУ, РП, ПИ и тп)

Т.е. потенциального исполнителя должно бы волновать, как закрыть текущий этап и открыть следующий. А не как сделать все и сразу, переоценивая при этом свои возможности уложиться в сроки - самая распространенная ошибка «фрилансеров».

Еще, пмсм, стоит разделять фрилансеров и работников на удалении. Первые зарабатывают тем, что выполняют быстро и качественно _типовую_ работу, которая д.б. предельно формализована, именно поэтому они могут сразу оценить сроки и цену своего участия в проекте. Если работа не типовая или не формализована в достаточной мере - нужны спецы на удалении, и чем меньше это «удаление» - тем лучше)