Проект сайта
Проект сайта
С чего начать?
Работу над большинством 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-узла составляют и согласовывают с заказчиком. При этом определяется роль разработчика в процессе обновления содержимого узла.
• Документ с требованиями определяет, что должен сделать заказчик и какие результаты разработчик должен предоставить заказчику.
• Для управления данными необходимо разработать систему хранения файлов.
• В процессе работы необходимо создавать резервные копии на различных носителях.
• Чтобы обеспечить своевременное выполнение работ, необходимо организовать эффективное управление проектом.