Анар Бабаев, Николай Евдокимов, Михаил Боде Создание сайтов

Технический редактор Е. Семенова

Литературные редакторы О. Журавлева, Е. Семенова

Художник Л. Адуевская

Корректоры О. Андросик, И. Мивриньш

Верстка Л. Соловьева

© ООО Издательство «Питер», 2014

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

© Электронная версия книги подготовлена компанией ЛитРес (www.litres.ru)

Над книгой работали

Анар Бабаев – интернет-маркетолог и предприниматель. Генеральный директор Setup.ru. В интернет-рекламе с 2003 года. В соавторстве написал книги «Раскрутка. Секреты эффективного продвижения сайтов», «Кнопка Бабло» и «Контекстная реклама. Учебник». Соавтор следующих инструментов и сервисов: конструктор сайтов Setup.ru, сайт знакомств нового поколения Lovetime.com, модуль управления контекстной рекламой в системе SeoPult. Автор семинаров по интернет-маркетингу, Докладчик многих отраслевых конференций. Занимается освоением и практическим применением новых технологий в рекламе.

Николай Евдокимов – интернет-предприниматель, директор по развитию компании AppInTop, стратегический директор и сооснователь SeoPult. В 2004 году открыл компанию «Лаборатория контента». В 2006 году стал сооснователем интернет-холдинга Unmedia. В 2009 году запустил автоматизированную систему поискового продвижения SeoPult. В 2013 году стал директором по развитию компании AppInTop. Является соавтором книг «Контекстная реклама. Учебник», «Раскрутка. Секреты эффективного продвижения сайтов».

Михаил Боде – журналист, редактор. В 2003–2004 годах – выпускающий редактор интернет-издания «ВебИнформ». Впоследствии работал в журналах Upgrade и «Секрет фирмы», онлайн-издании Drive.ru, сотрудничал с ИД «Манн, Иванов и Фербер». В 2010–2012 годах – редактор программы «Рунетология», соавтор и редактор программы «Рунет сегодня» на «Финам FM». С 2012 года – главный редактор онлайн-телеканала SeoPult.TV. Соавтор книги «Раскрутка. Секреты эффективного продвижения сайтов».

Алексей Трошин – эксперт по веб-разработке и интернет-маркетингу. Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005-м, участвовал в развитии крупнейших порталов Рунета: «Авто. ру» и «Банки. ру», создавал первый российский интернет-магазин, вышедший на IPO, – «Ютинет. ру», участвовал в развитии SaaS-системы управления задачами «Мегаплан». Занимал пост директора по развитию системы Setup.ru. Профессионал в области гибкой разработки программного обеспечения.

Анастасия Андреева – специалист по юзабилити. Работала над сайтами Rabota.ru и Joblist.ru. Аналитик и разработчик интерфейсов в ряде проектов, включая центр дистанционного обучения Xerox, сайты Группы ВТБ, Юниаструм-банка и Олимпиады в Сочи – 2014, мобильные приложения для платежной системы Wellpay! Аналитик и консультант по юзабилити в проектах разной тематики. Специализируется на нестандартных задачах, аудитории. Вела рассылку Setup.ru.

Алексей Пучков – руководитель Setup.ru. Первый сайт создал в 1997 году. С тех пор профессионально занимается интернет-проектами. Имеет более 50 успешно реализованных проектов. Работал в крупнейших интернет-холдингах Рунета, владел собственным онлайн-бизнесом. В настоящее время – руководитель проекта Setup.ru.

Константин Козлов – руководитель техподдержки Setup.ru.

Олеся Егозина – руководитель отдела тестирования Setup.ru.

Особую благодарность выражаем Анастасии Подгорновой – художнику, автору обложки.

(обратно)

Предисловие. Для кого эта книга и какая от нее польза

В названии нашей книги кроется легкая провокация. Казалось бы, если создание сайта – это просто, зачем одни люди готовят и выпускают огромные бумажные «кирпичи», в которых досконально разбираются технологии веб-разработки, а другие охотно покупают эти фолианты? Уж не хотим ли мы сказать, что наше практическое руководство, притом не самое толстое, одним махом побьет все прочие издания той же тематики, включая энциклопедические? Ни в коем случае. Но соль в том, что львиная доля книг в секциях «Компьютеры и Интернет» не про то, как открыть сайт.

