Проект сайта

Проект сайта

С чего начать?

Работу над большинством Web-проектов можно условно разделить на три этапа.

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

2. Этап разработки. После того как заказчик принимает предложения, разработ­чик может начинать работу по созданию Web-узла. На этом этапе создаются компоненты узла и связываются между собой. Если на предыдущем этапе раз­работчик добросовестно отнесся к планированию, то на этапе разработки поч­ти никогда не возникает необходимости переделывать уже выполненную рабо­ту.

3. Этап, следующий за окончанием разработки. Последний этап работы по созда­нию Web-узла включает тестирование готового узла, обеспечение доступа к нему из глобальной сети и рекламирование узла.

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

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

Рекомендуемые материалы

Получение заказа на выполнение проекта

Каждый проект начинается с переговоров разработчика с потенциальным заказчи­ком. В данном разделе вы узнаете о том, какие шаги следует предпринять для того, чтобы заказчик выбрал для выполнения проекта именно вас. Вы научитесь работать с заказчиком, подготавливаться к первой встрече и решать проблемы методом "мозгового штурма". После того как вы выясните потребности заказчика и у вас поя­вятся идеи насчет предполагаемого Web-узла, вам необходимо выяснить круг пользо­вателей, на который ориентирован создаваемый Web-узел, и ознакомиться с реше­ниями, которые используются конкурирующими организациями. Затем вам надо оп­ределить время выполнения проекта и бюджет и, наконец, выдвинуть конкретные предложения, и подписать договор с заказчиком.

Работа с заказчиком

Ваша способность представить информацию в Web зависит от объема и качества данных, которыми вы располагаете. Различные заказчики взаимодействуют с разра­ботчиками по-разному. Некоторые полагаются на вас и ожидают, что вы сами выяс­ните и разрешите их проблемы. Другие хотят непосредственно участвовать в работе над проектом. Заказчик может иметь свои соображения о том, каким должен быть Web-узел, и потребовать от вас реализации его идей.

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

Ниже перечислены некоторые рекомендации по работе с заказчиками.

• Тщательно подготовьтесь к встрече с заказчиком. Как и любая другая работа, перего­воры с заказчиком требуют подготовки. Перед первой встречей с заказчиком собери­те как можно больше сведений о нем. Некоторые заказчики готовы отдать вам ини­циативу ведения встречи, поэтому у вас должен быть готов план переговоров.

• Объясните особенности процесса разработки. Раскройте в деталях ход процесса разработки от начального до конечного этапа. Оговорите, на каких стадиях раз­работки вам потребуется информация от заказчика.

• Определите рамки взаимодействия. С самого начала работы над проектом определите степень участия заказчика в процессе разработки. Если вы считаете, что идеи заказ­чика не реализуемы или способны повредить выполнению проекта, попытайтесь убедить заказчика в том, что ему следует пересмотреть свою точку зрения.

• Попытайтесь побольше узнать об области деятельности заказчика. Часто заказчик не способен объяснить особенности своей деятельности. Задавайте вопросы и попытайтесь добиться того, чтобы заказчик предоставил нужную вам информа­цию. При необходимости постарайтесь получить необходимые сведения у его партнеров по бизнесу.

• Готовьтесь слушать. Постарайтесь не перебивать заказчика. Время, которое вы потратите при этом, не пропадет зря; вы сможете лучше понять особенности

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

• Если вы что-либо не понимаете, не пытайтесь скрыть это. Правдиво отвечайте на во­просы. Если вы не владеете каким-то вопросом, скажите об этом. Имеет смысл от­ложить обсуждение некоторых вопросов до следующей встречи; за это время вы сможете разобраться в них. Скрывая свою неосведомленность, вы рискуете впослед­ствии столкнуться с неразрешимыми проблемами. Если вы не способны решить за­дачу, поставленную заказчиком, порекомендуйте ему тех, кто может сделать это.

• Продемонстрируйте свои возможности. Расскажите заказчику о работах, выполненных вами ранее. Ознакомьте его с презентациями своих предыдущих проектов. Покажи­те, как средствами Web вам удавалось решить проблемы, с которыми сталкивались предыдущие заказчики. Подготовьте демонстрационный ролик, в котором содержа­лись бы информация о заказчиках, с которыми вы работали ранее, URL заказчиков и были представлены ваши возможности по решению задач.

• Проявите себя как энтузиаста и профессионала. Если заказчик увидит, что вы с во­одушевлением беретесь за работу, он поверит, что вы сможете создать высококачест­венный Web-узел, и вероятность того, что договор будет подписан, увеличится. Вам также необходимо убедить заказчика, что вы серьезно отнесетесь к работе.

• Будьте готовы ответить на вопросы. Заказчику может потребоваться дополни­тельная информация о ваших возможностях. Предоставьте ее как можно скорее.

Взаимодействие с представителем заказчика

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

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

Примечание

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

