Порядок ведения работ и зоны ответственности участников проекта — это всегда то, что по-английски называется tailor-made — «индивидуальный пошив», то, что создается «по месту», зависит от положения дел на предприятии, опыта сотрудников, ресурсов и возможностей. Скажем, есть ли на предприятии человек, который способен вести интернет-проект? Есть ли у него время? Если такого человека нет, то одной из начальных задач рабочей группы станет его поиск: есть ли подходящая кандидатура внутри предприятия или лучше найти руководителя со стороны, привлечь ли внешнего исполнителя (отдать выполнение этой услуги на аутсорсинг). То есть решить кадровый вопрос.

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

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

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

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

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

Таблица. Состав работ и матрица ответственности для интернет-проекта

Условные обозначения:

• X — исполнитель;
• XX — вспомогательная роль;
• XXX — внешний исполнитель.

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

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

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

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

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

Таблица. Примерный состав рабочей группы проекта «Корпоративный веб-сайт»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица. Стадии жизни проекта «Корпоративный веб-сайт »

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

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

Таблица. Примерный регламент работы с информацией, заносимой на сайт

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

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

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

Мы определили видение будущего сайта. Что дальше? Какова дальнейшая роль подразделений в работе над сайтом, помимо разработки его образа? От образа перейдем к конкретике бизнеса.

Идеологические вопросы

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

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

Технологические вопросы

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

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

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

Существует несколько сложившихся де-факто неофициальных стандартов на дизайн интерфейсов, визуальный дизайн, дизайн навигации и т. п. Существует также официальный отраслевой стандарт консорциума W3C на верстку веб-страниц (http://www.w3c.org). При выборе веб-разработчика желательно понимать, будет ли он следовать этим стандартам. Однако это требует очень глубокого знания предмета и слишком пристального внимания к мелочам. Лучше обращать внимание на общее качество работ и управления проектом.

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

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

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

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

…добавьте свои эпитеты — в результате их должно быть не больше ста. Только избегайте слова «красивый»: постарайтесь уточнить, что именно скрывается за этим понятием. Например, для внешнего вида сайта здесь использованы эпитеты «роскошный», «изысканный», «стильный», «выдержанный», «современный», «наглядный», «элегантный». Выбирайте или используйте что-нибудь свое.

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

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

Кристина Вудке (Cristina Wodtke, архитектор Yahoo.com, создатель журнала информационных архитекторов Boxesandarrows.com), которая успешно применяет метод ранжирования эпитетов (я пользуюсь термином «метод эпитетов») для определения видения сайта, описывает дальнейшую работу так:

Вы собрали как можно больше разнообразных элементов и «выпарили» из них сущность. Теперь вам нужно взять эту сущность и сделать ее доступной людям, которые смогут уловить ваше видение (в нашем случае это разработчики, которым вы будете ставить задачу). Вы должны выразить, что это видение означает — например, если быстрота является частью вашего видения, стоит ясно выразить, что именно вы имеете в виду: быстроту загрузки (для инженеров это означает сконцентрироваться на оптимизации серверной части, для дизайнеров — избегать графики), иллюзию быстрой загрузки (для ваших веб-разработчиков — использовать способ progressive rendering) или быстроту просмотра (для ваших дизайнеров — сконцентрироваться на ясности). Пять слов, получивших наивысший рейтинг, станут столбовыми камнями для вашей работы. Вы также сможете позднее использовать эти пять слов при оценке юзабилити или для тестирования визуальных зацепок на сайте. Работая в Yahoo!, мы распечатывали этот список и вывешивали его на стену — чтобы не потерять фокус.

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

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

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

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

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

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

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

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

• Быстрая загрузка.
• Удобная система быстрой ориентации на сайте.
• Попятная архитектура (понятие «быстрый» смыкается с понятиями «попятный», «ясный», «четкий», и мы можем их объединить или выделить другой эпитет).

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

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

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

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

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

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

Это:

1. Подразделения, непосредственно работающие с потребителями как с основными целевыми группами бизнеса, — отделы маркетинга, продаж, внешнеэкономической деятельности, дистрибуции.
2. Подразделения, работающие со средствами массовой информации и с рекламой, — пресс-служба и отдел рекламы.
3. Отделы, отвечающие за сервисное обслуживание и поддержку потребителей, — сервисный центр, служба поддержки, call-центр.
4. Отдел, отвечающий за научное и техническое развитие, — центр разработок и инноваций, R&D: с одной стороны, он демонстрирует планку прогресса и обеспечивает имидж компании как эксперта в своей области, с другой стороны, работает с авторами разработок и инвесторами.
5. Обеспечивающие подразделения — отдел кадров, отдел АСУ, отдел поставок, материально-технического снабжения, логистики и т. п.
6. Руководство, которое отвечает за стратегию развития предприятия, за общее видение и за принятие решений.

В этом списке главный герой, именуемый руководителем интернет-проекта, не присутствует, ведь он не заинтересован в работе через корпоративный сайт. Его профессия — просто управлять сайтом. А раз этим подразделениям нужен сайт, им и карты в руки. Собираем из их представителей рабочую группу, выпускаем приказ о составе, регламенте и, самое главное, о статусе группы и приступаем к работе. Теперь корпоративный веб-сайт — это проект. С чего начнем? Давайте поиграем!

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

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

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

Защита инвестиций при создании сайта

Чтобы вы не теряли однажды вложенных в сайт денег, ваш сайт должен позволять:

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

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

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