Вы сейчас находитесь в книжном магазине? Зайдите в отдел «Строительство и ремонт» или «Дизайн». Или, если сидите за компьютером, откройте сайт Ozon.ru и загляните в соответствующую рубрику. Полистайте одно издание, другое, третье. Едва ли хоть в одном из них вы найдете подробную инструкцию о том, как стать маляром, штукатуром или каменщиком. Большей частью даже справочная литература, за вычетом малотиражной узкоспециализированной, не содержит таких рекомендаций. Вы прочтете про выбор материалов, про то, как работать с архитектурным планом, как развить свой вкус, чувство стиля, но не про «курс молодого кровельщика». Зато в отделе компьютерной и околокомпьютерной литературы сплошь конкретика: учебники по языкам программирования PHP, JavaScript, Perl, по серверным технологиям, по графическим редакторам Photoshop и Adobe Illustrator. Впору впасть в эйфорию: бери да учись, делай все сам – пошаговые инструкции прилагаются. Однако, как ни парадоксально, благодаря полученной информации велик риск оказаться в ловушке. Вы покупаете очередной «самоучитель PHP» и вдруг по вскользь оброненным словам автора понимаете, что неплохо бы овладеть искусством настройки сервера – нужны еще одна-две книги. Потом, как оказывается, надо изучить веб-верстку, стандарты HTML5, таблицы CSS3. И наконец, вы осознаете, что штудировать надо было не PHP, а, скажем, Ruby. Да и теория объектно-ориентированного программирования не помешает. А к созданию сайта приступить так и не удалось: знания еще не капитальные и столько всего нужно усвоить.

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

Секрета никакого нет. Для того чтобы создать сайт, нужны не технические навыки, а управленческие. Сайтостроительство в его современном виде – это давно не забава «сделай все сам», а комплекс разнородных работ, которые, во всяком случае для новичка, неподъемны. Но если знать, какие действия входят в цикл веб-разработки, и понимать критерии, определяющие качество выполнения задач, и разбираться в том, какое дело кому поручить, цель становится достижимой. Ваша задача – грамотно координировать действия исполнителей, каждый из которых будет профи в своем деле, и, видя картину в комплексе, выдерживать общую линию. Разумеется, воображение и смекалка вам тоже понадобятся: чтобы сделать красивый, простой и при этом затягивающе привлекательный сайт, нужно знать фундаментальные принципы веб-разработки, но куда важнее интеллект и здравый смысл.

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

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

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

Для восприятия текста не требуется технических навыков. Термины и понятия, обойтись без которых никак нельзя, мы по мере сил расшифровываем сразу же, в тексте, или приводим ссылки на источники, в которых сложные темы растолкованы доступным языком. И главное, в книге нет длиннющих «простыней» с программным кодом. Не то чтобы мы намеренно задались целью отказаться от цитирования скриптов и команд (например, кое-где мы все-таки упоминаем теги), как знаменитый ученый и популяризатор науки Уильям Хокинг в своей «Краткой истории времени» решил обойтись без математических формул. Мы постарались сделать так, чтобы они были просто не нужны в повествовании: положа руку на сердце, признаем, что человеку, не являющемуся профессиональным веб-мастером или программистом, такие пассажи не дают толком ничего, кроме сладкого чувства причастности к высокой IT-кухне либо, напротив, грустного недоумения. Помимо всего прочего, технологии имеют свойство устаревать. Ну а методы планирования и управления командами меняются медленнее.

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

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

(обратно)

Дело техники

Глава 1. Техзадание: последний раз себя спрашиваю!

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

Для чего нужно техническое задание

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

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

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

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

Обратите внимание

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

Последовательность действий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что должно входить в техническое задание

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

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

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

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

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

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

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

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

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

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

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

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

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

Как оно выглядит

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

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

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

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

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

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

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

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

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

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

Полезно знать

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

Глава 2. Создание прототипа: анатомия сайта

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

Что такое прототип

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

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

Кому нужны прототипы

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

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

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

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

Какую пользу приносит прототип

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

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

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

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

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

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

Разновидности прототипов

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

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

• Wire-frame – то же, что блок-схема (рис. 3). Она простейшим образом показывает, какие модули содержит сайт и как они увязываются в единую структуру. Формы – прямоугольные, гамма – обычно монохромная, характер – аскетический. В отличие от интерактивного прототипа (см. далее), классическая блок-схема фиксирует самый общий вид страницы в статике. Как следствие, чтобы было ясно, что должно происходить при работе с каким-нибудь нетривиальным динамическим элементом, зачастую требуются чрезвычайно подробные текстовые ремарки.

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

