cRoss_s Сообщение 08/06/2010 17:03 Копия темы
Место «фишечек» на сайте, или роль дизайнера в написании технического задания Предположим, ваш аналитик (или вы, если компания небольшая, и ТЗ пишет сам менеджер) рисует модель. Он собрал все данные, учел все требования заказчика, знает, на какой странице что должно выводиться, как обновляться, какой объем информации и в каком виде должен выдаваться, куда ведут ссылки, какие вообще элементы навигации на странице, в общем, полный пакет требований к страницам у него есть.



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

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

Кроме того, в ряде случаев, новые идеи дизайнера могут потребовать (и часто требуют) дополнительного описания того, как же они на самом деле будут работать. Что фактически порождает еще один документ. Представьте себе лидера программистов, который сидит и мучительно сводит два документа в один в своем сознании, чтобы донести до команды, а как же реализовать тот или иной эффект, не потеряв при этом смысл, описанный в ТЗ.

В данном случае, мне видится реализации.

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

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

Естественно, и в том и в другом случае задание пройдет ряд итераций по согласованию и утверждений со стороны специалистов исполнителя и ответственных лиц заказчика, но в общем виде проводимые итерации видятся мне именно такими.

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