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

Применительно к веб-девелопменту[1] техническое задание (оно же техзадание, сокращенно ТЗ) – это документ, который описывает требования к будущему сайту, его предполагаемые вид, составные части, устройство, функциональность и предназначение, а также регламентирует процесс его создания. С одной стороны, в нем фиксируются главные аспекты разработки в их логической и хронологической взаимосвязи, с другой – то, какими средствами и по какому алгоритму будет достигаться цель. Попросту – что будет делаться, кем, как именно и когда. И главное – зачем.

А нужно техническое задание по большому счету не веб-программисту и не дизайнеру. Оно нужно вам, и только вам. Ведь чей сайт по нему будет сделан? Конечно, ваш. А значит, не так страшен Word, как его малюют, и пора засучить рукава. Благо корпеть вам не над авторефератом диссертации и не над объяснительной запиской «начальству в зубы». Хотя авторефераты писать полезно ради более строгого структурирования материала в собственной голове, а объяснительная записка иногда заставляет воображение отправиться в головокружительный полет. Вам предстоит составить не что иное, как документ, из которого вырастет ваш сайт. Документ – это своего рода гарантия. Без него ваш интернет-магазин едва ли станет золотоносной жилой, скорее, наоборот, превратится в какой-нибудь бесполезный сорняк, лишь отдаленно напоминающий торговую площадку, где даже нельзя будет добавить товар в «Корзину» без ошибки.

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

Прежде чем обратиться к практике, следует уточнить: всегда ли писать ТЗ – прерогатива заказчика? Смотря по обстоятельствам. Часто инициативу берет на себя исполнитель, особенно когда у клиента в голове лишь концепция в самых общих чертах («Мне бы новостной сайт типа Lenta.ru…» или «Хочу, чтобы было, как у Lamoda.ru, но в более строгой цветовой гамме и с симпатичными мопсами!»), а разработчик или аккаунт-менеджер (если выполнение проекта было поручено веб-студии) опытен и имеет в запасе набор гибко изменяемых типовых решений. Мы рассмотрим усредненную ситуацию, в которой вменяемый заказчик и трезво мыслящий исполнитель по очереди корректируют и дополняют документ до тех пор, пока он не будет устраивать обоих. Но представим, что в первом приближении «генплан сайта» готовите именно вы.

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

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

Изложите свои соображения. Например: «Сайт представляет собой каталог гитарных аккордов к популярным песням. Источники заработка – реклама и партнерские программы с онлайн-сервисами для прослушивания лицензионной музыки. Главная фишка проекта – интеллектуальный механизм распознавания песни, напеваемой посетителем в микрофон…» Правда, последняя фраза имеет смысл, если у вас скопилась энная сумма (порядок – сотни тысяч и миллионы долларов) и вам их не жалко потратить, так что будьте разумны. Мы предполагаем, что вы по меньшей мере бегло изучили ту часть интернет-рынка, в которую собираетесь выйти со своим сайтом, и объективно взвесили собственные возможности.

После того как вы покажете набросок концепции исполнителю, самое время будет вступить с ним в диалог. Если вам встретился профессионал, то он станет тактично задавать наводящие вопросы по существу проекта. Скорее всего, их будет много, и вам придется проявить терпение. У вас есть шанс, что называется, еще на берегу понять сильные и слабые стороны своего замысла. Обмениваясь мыслями с подлинным мастером веб-разработки, вы на ранней стадии можете исправить свой замысел и усовершенствовать бизнес-идею, на которой зиждется проект. Следовательно, вам нужна конструктивная дискуссия, а не одностороннее перечисление того, чего вы хотите или что умеет исполнитель.

Вставим небольшую ремарку к теме человеческого фактора: поскольку телепатическая функциональность по досадному недоразумению пока не прошита в мозгу каждого индивидуума на Земле, недопонимания в любой коммуникации неизбежны. Поэтому, когда вам кажется, что слова вашего собеседника могут быть истолкованы двояко, или вы даже не догадываетесь, о чем он говорит («Раз сервер у вас в Воронеже, а торговать вы собираетесь на всю Россию, вам надо будет прикрутить CDN. Ну и архитектуру спроектировать надежную»), не стесняйтесь переспрашивать и добиваться точных, прозрачных формулировок.

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