^{Рис. 3. Прототип главной страницы Setup.ru, выполненный с помощью сервиса Axure}

• Мокап (от англ. mock-up – «полноразмерный макет») – строго говоря, не вполне прототип. Вернее даже, без пяти минут сайт. Как правило, подразумевает близкий к финальному вид каждой страницы, однако статичен и лишен интерактивности. Посмотреть, но не «пощупать». Большое достоинство мокапа в том, что его чаще воспринимают всерьез многие заказчики – в противовес аскетичным прототипам («Пф, что за казаки-разбойники со стрелочками вместо сайта?»). Если мокап всплывает в проекте, то либо в начале, либо в конце его реализации: в первом случае – когда требуется убедить заказчика в том, что разработчики не оторваны от реальности и видят возможные «инкарнации» сайта задолго до его рождения, во втором – когда нужно подтвердить, что прототип удачно облачен в дизайнерские одежды. Далее мокапы уместны в том случае, если заказчику трудно воспринимать абстрактные концепции в отрыве от их конкретного воплощения (а прототип – это абстракция).

Тестирование прототипов

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

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

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

• Тепловые карты. Самый популярный в Рунете инструмент для составления тепловых карт сайта входит в сервис «Яндекс. Метрика». Наглядно, цветовым выделением с плавной градацией (интуитивно понятное «горячо – холодно») показывается, насколько часто посетители страницы щелкают мышью по различным элементам интерфейса или переходят по тем или иным ссылкам, охотно ли прокручивают страницу вниз и т. д. Учтите, что на страницах, где вы хотите увидеть тепловые карты, должен быть установлен счетчик «Яндекс. Метрики».

Обратите внимание

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

Кто должен создавать прототипы

Схематичную «раскадровку» сайта должен выполнять отдельный специалист, например эксперт по юзабилити (см. далее подраздел «Юзабилити и здравый смысл») или аналитик. Распространено ошибочное мнение, что прототипирование – исключительно дело менеджера проекта или дизайнера. Тем не менее куда правильнее делать прототип, ориентируясь на представителя целевой аудитории. Между тем менеджер проекта прежде всего озабочен тем, чтобы состыковать желания заказчика с представлениями разработчиков, а дизайнер лишь при огромном опыте в сайтостроительстве способен примирить свою тягу к красоте с удобством навигации и совершенством архитектуры.

Будем отталкиваться от того, что в идеале создание прототипа не дополнительный, а обязательный этап разработки сайта. Прототип не заменяет техническое задание, а иллюстрирует его или служит его логическим развитием, будучи еще одной ступенькой к готовому сайту. Часто дизайнер, особенно с опытом в UX^[4], клянется и божится, что прототип ему без надобности и все промежуточные процессы у него проистекают «в голове». Не верьте. В абсолютном большинстве случаев они появляются из ниоткуда и пропадают в никуда. Вместе с вашими деньгами.

Как делать прототипы

Точка отсчета в прототипировании

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

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

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

Рабочий процесс

Резонно, чтобы перед глазами у проектировщиков всегда была общая картина сайта. Вне зависимости от того, какой инструмент используется для прототипирования, очень удобно начинать с функциональной структуры сайта в mind maps, или ассоциативных картах (см. главу 1 «Техзадание: последний раз себя спрашиваю!» и рис. 2). Полезно, чтобы файл с mind map был на «Рабочем столе» (или, например, в онлайн-сервисе типа Mindmeister.com) у вас и всех, кто занят в проекте. Как-никак дельно составленная ассоциативная карта отражает всю структуру и функциональность сайта.

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

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

Юзабилити и здравый смысл

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

В одном абзаце принципы юзабилити не изложить, и мы подробнее остановились на них в главе 16 «Юзабилити и конверсия: заставляем сайт работать». Приведем для примера несколько фундаментальных принципов. Так, установлено, что люди обычно осматривают экран слева направо и сверху вниз, отсюда и предписание самую важную информацию, включая навигационные блоки, по возможности размещать близко к точке, с которой начинается обзор. Основные элементы меню и ссылки в идеале доступны без прокрутки страницы вниз. До всех мало-мальски значимых страниц посетитель – не всегда, но как правило – должен добираться в худшем случае за три клика. Другие общие рекомендации по юзабилити перечислены, например, в тематическом выпуске рассылки SeoPult (см. блок «Полезно знать»).