Первая встреча

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

Профессиональные Web-узлы редко создаются одиночками. Обычно такой узел появляется в результате совместных усилий группы специалистов, и основной участ­ник данной группы — заказчик. Поэтому открытое и конструктивное общение с за­казчиком является одним из главных условий успеха.

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

В ходе первой встречи желательно задать заказчику следующие вопросы:

• Каков род вашей деятельности?

• Есть ли у вас Web-узел?

• Если Web-узел уже имеется, каковы, по вашему мнению, его достоинства и не­достатки? Почему вы решили создать новый узел?

• Какие Web-узлы вам нравятся? Кто ваши конкуренты? Каковы, по вашему мне­нию, достоинства и недостатки их узлов?

• Каково основное назначение Web-узла?

• Какие кратковременные и долговременные цели преследует создание нового узла?

• Какую информацию о вашем бизнесе вы хотите сделать доступной широкой публике посредством Web-узла?

• Какие продукты или услуги вы предлагаете потребителям?

• С какими другими узлами вы хотели бы связать ваш узел посредством гипертек­стовых ссылок?

• Какой объем информации должен быть представлен на Web-узле?

• Есть ли у вас зарегистрированный товарный знак? Надо ли помещать его на Web-узел?

• Какие ресурсы имеются в наличии в настоящее время (например, фотографии, текстовые файлы, логотипы и т.д.)?

• Какие основные разделы должен содержать Web-узел?

• Как часто вы предполагаете обновлять содержимое Web-узла?

• Каков предполагаемый состав посетителей Web-узла?

• Какие типы отклика вы намереваетесь получать от посетителей Web-узла?

