20.08.2009

Про то, что не нужно писать в техническом задании

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

Итак, очень в последнее время раздражают все различные скетчи, схемы, наброски будущего дизайна. Обычно их рисуют менеджеры или сами заказчика, в большинстве случаев без доли смысла. Мешают они тем, что нужно вписываться в какие-то непонятные условия расположение объектов. И если следовать таким скейтчам, то в результате ничего хорошего не получается. Еще, как правило, предлагают всегда стандартную схему расположение блоков: шапка, тело (три колонки) и подвал. Ну и как вы думаете, может что-либо выйти интересное после таких скетчей?

Постоянное возвращение к каким-то сноскам или пунктам. Раздражает на столько что хочется просто начать работать без ТЗ. Очень устают глаза, когда приходиться бегать по 10-ти, а то иногда и по 20-страничному документу. Даже если его распечатать это мало чем поможет. Сноски — это хорошо, но только не когда нужно каждый раз к ним возвращаться.

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

Всем вышеперечисленным я хочу донести до некоторых заказчиков, то, что техническое задание должны быть как можно более компактным и лаконичным. И в нем не место таким вещам как напоминание по основам веб-дизайна или сбивающие с толку скейтчи. Рисовать скейтчи и знать основы веб-дизайна в первую очередь задача дизайнера, а не Ваша.

Поделись с друзьями:

Оставить комментарий:

Vik ondesign.by

Это дело знакомое, творческим людям трудно вписываться в какие-то рамки, но без этого никуда, а то потом проблем не оберешься)

Василий vasily_vaskovsky@somedia.ru

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

Мы менеджеры, и наша задача предусмотреть.
Ну, а если попадётся хороший дизайнер - хорошо..., но всё равно, мы молодцы! мы ведь его нашли =)

зы. - очень хорошие работы, радуют глаз.

Прохожий

Интересно, а как заказчик узнает, что вам указывать в ТЗ, а что нет?
В таком случае, прежде чем заказывать разработку ТЗ у ТЗ-разработчика, заказчику нужно получить от дизайнера пре-ТЗ на разработку ТЗ.

Вот например, у Вас есть такое пре-ТЗ, в котором написано, что нужно указать в ТЗ, что указывать необязательно, а что указывать нельзя ни в коем случае?

Если нет, то соберите страниц этак на 20-30 с кучей ссылок и скетчей.
А потом можете сходить на блог разработчика ТЗ :)))

PS. IMHO это просто работа. Работа всегда раздражает. Если это раздражает Вас сильно, то стоит подумать об отпуске или, как минимум, о режиме дня (сон, еда, спортзал, общение...).

PPS. Прохожу мимо.

Varyunya http://ukrelitflora.com.ua/

Насчет компактности и лаконичности - это точно.
Желательно, конечно это обговаривать при встрече, а не по средствам удаленного доступа...

Mosquito http://designlife.ru

Это просто разные весовые категории по ТЗ. Если делаешь сайт за 200 т. р., то желательно, чтобы в ТЗ были прописаны все нюансы и самые мелочи, в ином случае, если заказчик захочет что-то поменять, составляется доп. соглашение и производится перерасчет суммы (вариант для студий).

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

Я по-второму варианту и работал, а вся эта бюрократия меня также раздражает.

Юрий http://rightblog.ru

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

Конечно есть вариант вынести всю такую инфу - важную, но понятную профессионалам дизайнерам на отдельную страницу.

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

Алексей Морозов http://designpix.ru

GizmoID, никто не писал что тз должно быть мелким. Еще раз внимательно почитайте, о чем идет речь.

GizmoID http://www.sibirix.ru

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

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

Evilant

Вот-вот..получаешь корявый скетч выполненный в ворде, а в пункте каким бы вы хотели видеть ваш сайт обязательно напишут - креативным)) ништяк, вот как хочешь так и вливай креатив в стандартный трехколонник)))

Cергей http://mishalov.ru

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