Учитывайте в прототипе ровным счетом все, что желаете видеть на своем сайте. Планируете размещать баннеры? Значит, выберите где. Да и величину их следует знать заранее. «Баннеры потом впихнем под шапку и справа» – это скорее печально, чем забавно. Один баннер, другой, и часть навигационных элементов очутится за «линией сгиба», на втором экране, до которого и не всякий-то посетитель доберется.

Тип сайта, конечно, диктует исполнение интерфейса. Вместе с тем многие решения, несмотря на единичные яркие исключения, являются стандартом де-факто в современной веб-разработке, например расположение логотипа и строки поиска. Чтобы не изобрести ненароком велосипед, тем более восьмиколесный с рулем на багажнике, желательно, повторимся, ознакомиться с азами юзабилити (см. блок «Полезно знать»).

Не менее строго, чем к структуре сайта, стоит относиться к тому, как подается в прототипе контент. И безразлично – онлайн-медиа вы открываете или фотохостинг. Категорически противопоказано писать: «Здесь текст и красивые картинки». Обозначьте, где конкретно и в скольких колонках должен располагаться текст, а где картинки и каких они размеров.

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

Нумеруйте страницы в прототипе, и вам зачтется. Так же как, соединяя точки в детской книжке – от первой ко второй, от второй к третьей и т. д., – вы постепенно начинали видеть рисунок, из последовательности страниц вы выстраиваете маршрут посетителя по своему сайту. Что без недвусмысленных маркеров спланировать затруднительно. При «бумажном» прототипировании нумерация и вовсе незаменима.

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

Границы возможностей прототипа

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

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

Принцип самодостаточности

Прототип должен быть понятен людям, которые увидят его впервые в жизни. Собственно, в индустрии сайтостроительства по мере достижения ею зрелости увеличивается число компаний и команд, чья компетенция сводится к тому, чтобы в качестве конечного продукта выдавать прототип, по которому другая компания или команда будет писать код и рисовать дизайн сайта (взгляните, например, на Prototype.ru).

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

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

Средств для создания прототипов великое множество. Чтобы ответить на вопрос «Какое предпочесть?», нужно сперва понять, кто будет делать прототип и в каких целях. Весомая доля веб-разработчиков использует Axure RP Pro. Немало дизайнеров отдает предпочтение Adobe Fireworks. Популярен и Balsamiq (рис. 4). Большая часть онлайновых сервисов такого рода дает возможность загрузить прототип на сервер, с помощью пароля преградив доступ к нему случайным «прохожим», и провести испытания в обстановке, приближенной к боевой.

^{Рис. 4. Интерфейс сервиса для создания прототипов Balsamiq}

Интерактивные прототипы

axure.com

adobe.com

flairbuilder.com

foreui.com

guimachine.ru

proto.io

pidoco.com

protoshare.com

Скетчи, мокапы

balsamiq.com

mockupbuilder.com

gomockingbird.com

iphonemockup.lkmc.ch

Полезно знать

«Прототип: бумажный или интерактивный?»: http://www.cossa.ru/articles/155/40512/

О картах кликов в «Яндекс. Метрике»: http://help.yandex.ru/metrika/behavior/click-map.xml

Советы по работе с Axure RP Pro: http://habrahabr.ru/post/101938/

«Рейтинг решений для прототипирования и проектирования сайтов, используемых в веб-студиях и интернет-агентствах России»: http://2011.tagline.ru/prototype/

«Рассылка SeoPult. Выпуск № 120: юзабилити сайта»: http://seopult.ru/subscribe.html?id=125

«Рассылка Setup.ru. Выпуск № 53: создание прототипа»: http://www.setup.ru/client/subscription/114

«Рассылка Setup.ru. Выпуск 44: A/B-тестирование»: http://www.setup.ru/client/subscription/93

Стив Круг. Веб-дизайн, или Не заставляйте меня думать!: http://www.ozon.ru/context/detail/id/3795618/

Влад Головач. Дизайн пользовательского интерфейса. Искусство мыть слона: http://uibook2.usethics.ru

Глава 3. Работа с фрилансерами: freelance, freelove

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

Что касается работы с фрилансером, почти все ее риски и доходы зашифрованы в самом определении этого человеческого и профессионального типа. Фрилансер (англ. freelancer – «вольный наемник») – это внештатный специалист, как правило, трудящийся дистанционно и выполняющий единичные задачи для различных заказчиков, иногда – для круга постоянных подрядчиков. Он рассчитывает только на себя, что зачастую мешает другим безоговорочно рассчитывать на него.

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

