ТЗ на программинг (стоит ли?)

[01ssv]

раз такая тема пошла.. помню придумал много чего интересного сидя на толчке.. потом сел за код и воплотил задуманное

Такое можно сделать, только для небольших проектов, большие проекты только с ТЗ! Сначала общее: то что хочу, потом подробнее до детального функционала. После этого структуру базы в Erwin или подобном.

Без структуры базы получится, что постоянно базу надо докатывать, а это в свою очередь ведет к накоплению ошибок.

В общем если проект маленький то можно без ТЗ, большой - ТЗ в обяз!

 

[yuravolovod]

Собираюсь полностью реализовать один проект (т.е. я берусь за все - за дизайн, программирование, проектирование и т.п.) и вот такой вопрос: стоит ли составлять ТЗ на программинг "для себя" ? И где можно почитать литературу, в которой описано как сделать ТЗ максимально понятным и помогающим работе человека? Я пытался составить сам - получилось плохо...

стоит. из собственного опыта скажу. сразу любой проект делается на листике... затем тз, много увидишь нового.. если конечно проект не состоит из 100 строк.. особенно тз по програмингу.

 

[thoth777]

Собираюсь полностью реализовать один проект (т.е. я берусь за все - за дизайн, программирование, проектирование и т.п.) и вот такой вопрос: стоит ли составлять ТЗ на программинг "для себя" ? И где можно почитать литературу, в которой описано как сделать ТЗ максимально понятным и помогающим работе человека? Я пытался составить сам - получилось плохо...

100% надо.
сначала составляете общий план проекта (назначение и функционал - то есть что умеет). потом делите на блоки. каждый блок на подблоки. не поленитесь, потратьте время, зато потом будете программить проект и проблем не знать. да и проект, выполненный по ТЗ делается гораздо быстрее чем проект "из головы".

 

[MadWizard]

Полное описание всей информации для составления ТЗ содержится в ГОСТ 34.
Просмотреть можно, например, здесь
Для просмотра ссылки Войди или Зарегистрируйся
Это самый общий шаблон, для каждого конкретного проекта можно адаптировать - оставлять только нужные разделы .

 

[Spitoll]

Собираюсь полностью реализовать один проект (т.е. я берусь за все - за дизайн, программирование, проектирование и т.п.) и вот такой вопрос: стоит ли составлять ТЗ на программинг "для себя" ? И где можно почитать литературу, в которой описано как сделать ТЗ максимально понятным и помогающим работе человека? Я пытался составить сам - получилось плохо...

Составлять нужно, это также относится к проэктированию, при разработке ТЗ ты обращаешь внимание на детали, которые могут менять проэкт. А вобще все зависит от сложности проэкта...

 

[AndreyD2]

ТЗ конечно составляй - только для себя это не совсем ТЗ.
Так как для себя: за красотой не гонись:
1. Структура БД - пожалуй самое важное, посиди подумай над этим на будущее.
2. Разбей программинг на отдельные модули.
2.1 Модули - раздели на функционалы.
3. Дизайн - достаточно просто перечсления необходимого материала, например, шапка - 2часа, flash - 3 часа, ...
В программинге укажи сроки выполнения - и пытайся в них вложится, иначе ничинаешь разрабатывать модуль, приходят новые идеи и ты делаешь один модуль очень долго. Да он получиться универсальным, многопрофильным, но сам проект будет не функционален.

 

[infohomee]

В начале разработки Заказчик, как правило, абсолютно не понимает чего он хочет . Понимание приходит только тогда, когда уже все написано и надо платить. Поэтому, ТЗ - это способ закрыть тему: "мы конечно заплатим, но вы еще сделайте вот это, это, еще э..... здесь расширьте, а здесь наоборот ....".
А для себя больше пользы дадут "карты ума".

 

[alexzander69]

В начале разработки Заказчик, как правило, абсолютно не понимает чего он хочет . Понимание приходит только тогда, когда уже все написано и надо платить. Поэтому, ТЗ - это способ закрыть тему: "мы конечно заплатим, но вы еще сделайте вот это, это, еще э..... здесь расширьте, а здесь наоборот ....".
А для себя больше пользы дадут "карты ума".

Да у меня сейчас такая проблема, проект готов к запуску но заказчики постоянно требуют улучшений, доп функционал, который сейчас сложно реализовать (сразу не предусмотрел, хотя за такие деньги - функция предусматривания не активируется). И еще как назло заказчики знакомые... короче очень жалею что сразу не прописал тз с графиком и ценой работ

 

[KilllorD]

Да у меня сейчас такая проблема, проект готов к запуску но заказчики постоянно требуют улучшений, доп функционал, который сейчас сложно реализовать (сразу не предусмотрел, хотя за такие деньги - функция предусматривания не активируется). И еще как назло заказчики знакомые... короче очень жалею что сразу не прописал тз с графиком и ценой работ

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

 

[lorien]

Да у меня сейчас такая проблема, проект готов к запуску но заказчики постоянно требуют улучшений, доп функционал, который сейчас сложно реализовать (сразу не предусмотрел, хотя за такие деньги - функция предусматривания не активируется). И еще как назло заказчики знакомые... короче очень жалею что сразу не прописал тз с графиком и ценой работ

Они так долго тебя ещё могут мурыжить. ИМХО, надо просто забить на деньги и сказать, что больше новых фич не будет. Если деньги всё же заплатят, то хорошо, если нет - ну и ... с ними. Урок на будущее - зарание расписывать всё детально.

Считаю, что для любого проекта, даже на пол дня, следует в начале взять листочек и нарисовать там компоненты проекта, стадии разработки, стрелочками пометить направление потоков данных. Для разработки веб-сайта хорошо помогает такой приём: надо описать каждую страницу которая будет на сайте. Затем глядя на список страниц надо описать модели данных - структуру таблиц или классов в ORM. Имея на руках два списка: страницы сайта и модели сайта, прщое оценить объём работ, их сложность и количество нужного времени. И, конечно, полученную оценку по времени надо умножить на 2 или 3 и вот тогда уже будет что-то приближенное к реальности