Информация позаимствована с сайта limbo-cms.com.ru.

Автор: Вячеслав Мельник

Опубликована: дек. 2005

Не секрет, что решение о строительстве собственного веб-сайта нередко принимается из эмоциональных и несерьезных посылок. Например: "нужно шагать в ногу со временем", "вот у моего партнера (конкурента) уже есть сайт, а у меня нет …", "сейчас появились свободные деньги, так почему бы не …. ", "знаю отличную дизайнерскую контору - они сделают классно и недорого" и т.д. и т.п. Почему же происходит так, что владельцы сайтов не понимают целей и задач продвижения своих предложений в виртуальной среде или, вообще, используют ложные ориентиры? Причина здесь кроется в недопонимании заказчиком принципов работы Сети и неумении грамотно составить техническое задание исполнителям, прежде всего, программистам и дизайнерам. Как результат - вся работа по созданию узла полностью отдается на откуп именно этим категориям специалистов.

Абсурдность такого подхода можно пояснить на следующем примере. Представьте себе ситуацию, когда техническое задание на строительство, скажем, торгового центра составляет не заказчик, а подрядчики - архитекторы и конструкторы-строители. Даже если все исполнители проекта являются прекрасными специалистами и кристально честными людьми, все равно, они действуют в своих интересах и из своих собственных представлений и соображений. Архитектор всегда стремится нарисовать картинку пооригинальнее, строитель - правильно просчитать и упростить несущие и декоративные элементы конструкции, а оба вместе - продать свою работу заказчику подороже. Причем подрядчиков мало интересуют вопросы окупаемости и функциональности торговых площадей после сдачи объекта. И совершенно правильно: изначально об этом должен был позаботиться сам заказчик!

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

Что же получается при отсутствии продуманного техзадания? Почувствовав неограниченную свободу, дизайнеры набивают вебстраницы графикой, флэшами и прочей анимацией, программисты вставляют совершенно дикие скрипты, работающие только под определенными версиями наиболее известных браузеров. А над организацией контента вообще никто не задумывается: информацию просто переносят на вебстраницы с каких-нибудь ведомственных печатных материалов, имеющихся под рукой. В результате появляются сайты, похожие на одинокие заброшенные пирамиды, пути-дороги к которым затерялись. Когда же одинокий пользователь случайно натыкается на подобные узлы, он быстро их покидает, утомившись длительной загрузкой вебстраниц или испугавшись перспективы долго разбираться в неясных предложениях и назначении сайта.

Методика составления технического задания

С практической точки зрения техзадание поможет заказчику четко и ясно поставить задачу разработчику веб-сайта. В юридическом отношении этот документ станет неотъемлемой частью договора с дизайнером или дизайнерской студией (оформляется как приложение к договору).

Понятно, что заказчик не должен глубоко разбираться в технических вопросах, однако знать и отчетливо формулировать свои цели и задачи он просто обязан. Помочь в этом вопросе смогут обычные, еще советские ГОСТы, распространяющиеся на единую систему программной документации, поскольку отдельный стандарт на составление техзадания для сайтостроителей пока еще не появился. Итак, возьмем для примера ГОСТ 19.201-78 "ТЕХНИЧЕСКОЕ ЗАДАНИЕ, ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ".

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

"1.4. Техническое задание должно содержать следующие разделы:

наименование и область применения;
основание для разработки;
назначение разработки;
технические требования к программе или программному изделию;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приёмки;
приложения"
Итак, раздел первый: "Наименование и область применения"


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

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

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

Раздел второй: "Основание для разработки"


Основанием для разработки станет договор заказчика с исполнителем на разработку веб-сайта, а техзадание станет приложением к этому договору.

Раздел третий: "Назначение разработки"


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

Раздел четвёртый: "Технические требования к веб-сайту"


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

В данном разделе заказчику необходимо указать следующие данные:

1) Структура сайта (фреймовый, бесфреймовый, одно- или многоязычный, ориентировочное количество страниц и пр.). Основные пожелания к дизайну гипертекстовых страниц.

2) Прогнозируемая скорость передачи данных на линиях основной аудитории сайта. Иными словами, заказчику следует подумать, на какой скорости средний пользователь получит доступ к сайту. Например, если основная аудитория сайта - индивидуальные пользователи с коммутированным доступом в крупных городах СНГ, то следует ориентироваться на 28,8 кбит/с, а если пользователь живет в провинциальном городе, то, наверное, будет разумным ограничится 14,4 кбит/с. Если же заказчик решил покорить европейского или американского потребителя, да еще выбрал местный хостинг, можно рассчитывать на 56 К и выше. В следующем пункте изложено о том, зачем это нужно.

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

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

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

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

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

Владельцу сайта всего лишь нужно добиться выполнения следующих условий:

Все скрипты должны безотказно работать в основных браузерах (Internet Explorer, Netscape и Opera) версии 4.0 и выше. (Не следует рассчитывать на слишком древние браузеры и, в то же время, ограничиваться лишь самыми последними версиями).
Сайт должен хорошо смотреться во всех указанных браузерах.
Не должно быть ограничений на разрешающую способность и размер монитора пользователя. (По крайней мере, страницы должны иметь нормальный вид на 15- и 17-дюймовых мониторах при разрешающей способности как 1024 х 768, так и 800 х 600).
Страницы сайта должны нормально восприниматься посетителем, который пользуется браузером в режиме отключения просмотра графики. (С целью ускорения загрузки страниц многие пользователи снимают опцию просмотра рисунков).
Разумеется, дизайнеру проще работать без вышеуказанных ограничений: простор для творчества, можно наращивать объемы графики и, одновременно, не заниматься оптимизацией графических изображений. Как правило, сначала вопросы оптимизации ускользает от внимания заказчика, но в последующем они наворачиваются как снежный ком, больно ударяя по бюджету сайта. В худшем случае, заказчику вообще приходится перестраивать свой онлайновый ресурс, если дизайнеры приложили все силы, чтобы выполнить поисковую оптимизацию наоборот , а составители текстового контента нарушили основные правила веб-копирайтинга .

Раздел пятый: "Технико-экономические показатели"


Четвертый раздел можно объединить с третьим, но если заказчик одновременно заказывает оптимизацию и продвижение (это лучше сделать заранее, а не после публикации сайта в Сети), то целесообразно указать следующие требования:

Ключевые слова и их количество.
Количество исходящих и входящих ссылок.
Прогнозируемое количество посетителей через месяц, квартал, полгода.
Прогнозируемый рейтинг сайта по определенным словосочетаниям через определенное время (месяц, квартал, полгода).
Специальные требования для интернет-магизинов и т.д.
Раздел шестой: "Стадии и этапы разработки"


Раздел составляется по согласованию с исполнителем. По сути, в раздел переписывается соответствующий пункт договора.

Раздел седьмой: "Порядок контроля и приёмки"


Контроль и приемка готового веб-сайта достаточно просты:

Заказчик просматривает готовый сайт с помощью разных браузеров, на различных мониторах с различной разрешающей способностью (см. Третий раздел, п. 4).
С помощью специальных средств проверяется время загрузки графических изображений.
После выбора хостинга и размещения сайта аналогичная проверка выполняется с различных компьютеров (начинать следует с места, где имеются худшие условия доступа в Интернет).
Раздел седьмой: "Приложения"
Любые дополнения к техзаданию.

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


--------------------------------------------------------------------------------

Об авторе

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