Какие бывают фрилансеры

Вступить на стезю вольного художника может представитель любой из «сайтостроительных» профессий: дизайнер, веб-программист, верстальщик, менеджер проекта, проектировщик интерфейсов, SEO-оптимизатор, тестировщик и т. д. Часто один фрилансер выступает сразу в нескольких амплуа, но, например, кодер и иллюстратор в одном лице – либо экспонат кунсткамеры, либо уникум. Эпоха веб-мастеров на все руки канула в Лету вместе с сайтами, целиком написанными в «Блокноте» за две ночи. Нанимать мастера на все руки – затея архивредная. Пытаясь найти добряка-водяного, который поможет вам построить летучий корабль, как в одноименном мультфильме, вы скорее подцепите пиявок, сосущих вашу кровь и деньги.

Если вы сделаете выбор в пользу фриланса, вам понадобятся как минимум два работника разного профиля: дизайнер и веб-программист. Промежуточные варианты не исключены (рисует сайт фрилансер, «собирают» его в студии, а поисковым продвижением занимаетесь вы сами с помощью сервиса наподобие SeoPult), но обычно более головоломны.

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

Когда обращаться к фрилансеру

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

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

Обратите внимание

Менеджера проекта по созданию вашего сайта тоже можно нанять как фрилансера. Иногда это спасает ситуацию.

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

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

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

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

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

Фрилансер мечты

При воспоминании о сотрудничестве с фрилансерами кто-то плюется, а кто-то удовлетворенно хмыкает. Первых больше, и к тому есть предпосылки. Риск нарваться на неквалифицированного «дизайнера-надомника» или «программиста из 8 А класса» выше, чем если, например, вы выбираете веб-студию из числа участвующих в каком-нибудь авторитетном отраслевом рейтинге. Не останавливаясь на какой бы то ни было отдельной профессии, попробуем составить фоторобот идеального фрилансера.

• «Фриланс – это судьба». Не имеет штатной работы и живет на вольных хлебах не первый год. «Тру-фрилансер» трезво оценивает свои силы, ввиду опыта умеет определять сроки выполнения задач, научился не взваливать на себя неподъемную ношу (сделать туристический портал с геолокационными сервисами за полтора месяца, притом что параллельно пытается клепать три принципиально разных интернет-магазина). Совместители, днем трудящиеся в офисе, а вечерами халтурящие, в среднем менее надежны, слабее мотивированы денежным вознаграждением за сдельную работу и более склонны срывать дедлайны^[5]. Хрестоматийный диалог с «полуфрилансером»:

– Вячеслав! Вы третий день не выходите на связь. Прототип вы должны были показать мне еще в прошлую среду.

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

– Но мне надо открывать магазин в начале следующего месяца! У нас только по детским книжкам предзаказ – на двадцать семь тысяч с гаком. Думаю, будет справедливо удержать у вас 5 % гонорара. Мы эту меру обговаривали.

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

• Владеет азами тайм-менеджмента^[6]. Толковый фрилансер ни в коем случае не возьмет работы больше, чем ему удастся выполнить за оговоренные сроки. Желательно, чтобы большую часть дня в оговоренный период он занимался вашим проектом. И конечно, он должен находиться на связи либо на протяжении всего рабочего времени в будни, либо в часы, которые вы вместе с ним утвердили как отчетные.

• Обладает опытом для выполнения необходимых вам задач. Бесспорно, заслуживает уважения разработчик, который сделал великолепный отказоустойчивый сервис аренды автомобилей. Но что вам толку в его достижениях, если он никогда не создавал интернет-магазины на Drupal 7, а вам в лучших традициях дедлайн-триллеров нужно было довести до ума кривую работу однокурсника – угораздило же довериться ему – еще вчера? Разумнее взять в оборот веб-мастера, не хватающего звезд с неба, но настроившего штук двадцать торговых площадок на вышеупомянутой CMS.

Обратите внимание

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

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

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

• «Не великие таланты, но понятны и просты». Вам нужен не гуру, а тот, кто успешно выполнит поставленные вами задачи. Добросовестный фрилансер не пытается заумно, используя технический жаргон, маскировать свои слабые места и умеет говорить простыми словами о сложном. Навязывает вам в первом же разговоре мысль о сакральном смысле префиксов переменных в языке Delphi? Давай, до свидания!

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

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