Pull to refresh

Comments 10

Насчёт программной части очень правильно. Лучше сразу описать все технологии с указанием точных версий, чем потом париться.
Спасибо. а то все тут пишут, что надо техническое задание, надо техническое задание.
Но никто не пишет КАК!
Рад, что хоть кому-то пригодится то что я написал )
Детский утренник, а не техническое задание. Почитайте аналогичные работы, чтобы как минимум не пропустить много важного.
Спасибо, уже читал данную статью. То что написано в моем посте расчитано больше на ТЗ именно для сайта. Конечно же неплохо было бы указать цели и задачи, но про них говорится в брифе, на основании которого и строится ТЗ. Бриф идет как Приложение к договору, и как мне кажется, нет смысла писать тоже самое в ТЗ что и в брифе.
Как я писал в посте, цель данного ТЗ все максимально упростить
Ну вот и карма полетела вниз ( А ведь просто хотел поделиться своими мыслями и домыслами…
вопрос немного не по теме, но задать его больше негде.

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

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

Кто видел этот топик, дайте пожалуйста ссылку, чесно гуглил и внутренним и внешним поиском по разным ключевым словам, найти не могу.
UFO just landed and posted this here
Мне всё-таки думается, что без обобщающего раздела ТЗ не обойтись. «Кому нужны будут эти разделы? Почему вообще именно эта функциональность?» — об этом нужно подумать и написать.

Ни одно техническое задание не может описать результат полностью, в мелочах, потому что для этого нужно проделать всю работу, которую задание описывает. Чтобы исполнители могли принимать решения о мелочах, о деталях, им нужно чувствовать назначение всех составляющих элементов. Когда придумаете эти обобщающие разделы, может быть и предполагаемая структура разделов покажется неверной.
Sign up to leave a comment.

Articles