• Должен ли Web-узел быть статическим или динамическим? (Динамические Web-узлы основываются на использовании баз данных.

• Как скоро Web-узел должен быть представлен в сети?

• Кто является вашим провайдером?

• Каков бюджет данного проекта?

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

• Привлечь новых потребителей.

• Предоставить существующим потребителям новые средства приобретения товаров.

• Сделать каталоги товаров и услуг доступными в Internet.

• Предоставить широкой публике информацию о компании.

Запишите цель создания Web-узла и всегда держите эту записку под рукой, чтобы вы могли свериться с ней, принимая решение о содержимом Web-странц или их внешнем виде. Увлекшись деталями, например размещением изображений или созда­нием навигационных кнопок, легко забыть о том, для чего же выполняется вся рабо­та. Записанная цель создания узла поможет вам придерживаться основного направле­ния при работе над проектом.

«Мозговой штурм»

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

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

В совещании методом "мозгового штурма" обязательно должен принимать уча­стие заказчик. Это необходимо по нескольким причинам. Во-первых, в большинст­ве случаев заказчики сами хотят участвовать в работе над проектом. Во-вторых, за­казчик непосредственно заинтересован в создании Web-узла, а соображения, выска­занные им, могут существенно помочь разработчикам. В-третьих, заказчик может убедиться в том, что интенсивная работа над проектом уже началась и разработчик учел его мнение.

После окончания совещания на основании высказанных предложений формирует­ся начальный перечень характеристик будущего Web-узла. Этот список называют ви­дением Web-узла. Видение должно определять конкретные цели, выраженные количе­ственно. Например, целью заказчика может быть увеличение числа потребителей на 10% за счет предоставления им новых технических средств для приобретения товаров.

Определение предполагаемой аудитории

В реальной жизни ваше поведение и внешний вид существенно зависят от аудито­рии, с которой вам придется встретиться. Например, вы по-разному оденетесь, от­правляясь на встречу с друзьями и на важное деловое совещание. Внешний вид Web-узла также зависит от предполагаемой аудитории. Очень важно перед началом работы выяснить круг пользователей, на который рассчитан Web-узел.

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

Необходимо также учитывать техническую оснащенность предполагаемой аудитории, поскольку многие характеристики узла (от оформления до программного обеспечения) за­висят от аппаратных средств, имеющихся в распоряжении пользователей. Возможности пользователей — существенный фактор, ограничивающий набор средств, который может быть применен при оформлении Web-документов. Вы также должны выяснить, какой тип Internet-соединения типичен для предполагаемых пользователей узла (связь по коммути­руемой линии, кабельное соединение, линия Т1 и т.д). Например, если большинство поль­зователей имеют доступ к Internet по коммутируемой линии, в состав Web-страницы нель­зя включать мультимедиа-данные и большое количество изображений. Важно выяснить, какая операционная система установлена на компьютерах пользователей (Windows 95, 98, 2000, ME; Mac OS 8, 9, X или UNIX). Зная ответ на этот вопрос, вы сможете выбрать опе­рационную систему для наиболее полного тестирования Web-узла.

Для того чтобы определить характеристики среднего пользователя, желательно за­дать заказчику следующие вопросы.

• Как бы вы определили круг пользователей создаваемого узла?

• Какова возрастная группа большинства пользователей?

• К каким этническим группам принадлежат большинство пользователей?

• Каков средний доход пользователей создаваемого Web-узла?

• Преобладают ли среди пользователей мужчины или женщины?

• Каков род занятий большинства пользователей?

• Ограничен ли круг пользователей определенным регионом или страной?

• Имеют ли предполагаемые пользователи узла какие-либо характеристики, при­сущие только им?

• Могут ли в составе предполагаемой аудитории присутствовать пользователи с физическими ограничениями?

• Как часто узел будет посещаться пользователями?

• Что получают пользователи в результате посещения Web-узла?

• Какой опыт работы с Web имеют предполагаемые пользователи?

• Какой тип соединения применяют большинство пользователей для доступа к Internet? Какова пропускная способность линий?

• Какую операционную систему применяют большинство пользователей?

• Какие аппаратные средства применяют большинство пользователей?

• Используют ли они старые модели компьютеров?

• Какая разрешающая способность типична для мониторов, которые применяют предполагаемые пользователи?

Предполагаемая аудитория — один из основных факторов, определяющих соотноше­ние текста, изображений, мультимедиа-данных и интерактивных элементов в составе Web-узла. Например, Web-узел, ориентированный на детей, должен быть насыщен красочными элементами, изображениями, в том числе движущимися, для него должны специально вы­бираться шрифты. Web-узел, предназначенный для людей старшего возраста, должен со­держать больше текста, цвета должны быть сдержанными, композиция — несколько ста­ромодной. Кроме того, необходимо использовать для Web-страниц полужирный шрифт или шрифт большого размера, чтобы пользователи с ослабленным зрением могли без тру­да читать текст. Разрабатывайте Web-узел с учетом предполагаемой аудитории, но помни­те, что большинство Web-узлов доступно широкой публике, поэтому пользователи могут принадлежать к самым различным категориям.

Определение масштаба Web-узла

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

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

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

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

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

• Основная идея Web-узла.

• Способ представления основной идеи.

• Общий стиль Web-узла (должен ли материал излагаться формально или нефор­мально, является ли узел академическим, развлекательным и т.д).

• Имеются ли у заказчика необходимые материалы (например, логотипы, текст, изображения и т.д.), или вам необходимо создавать Web-узел с нуля.

• Есть ли у заказчика Web-сервер, или Web-узел должен размещаться на сервере провайдера.

• Придется ли вам сопровождать Web-узел после того, как он будет представлен в Internet.

Анализ информации, представленной конкурентами

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

Чтобы наилучшим образом проанализировать Web-узлы конкурентов, задайте себе следующие вопросы.

• Насколько хорошо представлена информация?

• Соответствует ли представленная информация назначению Web-узла?

• Запрашивает ли узел данные у пользователя?

• Ориентирован ли узел на ту же аудиторию, что и ваш Web-узел?

• Обладает ли узел какими-либо особенностями, отличающими его от других Web-узлов?

• Удобно ли работать с Web-узлом?

• Много ли времени требуется для копирования данных?

• Привлекает ли узел внимание пользователя?

• Какие элементы вы использовали бы на создаваемом вами Web-узле?

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

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

Бюджет и время выполнения проекта

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

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

Потребности заказчика должны соответствовать времени выполнения проекта и бюд­жету. Если необходимо, чтобы Web-узел был создан очень быстро, вам следует ограничить масштаб проекта. Если вы собираетесь привлечь новых сотрудников, чтобы создать Web-узел за ограниченное время, неизбежно возрастет общая стоимость проекта. Если вы хоти­те выполнить работу своими силами за ограниченное время в рамках ограниченного бюд­жета, это можно сделать за счет упрощения проекта; в этом случае вам придется подумать о том, какими элементами Web-узла можно пожертвовать.

Вам необходимо оценить, сколько времени займет работа над проектом опреде­ленного масштаба. Точно подсчитать время, необходимое для выполнения каждой за­дачи, очень сложно. Если вы руководите группой разработчиков, попытайтесь полу­чить оценку затрат времени от каждого из сотрудников. Для решения одной и той же задачи разным сотрудникам может потребоваться различное количество часов. Под­считывая время, учтите затраты на изменение композиции Web-узла и изменения, ко­торые, возможно, придется внести в текст. Обычно Web-дизайнеры планируют, что композиция узла будет изменена дважды и учитывают это в общей стоимости проек­та. Если же возникает необходимость в дальнейшем изменении композиции, то пре­дусматривается почасовая оплата дополнительной работы.

Рассчитывая общую стоимость проекта, необходимо принять во внимание все затраты.

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

• Необходимо принять в расчет стоимость приобретаемых материалов и их обработки.

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

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

Если заказчик рассчитывается с вами на основании времени и материалов, под­скажите ему, как минимизировать количество часов, затрачиваемых на выполнение работы. В частности, работа по созданию Web-узла часто затягивается из-за того, что материалы, предоставляемые заказчиком, нуждаются в редактировании. Объясните заказчику, что работа существенно ускорится, если текст, передаваемый для перевода в HTML-формат, будет предварительно просматривать корректор.

Желательно проинформировать заказчика о том, как вносятся изменения в струк­туру и содержимое Web-узла. Ваше взаимодействие с заказчиком существенно упро­стится, если в контракт будет включен пункт, оговаривающий условия внесения из­менений. Заказчик должен знать, что изменения масштаба проекта или его содержи­мого после утверждения предыдущего варианта неизбежно влекут за собой пересмотр графика выполнения работ и бюджета проекта.

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

Определяя стоимость выполнения проекта, необходимо также учесть вопросы раз­мещения Web-узла на сервере. Поговорите с заказчиком и получите у него ответы на следующие вопросы.

• Имеет ли заказчик собственный Web-сервер?

• Имеет ли заказчик договор на размещение Web-узла на каком-либо из серверов?

• Считает ли заказчик, что вопросом размещения Web-узла на сервере должны заниматься вы? Если да, то есть ли у вас время и возможности сделать это?

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

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

• Потребности заказчика.

• Расположение агентства Web-дизайна

• Объем и качество работ, выполненных ранее агентством Web-дизайна.

• Квалификация Web-дизайнера.

• Состояние рынка.

Составление предложений

После того как вы узнали потребности заказчика и определили масштаб проекта и содержимое Web-узла, оформите эти сведения в виде предложений.

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

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

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

Переговоры и подписание договора

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

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

Проводя переговоры, предшествующие подписанию договора, желательно придер­живаться следующих правил.

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

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

• Будьте готовы к тому, что другая сторона, в данном случае заказчик, будет оспари­вать некоторые положения договора и предложит пересмотренный вариант. Пред­ложите заказчику выделить внесенные изменения и снова прочтите текст договора, чтобы убедиться в том, что остальные положения остались в прежнем виде. Лучше всего показать переработанный текст договора юристу. Несущественная для вас пе­рестановка слов и даже знаков пунктуации может изменить первоначальный смысл договора, и профессиональный юрист это обязательно заметит.

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

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

• Подписывайте договор только в том случае, если все его положения понятны и при­емлемы для вас. Желательно, чтобы договор предварительно просмотрел юрист.

• Если в процессе переговоров вы делаете уступки, то вы вправе ожидать, что другая сторона пойдет на уступки по другим пунктам.

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

• Не называйте в начале переговоров предельно допустимые условия. Многие счита­ют, что в ходе переговоров необходимо добиться уступок от другой стороны.

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

Многие разработчики не имеют достаточного опыта ведения переговоров. Если вы не уверены, что сможете справиться с этой задачей, наймите специалиста, который будет представлять ваши интересы. Лучше всего вести переговоры так, чтобы в ре­зультате обе стороны оказались в выигрыше.

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

В тексте договора описывается, какие задачи решает разработчик, как они должны быть выполнены, стоимость работ и права собственности на результаты выполнения проекта. Если в ходе работы между разработчиком и заказчиком возникают разногла­сия, они разрешаются на основании текста договора.

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

• Кто является владельцем Web-узла и с какого момента Web-узел переходит в его собственность.

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

• Кто отвечает за выполнение различных частей проекта.

• Сроки выполнения каждого этапа договора.

• Стоимость проекта и сроки выплаты.

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

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

Роли участников разработки

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

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

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

• Главный конструктор. В некоторых больших компаниях, специализирующихся на разработке Web-узлов, предусмотрена должность главного конструктора, который разрабатывает общую структуру продукта и несет ответственность за свое решение. Многие главные конструкторы раньше были художниками или Web-дизайнерами.

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

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

• Видеодизайнер. Подобно аудиодизайнерам, видеодизайнеров обычно нанимают на контрактной основе для работы над конкретными проектами. Видеодизайнер создает и редактирует видеоклипы для Web-узлов. В процессе работы он непо­средственно взаимодействует с аудиодизайнером и Web-дизайнером, а в некото­рых случаях и с главным конструктором.

• Аниматор. Аниматор создает анимационные последовательности для Web-узлов. Некоторые аниматоры ранее работали над созданием фильмов и переключились на создание Web-узлов. Некоторые занимались обработкой изображений, затем освоили специализированные инструменты и стали работать с анимацией. Часть аниматоров изначально получили соответствующее образование. Для того чтобы создавать сложные анимационные последовательности, необходимо знать соот­ветствующие языки программирования и языки сценариев. Как правило, ани­мационные элементы, содержащиеся в составе Web-страниц, достаточно просты и представляют собой анимационные GIF-изображения. Большинство анима­ционных последовательностей создается с использованием таких инструментов, как Macromedia Flash или Adobe LiveMotion. Указанные приложения позволяют быстро создавать анимационные данные приемлемого качества.

• Программист. Программисты отвечают за кодирование HTML-документов и соз­дание сценариев для Web-узлов. Для того чтобы участвовать в создании динами­ческих Web-узлов, программист должен иметь опыт работы с CGI-сценариями, JavaScript, VBScript, SQL, Perl, XML и Dynamic HTML. Приступая к работе над проектом, как можно раньше привлекайте программистов к участию в совеща­ниях. Чем раньше программист выдвинет свои предложения, тем легче будет согласовать их с общей структурой Web-узла.

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

• Специалист, оценивающий применимость узла. Данный специалист проверяет, удобно ли пользователю работать с данным Web-узлом. Он тестирует содер­жимое Web-узла и определяет, что следует сделать для того, чтобы ускорить и упростить доступ пользователя к информации, содержащейся на Web-узле.

Большинство специалистов подобного профиля участвуют одновременно в нескольких проектах.

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

Структура рабочей группы

Если вы не чувствуете в себе силы самостоятельно создать Web-узел с нуля, вам придется работать в составе рабочей группы. Численность группы зависит от особенностей конкретного проекта, а также от ресурсов, которыми располагает компания, специализирующаяся на создании Web-узлов. В больших компаниях рабочая группа может насчитывать большое количество сотрудников, каждому из которых поставлена конкретная задача. Если размеры компании малы, в состав рабочей группы входят несколько специалистов, отвечающих за разработку всего Web-узла. Запомните, что ни должности сотрудников, ни взаимодействие между ними нельзя рассматривать как незыблемую истину. Если вы ознакомитесь с деятельностью различных компаний, то увидите, что ка­ждая компания по-своему организует работу над проектом.

Примечание.

Должность участника рабочей группы не обязательно отражает его роль в работе над проектом и даже уровень квалификации. В разных компаниях в одних и тех же ролях выступают сотрудники, работающие на различных должностях. Вы можете встретить художника или аниматора, отвечающего за композицию всего Web-узла. Сказанное относится и к объему выполняемой работы. В небольшой компании разработкой и со­провождением Web-узла может заниматься один человек. Он может занимать долж­ность старшего Web-дизайнера. В больших компаниях ту же работу делают Web-дизайнеры различных уровней и даже специалисты других профилей. Не обращайте большого внимания на название вашей должности. Главное для вас— специфика и объем работ, которые вам предстоит выполнить.

Планирование Web-узла

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

Сбор данных

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

• Информация о компании.

• Информация о положении компании на рынке.

• Данные о биржевой деятельности.

• Адреса, телефонные номера, адреса электронной почты.

• Глоссарий.

• Элементы оформления, которые должны быть использованы в составе документов.

• Тексты.

• Прочие ресурсы (видеозаписи, книги, статьи, компакт-диски и т.д.).

• URL предприятий-конкурентов.

На этапе, предшествующем разработке компонентов узла, соберите столько мате­риалов, сколько сможете. Избыток информации обеспечит вам некоторую свободу выбора. Чем больше материалов вы получите у заказчика, тем больше ресурсов будете иметь в своем распоряжении при создании узла.

Содержимое

По возможности соберите текст, логотипы, фотографии, иллюстрации, аудиофай­лы и прочие данные. Вы можете получить их у заказчика либо найти в других источ­никах, например на компакт-дисках, в библиотеках или в Web. Внимательно озна­комьтесь с собранными вами данными. Решите, какая информация наиболее важна и как ее следует разместить на Web-узле. Распределите данные по темам. Продумайте способ представления данных. Решите, какую часть содержимого узла должен состав­лять текст и как много изображений необходимо представить на узле. Нужны ли до­полнительные материалы, графические данные, таблицы или интерактивные компо­ненты? Оправдано ли применение фреймов?

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

Размер

Оцените объем информации и подумайте о том, как наилучшим образом распре­делить ее в пределах узла. Объем информации определяет количество Web-страниц, их внешний вид и средства навигации. Подумайте о том, как эффективно представить данные на узле.

Мультимедиа

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

Вспомогательные данные

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

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

Статическое и динамическое представление данных

Определите, должны ли данные быть представлены статически или динамически. Когда заказчик передает запрос на получение Web-страницы, сервер, на котором хра­нится соответствующий документ, передает на компьютер пользователя HTML-код и Web-страница отображается в окне броузера. Для статических Web-страниц сервер не выполняет никаких других действий. Пользователь может просматривать полученный документ, вводить информацию с помощью интерактивных элементов, активизиро­вать аплеты, но в состав Web-страницы входит только та информация, которая была заложена в нее в момент форматирования.

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

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

Получение данных от заинтересованного лица

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

Определите заинтересованное лицо — сотрудника или партнера предприятия, ин­тересам которого отвечало бы создание качественного Web-узла. В ходе встреч с заин­тересованным лицом вы лучше поймете особенности предприятия и, соответственно, сможете лучше представить его на Web-узле. Вопросы, задаваемые заинтересованному лицу, могут касаться тех деталей деятельности предприятия, которые не всегда из­вестны представителю заказчика.

В ходе встреч с заинтересованным лицом желательно задать ему следующие вопросы.

• Какие функции выполняет ваш отдел?

• Как они связаны с деятельностью предприятия?

• Какие технологии используются при выпуске продукции?

• Какова численность отдела?

• Какие сведения об отделе должны быть, по вашему мнению, отражены на Web-узле?

• Насколько быстро устаревает информация об отделе?

• Какую информацию вы хотели бы получать от посетителей узла?

• С какими другими Web-узлами должны, по вашему мнению, быть связаны Web-страницы, посвященные вашему отделу?

• Какие Web-узлы вам нравятся?

• Какие ресурсы, имеющие отношение к деятельности отдела, доступны на сегодняшний день (фотоснимки, текстовые файлы, логотипы и т.д.)?

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

Разделение на категории и определение приоритетов

Перед тем как приступать к разделению информации на категории и определению приоритетов, убедитесь в том, что у вас имеется полный перечень данных, которые должны быть представлены на Web-узле. Включение новой информации в готовый Web-узел представляет собой крайне сложную задачу. Если у вас есть список содер­жимого узла, вкратце опишите имеющуюся информацию. Постарайтесь разделить все данные на пять—семь категорий. Процесс разделения на категории принято называть формированием блоков (chunking). Число категорий ограничено тем, что интерфейс, представляющий более семи категорий, создать достаточно трудно, и соответствую­щий документ будет перегружен информацией. Составив краткое описание, переходи-, те к определению приоритетов данных. Решите, какая информация должна выделять­ся на экране и привлекать внимание пользователя и к каким данным пользователь должен иметь постоянный доступ.

Борьба с ошибками, допускаемыми при выборе информационной архитектуры

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

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

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

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

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

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

Перечисленные ниже правила помогут вам избежать ошибок, которые часто до­пускают разработчики архитектуры Web-узла.

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

• Помните, что пользователь не обязательно начинает знакомство с Web-узлом с его исходной страницы. Ссылки, расположенные на других узлах, могут привес­ти его к любому документу.

• Составляя план, выделите достаточно времени для разработки архитектуры узла.

Построение блок-схемы

Как нельзя построить дом без чертежей, невозможно создать высококачест­венный Web-узел без блок-схемы. На блок-схеме не должен отражаться внешний вид документов, блок-схема лишь представляет взаимосвязь между документами в составе Web-узла. Построив блок-схему, желательно ознакомить с ней заказчика; это поможет ему понять структуру Web-узла. Блок-схема иллюстрирует иерархию данных. Информация делится на уровни. Первый уровень соответствует общим категориям. Документы, принадлежащие пер­вому уровню, служат своеобразными указателями, обеспечивающими переход на сле­дующий уровень. На втором уровне вопросы, упомянутые на первом уровне, пред­ставлены более подробно. На этом же уровне реализованы указатели на документы третьего уровня, в которых представлена детальная информация и содержатся гипер­текстовые ссылки на другие источники. Помимо рассмотренных, в составе Web-узла могут присутствовать и другие уровни, однако не следует безосновательно увеличивать число уровней узла и гипертекстовых ссылок в составе документа.

Для построения блок-схемы можно воспользоваться любым графическим редакто­ром; лучше других для этого подойдут приложения, предназначенные для создания векторных изображений. Строить блок-схемы также позволяют некоторые HTML-редакторы, например Adobe GoLive. После того как вы определите собственный язык на основе доступных символов, данная программа автоматически рисует элементы блок-схемы, заполняет их текстом, выделяет уровни иерархии и обозначает взаимо­связь между документами,

План обновления содержимого узла

План обновления содержимого узла желательно составить на самых ранних стади­ях работы над узлом. World Wide Web представляет собой самую динамичную среду публикации информации, допускающую многочисленные изменения данных. План обновления составляется лишь в том случае, если в договоре предусмотрено не только создание и установка узла, но и его сопровождение. В плане обновления указывается, какие страницы или отдельные области должны подвергаться изменениям, когда из­менения должны вноситься, и источник нового содержимого Web-документов. Гра­фик поставки новых данных, который входит в состав плана обновления содержимо­го, обеспечивает равномерную загрузку специалистов, занимающихся модификацией информации, представленной на Web-узле.

Так, например, содержимое Web-узла кинотеатра должно обновляться каждую не­делю. Чтобы Web-мастер мог вовремя представить новые данные на узле, он должен получить их заблаговременно.

Требования к Web-узлу

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

Документ с требованиями к Web-узлу создается после принятия предложений за­казчиком. Этот документ позволяет вам убедиться в том, что заказчик предоставил вам все необходимые информационные ресурсы и вы правильно поняли потребности заказчика, связанные с созданием Web-узла. Документ с требованиями, подписанный заказчиком, уточняет детали, упущенные в предложениях, и уменьшает вероятность возникновения недоразумений в процессе работы над Web-узлом.

Подписание требований заказчиком означает окончание стадии проекта, предше­ствующей реальной работе над созданием Web-узла.

Документ с требованиями к Web-узлу должен предоставлять ответы на следующие основные вопросы.

• Какие ресурсы заказчик должен предоставить разработчику?

• Что необходимо разработчику для решения поставленной перед ним задачи?

• Что должен сделать разработчик в процессе выполнения проекта?

• Какие возможности должен предоставлять Web-узел?

Составление графика выполнения работ

После составления требований вам надо разработать график выполнения работ и согласовать его с заказчиком.

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

Почти все заказчики очень спешат. Не исключено, что от вас потребуют завершить проект в недельный срок. Если вас не устраивает перспектива составлять график ра­бот, исходя из такой конечной даты, объясните, что только для создания исходной страницы потребуется около десяти дней. Заказчик должен представлять себе реаль­ные сроки выполнения проекта. Если ему необходимо, чтобы Web-узел был установ­лен раньше, он должен быть готов к тому, что стоимость проекта резко возрастет. Объясните заказчику, что, для того, чтобы сократить сроки создания его Web-узла, вам придется изменить планы работы над другими проектами. Расскажите также о том, что, для того, чтобы завершить проект досрочно, его участники должны будут ра­ботать сверхурочно, а оплата за сверхурочные работы, как правило, выше обычной почасовой ставки сотрудников на 50%.

В процессе выполнения работ важно как можно точнее придерживаться графика. Если вы вовремя будете представлять заказчику промежуточные результаты, его доверие к вам возрастет. Убедитесь, что при составлении графика вы выделили достаточно времени для каждой работы и вам не придется думать о том, что же предпринять, чтобы уложиться в отведенный срок. Помните, что гораздо лучше с самого начала запросить у заказчика до­полнительное время, чем впоследствии не представить очередные результаты и приводить в качестве оправдания непредвиденные обстоятельства. Если вы будете стараться выпол­нить работу в спешке, ее качество неизбежно снизится. Имейте в виду, что вам, возможно, придется одновременно работать над несколькими проектами.

Разрабатывайте график работ так, чтобы каждая стадия выполнения проекта за­канчивалась получением конкретного результата. Это относится к этапу, предшест­вующему разработке, к этапу разработки, а также к этапу, следующему за окончанием разработки. В графике должна быть предусмотрена не только ваша работа, но также и действия, предпринимаемые заказчиком. Учитывая действия заказчика в графике, вы тем самым подчеркиваете тот факт, что заказчик является одним из участников рабо­ты над проектом. Необходимо оговорить, что невыполнение заказчиком своих обяза­тельств в срок является основанием для пересмотра всего графика работы над проек­том. Так, например, если заказчик не смог вовремя одобрить или отклонить представ­ленные материалы, сроки работ над остальными стадиями проекта, а следовательно, и время ввода Web-узла в строй, сдвигаются. С самого начала проинформируйте заказ­чика о том, что успех или неудача ваших работ во многом зависят от его действий.

Управление файлами

В процессе разработки Web-узла вы получаете большое количество материалов, представленных в различных форматах. Время, затраченное на организацию этих дан­ных, обязательно окупится впоследствии.

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

Соглашения по именованию файлов

Файлы, расположенные на Web-сервере, должны иметь расширения, отражающие формат содержащихся в них данных. Файл, содержащий код исходной страницы, практически всегда имеет имя index.html (index.htm, index.asp и т.д.). Докумен­ты, связанные с исходной страницей, также должны храниться в файлах с расширением .html, чтобы они могли быть корректно обработаны броузером. Изображения, звуковые и видеофайлы должны иметь трехбуквенное расширение, обозначающее формат данных, например .gif, ордили .трд.

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

Для того чтобы упростить поиск файлов или просмотр структуры каталогов, при­нято в именах файлов использовать сокращения, описывающие содержимое файлов. Так, например, в имени файла с фоновым изображением используется аббревиатура bg (backgroung), для описания страницы — рд (page). Для обозначения содержимого файла также используется позиция, которую данные занимают на странице, например top, bottom, left, right, main, side и footer.

Вкратце основные соглашения по именованию файлов могут быть сформулирова­ны следующим образом.

• Для хранения кода исходной страницы используются файлы index.html, index.htm, index.asp И Т.Д.

• Коды Web-страниц находятся в файлах с расширением . html или . htm.

• В именах файлов должны использоваться только символы нижнего регистра.

• Имена файлов должны отражать назначение их содержимого.

Управление проектом: основные понятия

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

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

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

Ниже описаны основные понятия, используемые при работе над проектом.

Проект. Некоторые усилия, организованные и направленные на выпуск товара или предоставление услуг. Каждый проект должен быть завершен.

Процесс. Действия по решению одной или нескольких задач, предпринимаемые многократно. Так, например, управление проектом — это процесс, который мо­жет быть условно разбит на четыре стадии: описание проблемы, планирование, реализация и завершение. Эти стадии характерны для каждого проекта.

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

Результат. Следствие предпринятых усилий — продукты или услуги, полученные при выполнении работ над проектом. Обычно разделяют конечный результат, предостав­ляемый заказчику, и промежуточный результат, полученный на одном из этапов вы­полнения проекта, и используемый для достижения конечной цели проекта.

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

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

Рабочая группа. Временный коллектив, организованный для выполнения неко­торой работы, например записи и редактирования видеоклипа. После заверше­ния работы рабочая группа распускается.

Контрольная точка. Встреча с заказчиком на некоторой стадии проекта, в ходе кото­рой выясняются вопросы, определяющие успех или неудачу проекта. Цель встре­чи — найти решение вопроса, которое обусловило бы успешное продолжение рабо­ты над проектом. Если ни одна из сторон не может предложить подходящее реше­ние, контрольная точка автоматически превращается в окончание проекта.

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

Инструменты планирования

При составлении планов часто используется специализированное программное обеспечение, например продукт Microsoft Proejct (MSP).

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

•  Планирование масштаба проекта. Формирование основы для последующих решений;

• Определение задач. Идентификация конкретных задач, которые должны выть выполнены для получения необходимых результатов.

• Определение последовательности задач. Определение взаимозависимости между различными задачами и планирование последовательности их выполнения.

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

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

• Планирование использования ресурсов. Определение объема ресурсов (число спе­циалистов, количество оборудования и материалов), необходимых для решения конкретной задачи.

• Оценка стоимости. Определение стоимости ресурсов, требующихся для выполне­ния работ по проекту.

Этапы выполнения проекта

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

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

Последняя часть работы над проектом — это этап, следующий за окончанием раз­работки, который включает тестирование узла, размещение его на Web-сервере и ор­ганизацию рекламы.

Web-узел должен быть тщательно протестирован несколькими сотрудниками. В про­цессе тестирования необходимо убедиться в отсутствии ошибок, разрушенных ссылок, а также в том, что набор реализованных операций достаточен для эффективной работы пользователя. Текст должен быть прочитан корректором. Каждый элемент узла и каждая гипертекстовая ссылка должны быть проверены с помощью различных броузеров на платформах Windows и Macintosh. Информация, полученная в результате тестирования, используется для модификации Web-узла. Затем необходимо скопировать Web-узел на Web-сервер и дважды выполнить его тестирование. И наконец, Web-страницы, входя­щие в состав узла, должны быть объявлены на основных поисковых серверах, таких как AltaVista, Lycos и Yahoo!. При необходимости выполняют дополнительные мероприятия по привлечению пользователей.

Резюме

Прочитав эту главу, вы узнали, что на этапе, предшествующем разработке, пред­принимается ряд действий, каждое из которых оказывает большое влияние на даль­нейший ход работ в рамках проекта. В результате первой встречи с заказчиком вы по­лучаете некоторое представление о его деятельности и о том, что именно заказчик ожидает получить в результате создания и установки Web-узла. В ходе первой встречи необходимо внимательно слушать представителя заказчика и задавать ему вопросы. При первой и последующих встречах с заказчиком определяется масштаб Web-узла. Далее в ходе работы над проектом предпринимается сеанс "мозгового штурма", в ре­зультате чего генерируются идеи о том, каким должно быть содержимое Web-узла.

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

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

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

• В процессе взаимодействия с заказчиком необходимо собрать как можно больше информации.

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

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

• Перед тем как приступать к разработке Web-узла, необходимо определить пред­полагаемый круг пользователей.

• Решение о масштабе Web-узла необходимо принимать совместно с заказчиком.

• Ознакомившись с Web-узлами конкурирующих организаций, вы можете соста­вить представление о том, как они представляют информацию в Web.

• Сроки выполнения и бюджет проекта необходимо согласовывать с заказчиком.

• Предложения разработчика должны соответствовать потребностям заказчика; их реализация должна решать проблемы заказчика.

Ещё посмотрите лекцию "17. Экологическое разнообразие современного человека" по этой теме.

• На этапе, предшествующем разработке, составляют блок-схему Web-узла.

• План обновления Web-узла составляют и согласовывают с заказчиком. При этом определяется роль разработчика в процессе обновления содержимого узла.

• Документ с требованиями определяет, что должен сделать заказчик и какие ре­зультаты разработчик должен предоставить заказчику.

• Для управления данными необходимо разработать систему хранения файлов.

• В процессе работы необходимо создавать резервные копии на различных носителях.

• Чтобы обеспечить своевременное выполнение работ, необходимо организовать эффективное управление проектом.