Постепенно от общего переходите к частному. Обязательно спросите потенциального исполнителя: «Какими программными средствами вы планируете пользоваться, чтобы реализовать проект?» Хотя звучит эта фраза, как в анекдоте: «Рядовой Кузнецов, повторите, что вы сказали, после того как ваш сослуживец уронил бочку с солидолом вам на ногу?» – «Товарищ майор, я ответил, не нарушая устава: “Иванов, ввиду своей близорукости вы нанесли мне физический ущерб, прошу не усугублять его”». В реальности общение будет примерно таким:

– А на чем вы думаете написать мой сайт? Что предпочтительно?

– На PHP 5.5 в связке с MySQL. Сервер – nginx.

– Почему именно nginx? Мне советовали Apache.

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

– Ладно. Есть ли какие-то особые требования к хостингу?

– А у вас сейчас есть хостинг? Или будете покупать его исходя из наших рекомендаций?

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

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

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

• предназначение и задачи сайта;

• роли заказчика и исполнителя;

• структура сайта;

• содержание;

• краткий список сервисов и возможностей.

«Ну что за бюрократия “роли заказчика и исполнителя”!» – поморщится читатель, нетерпимый к канцелярскому языку. Тем не менее сколь скучно название раздела, столь важен он сам. К сожалению, случается, что если круг обязанностей исполнителя подробно не оговорен, то заказчик после месяца сотрудничества понимает, что создание дизайна в задачу разработчика не входит (обратное было бы странно). Или наоборот, не имея четкой договоренности относительно своих обязанностей, исполнитель ограничивается кодингом, а за верстку сайта и не думает браться.

Список разделов вы вправе изменять, расширять и сокращать исходя из своих потребностей. Помните упомянутое ранее расплывчатое пожелание анонимного заказчика: «Мне бы новостной сайт типа Lenta.ru…»? Справедливости ради необходимо отметить, что в ряде случаев на стадии обсуждения концепции допустимо или даже желательно указать, на какие интернет-проекты вы ориентируетесь, какие вам нравятся больше, а какие меньше.

Ни ваш драфт[2], ни первая версия технического задания (будь она хоть подробнее некуда) – это не «окончательная бумажка», которой вожделел профессор Преображенский в «Собачьем сердце». Почти наверняка изменения и повторные согласования понадобятся. Чем чаще и подробнее они закрепляются сперва в концепции, затем в ТЗ, тем лучше.

Маленький совет, который, мы уверены, облегчит вам жизнь и приблизит момент открытия сайта. Именовать файлы с концепцией или техническим заданием следует так, чтобы с первого взгляда становилось ясно, кто автор редакции документа и является ли она актуальной. Например, ProjectSpecification0.1.doc. Здесь Project – название проекта, Specification – тип документа (в нашем случае техзадание; это может быть и Concept – «концепция»), а первая цифра маркирует версию, отправленную исполнителю; если это 0, значит, она еще не выслана и вы шлифуете документ собственными силами. Тогда 0.2 может обозначать новую редакцию документа, сделанную вами же и никому больше не показываемую. Когда же исполнитель ответит вам, прислав документ со своими уточнениями, вы создадите с учетом его поправок и ваших собственных доработок (версии 0.2) файл под номером 1.3.

При работе над ТЗ вам не помешает попробовать себя в амплуа занудливого параноика: «Новостной блок фиксированного размера находится на главной странице вверху справа, под шапкой. В нем отображаются четыре последние добавленные новости (с возможностью закрепить с помощью админки произвольно выбранную на верхней позиции). Длина текста – до двух строк. Под каждой новостью слева внизу шрифтом на два кегля меньше того, которым набран анонс новости, указана дата в формате DD.MM.YYYY, например 15.08.2013».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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