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

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

• Термины и определения.

• Назначение технического задания.

• Обязанности исполнителя и заказчика.

• Назначение и задачи сайта.

• Описание работы сервиса и механики сайта.

• Структура сайта и его составляющие.

• Дизайн сайта.

• Требования к технической и программной реализации сайта.

• Условия сдачи и приемки.

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

Никто не отменял каверзных законов Мерфи: если возможны разночтения, с высокой долей вероятности будет выбрано большее из зол. Гладко было на бумаге, да забыли про овраги. А также про тектонические трещины, вблизи которых сейсмическая активность столь сильна, что, вероятно, скоро никаких оврагов не будет. И про то, что овраги заодно с полями и лесами находятся в частной собственности.

Вообще попробуйте отнестись к ТЗ как к брачному контракту. Вам ведь со своим сайтом потом жить и жить.

Форма подачи информации в техническом задании остается на ваше усмотрение и зависит от того, кто ваш подрядчик и каков его опыт, насколько сложна внутренняя логика сайта, делаются ли в одной фирме дизайн, программирование и верстка или нет. Существуют отраслевые стандарты по составлению ТЗ, включая предписываемый IEEE[3]. Кроме того, простите за грубость, в интернет-фольклоре есть «правило 34», которое звучит так: «Про это есть порно». Так вот, можно было бы сформулировать и «правило 34.1»: «Про это есть ГОСТ». И по формату техзадания на разработку сайта ГОСТ имеется, и номер его – 34.602-89.

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

Визуализацию в техзадании использовать крайне желательно (рис. 1). Это может быть нарисованная в любом графическом редакторе блок-схема, отображающая модули так, как они должны быть расположены на той или иной веб-странице. Как в театре шекспировской эпохи, когда в отсутствие декораций прислужники выносили на сцену особые таблички – титлы, призванные обозначить место действия: «Лес», «Тронная зала». В нашем случае – «Шапка», «Форма поиска» и т. д.

^{Рис. 1. Техническое задание на редизайн портала Banki.ru, реализованное в доступной графической форме – с использованием стикеров}

Самый наглядный, но, к сожалению, едва ли не утопический вариант – подробный, с зачатками дизайна, эскиз страницы каждого типа (например, в случае с интернет-магазином – титульная страница, страница продуктовой категории, страницы отдельных товаров, «Корзина» и пр.). Он обладает существенными преимуществами, однако требует владения графическими редакторами – как правило, подразумевается Photoshop, – по крайней мере на любительском уровне. Почему этот вариант скорее утопический? Потому что редкий заказчик располагает глубокими познаниями в проектировании интерфейсов и вместе с тем, пусть даже он собаку съел на веб-проектах, не навязывает дизайнеру свое художественное видение, а лишь указывает ему реперные точки.

Комплексное, наглядное представление сайта также обеспечивают mind maps – дословно «ассоциативные карты» (рис. 2). Эта техника позволяет отобразить проект в виде древовидной схемы, на которой каждому элементу (понятию, модулю) соответствует блок, причем в одном блоке не должно быть больше трех-четырех слов. Ассоциативные карты помогают с легкостью обнаруживать логические противоречия там, где при сопоставлении отдельных эскизов страниц это заняло бы часы, и смотреть на план сайта «с высоты птичьего полета».

Понять, эффективны ли механизмы сайта «вживую», дает возможность его прототип – макет той или иной степени интерактивности (см. главу 2 «Создание прототипа: анатомия сайта»). Для сборки таких «боевых моделей» предназначен целый арсенал инструментов, в том числе онлайновых, например зарубежный Balsamiq.com и российский Guimachine.ru.

^{Рис. 2. Mind map на проектирование сайта}

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

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

«Техническое задание на сайт»: http://habrahabr.ru/post/138749/

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

В нашем случае прототипом является набор логически связанных между собой схем веб-страниц, в своей совокупности демонстрирующих структуру и механику работы сайта. Это его «муляж», степень детализации которого варьируется в широких пределах: от скупого карандашного наброска на листе формата A4 до комплекта файлов с расширением. psd (формат Photoshop) с натянутым на каркас интерфейса дизайном, а вернее – «протодизайном». Или своего рода «анатомическая карта» – тело сайта в разрезе, показывающем, где какой сустав сгибается и за счет каких сухожилий и мускулов.

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

Прототипы полезны всем сторонам, участвующим в разработке сайта. Каждому по-своему.

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

Команда проекта с помощью прототипа лучше согласует свои действия. Еще бы: у каждого перед глазами «декларация о намерениях в картинках». В спорной ситуации гораздо проще ткнуть пальцем в проблемный узел схемы, чем ожесточенно спорить о том, кто где ошибся. Это дорожная карта веб-разработки.