Фраза «Сайт – это бизнес-инструмент» обычно используют в отношении компании-владельца. Это правда, поэтому и начинать работу нужно с бизнес-аналитики: определить, для каких целей используется сайт, какие бизнес-задачи может решать, каким подразделениям нужен, как они смогут использовать его для увеличения эффективности своей работы. Однако важно знать, что успешный сайт в первую очередь выглядит как бизнес-инструмент для другой стороны баррикад – для клиентов. Ключевое слово – «выглядит»: все цели владельцев завуалированы, на первый план выведены сервисы для клиентов, пользуясь которыми, посетители приносят выгоду владельцам. И «выглядит» не мешает быть на самом деле.
Сайт – это проект
Сайт должен иметь системное управление, и эта функция не может быть передана на аутсорсинг. На предприятие это накладывает необходимость иметь обученного руководителя интернет-проекта, а также регламент работы для всех подразделений компании, работающих с приемом или поставкой информации целевым потребителям.
Защита инвестиций при создании сайта
Чтобы не терять однажды вложенных денег, сайт должен позволять:
- Простым способом помещать информацию – через простой и понятный пользовательский интерфейс, через автоматическую связь с другими информационными системами компании. Благодаря этому не нужно держать в штате специалистов, владеющих навыками веб-разработки, «веб-мастеров», а информация будет попадать на сайт быстрее.
- Легко наращивать функциональность сайта, изменять его структуру, внешний вид, концепцию, не изменяя кардинально программное обеспечение. Каждый раз должна делаться только та работа, которая действительно необходима: например, оплачивать только работу кодировщика, а не всего штата студии веб-разработки.
- Поддерживать наиболее устойчивые, распространенные и перспективные стандарты на техническое решение.
Поддержка широко распространённых стандартов снизит затраты на внедрение новых модулей, на организацию обмена информацией с другим программным обеспечением, интернет-ресурсами, корпоративными системами, на масштабирование, развитие и перенос сайта.
- Работать с веб-разработчиками, имеющими устойчивое положение на рынке, тщательно их выбирать, выстраивать партнерские отношения. Вам неминуемо понадобится вносить изменения и развивать сайт на уровне программных, пользовательских, дизайнерских решений. Выбирая разработчика сайта, вы выбираете партнера в долгосрочной перспективе.
Какие подразделения заинтересованы в работе через сайт
Самое полное представление о том, какие бизнес-задачи способен решать сайт, с какой стороны ни взглянуть, бизнеса или его целевой аудитории, может дать анализ целей бизнес-подразделений компании. Ведь именно подразделения работают на передовой линии и лучше всего знают, что нужно им самим и их подопечным. Вот и начнем работу над будущим сайтом с того, что еще раз уточним, какие же подразделения могут быть заинтересованы в работе со своими целевыми группами через сайт?
Это подразделения:
- непосредственно работающие с потребителями как с основными целевыми группами бизнеса – отделы маркетинга, продаж, внешнеэкономической деятельности, дистрибуции.
- работающие со средствами массовой информации и с рекламой – пресс-служба и отдел рекламы.
- отвечающие за сервисное обслуживание и поддержку потребителей – сервисный центр, служба поддержки, call-центр.
- отвечающие за научное и техническое развитие – центр разработок и инноваций, R&D: с одной стороны, он демонстрирует планку прогресса и обеспечивает имидж компании как эксперта в своей области, с другой стороны, работает с авторами разработок и инвесторами.
- обеспечивающие – отдел кадров, отдел АСУ, отдел поставок, материально-технического снабжения, логистики и т.п.
- руководство, которое отвечает за стратегию развития предприятия, за общее видение и за принятие решений.
В этом списке главный герой книги, руководитель интернет-проекта, не присутствует, ведь он не заинтересован в работе через сайт. Просто управлять сайтом – это его профессия. А раз этим подразделениям нужен сайт, им и карты в руки. Собираем из их представителей рабочую группу, выпускаем приказ о составе, регламенте и, самое главное, о статусе группы, и приступаем к работе. Теперь корпоративный веб-сайт – это проект. С чего начнем? Давайте поиграем!
Определение видения сайта. Метод эпитетов
Игра будет очень простой, занимательной и внешне совсем несерьезной. Для начала, возьмем вот такую таблицу:
Таблица 1.1. Шаблон для создания видения сайта методом эпитетов
| N | Эпитет | Маркетинг | Продажи | Дистрибуция | ВЭД | Реклама | PR |
| 1 | Простой | ||||||
| 2 | Ясный | ||||||
| 3 | Строгий | ||||||
| 4 | Быстрый | ||||||
| 5 | Выдержанный | ||||||
| 6 | Солидный | ||||||
| 7 | Изысканный | ||||||
| 8 | Роскошный | ||||||
| 9 | Ценный | ||||||
| 10 | Целесообразный | ||||||
| 11 | Логичный | ||||||
| 12 | Понятный | ||||||
| 13 | Актуальный | ||||||
| 14 | Современный | ||||||
| 15 | Полезный | ||||||
| 16 | Стильный | ||||||
| 17 | Профессиональный | ||||||
| 18 | Информативный | ||||||
| 19 | Функциональный | ||||||
| 20 | Оперативный | ||||||
| 21 | Точный | ||||||
| 22 | Рабочий | ||||||
| 23 | Насыщенный информацией | ||||||
| 24 | Удобный | ||||||
| 25 | Наглядный | ||||||
| 26 | Располагающий | ||||||
| 27 | Оперативный | ||||||
| 28 | Экономящий время | ||||||
| 29 | Четко работающий | ||||||
| 30 | Надежный | ||||||
| 31 | Безопасный | ||||||
| 32 | Передовой | ||||||
| 33 | Продуманный | ||||||
| 34 | Лаконичный | ||||||
| 35 | Вызывающий доверие | ||||||
| 36 | Элегантный |
… добавьте свои эпитеты – в результате должно получиться не больше ста. Только избегайте слова «красивый»: постарайтесь уточнить, что именно скрывается за этим понятием. Например, для внешнего вида сайта здесь использованы эпитеты «роскошный», «изысканный», «стильный», «выдержанный», «современный», «наглядный», «элегантный». Выбирайте или используйте что-нибудь свое.
На этом этапе не нужно делить эпитеты по группам: скажем, это к оформлению относится, а это к быстродействию. С помощью этой таблицы мы будем создавать образ сайта, его видение, фокус для дальнейшей работы. А разбиение по группам и затем распределение задач по специалистам – это отдельная работа: закончится она на этапе постановки задачи веб-разработчику. Вместе с ним вы обсудите каждый пункт вашего видения и вместе уточните, как будет реализован тот или иной эпитет. Фактически, вы будете создавать общее видение успешного проекта, а значит, и некоторые критерии успешности. Разработчик будет производить преобразование общего видения в конкретную техническую реализацию, реализовывать стоящую перед ним задачу и затем сдавать ее вам, и ему не меньше, чем вам, необходимо выработать критерии успешности. Скажем, эпитет «быстрый» может означать:
- хорошее юзабилити, т.е. возможность быстро найти на сайте нужную информацию;
- быструю загрузку страниц, что влечет за собой разработку так называемого «информационного», или «текстового», дизайна;
- быструю перезагрузку страниц, т.е. применение клиент-серверных технологий и технологий типа Java Script, и т.п.;
- быстрый доступ к содержимому, т.е. соблюдение очередности в загрузке элементов страницы – сначала загружать элементы навигации и текстовое содержимое, а затем элементы оформления.
Cristina Wodtke (информационный архитектор Yahoo.com, создатель журнала информационных архитекторов Boxesandarrows.com), которая успешно применяет метод ранжирования эпитетов (я пользуюсь термином «метод эпитетов») для определения видения сайта, описывает дальнейшую работу так:
«Вы собрали как можно больше разнообразных элементов и “выпарили” из них сущность. Теперь вам нужно взять эту сущность и сделать ее доступной людям, которые смогут уловить ваше видение (в нашем случае это разработчики, которым вы будете ставить задачу). Вы должны выразить, что это видение означает – например, если быстрота является частью вашего видения, стоит ясно выразить, что именно вы имеете в виду: быстроту загрузки (для инженеров это означает сконцентрироваться на оптимизации серверной части, для дизайнеров – избегать графики), иллюзию быстрой загрузки (для ваших веб-разработчиков — использовать способ progressive rendering) или быстроту просмотра (для ваших дизайнеров – сконцентрироваться на ясности). Пять слов, поучивших наивысший рейтинг, станут столбовыми камнями для вашей работы. Вы также сможете позднее использовать эти пять слов при оценке юзабилити или для тестирования визуальных зацепок на сайте. Работая в Yahoo!, мы распечатывали этот список и вывешивали его на стену – чтобы не потерять фокус»[1]
Итак, во втором столбце мы разместили эпитеты, описывающие сайт – их может быть до сотни, но не меньше тридцати. Теперь попросим сотрудников отобранных подразделений проставить свою оценку в баллах для каждого эпитета. Только не передавайте этот список от сотрудника к сотруднику так, чтобы каждый последующий видел мнение предыдущего: вам нужно личное мнение каждого, ведь у каждого из них свой личный опыт работы с клиентами и свое понимание того, что именно клиентам нужно от сайта. Обобщить этот опыт и выделить из него самое важное и есть ваша задача.
Дальше в столбцах вы проставите суммарную оценку важности каждого эпитета, по мнению сотрудников каждого отдела. Получится очень важный документ: он отражает фокус работы над разделами сайта для каждого отдела. Если фокус будет сильно различаться, возможно, придется принимать решение о создании не одного, а группы сайтов: например, корпоративного сайта (вотчина PR-службы), версии на иностранных языках (для отдела ВЭД), промо-сайта для продвижения отдельных продуктов компании (для рекламного отдела), сайта для проведения закупок (для отдела снабжения), интернет-магазина (для отдела продаж) и закрытого сайта для работы с дистрибуторами. Однако обычно большинство этих задач успешно решается внутри одного сайта. Теперь отберем пять эпитетов, получивших высшую оценку. Можно просуммировать по строкам баллы и отобрать те эпитеты, которые заняли первые пять мест. Познакомьте всех, кто участвовал в процессе, с его результатами. Теперь вы решили очень важную задачу: вы подготовили почву для создания сайта, который отвечает задачам компании. А кроме того, подготовились к выбору разработчика – выбор разработчика, в том числе, будет производиться с учетом вашего видения сайта и понимания, может ли тот или иной разработчик воплотить это видение в жизнь.
Мы познакомились с закрытым методом эпитетов. Его преимущество в том, что мы не заставляем людей фантазировать и формулировать, ведь иногда это вызывает затруднения. Хороший список эпитетов включает максимально возможный набор, из которого всегда можно выбрать свой образ. Более простое и быстрое применение метода эпитетов, которое даст «облегченное», хотя, возможно, более сжатое и точное видение сайта, производится в открытой форме. В этом случае вы просите все заинтересованные подразделения дать свою тройку-пятерку эпитетов и аккумулируете их в один общий список, а затем так же производите голосование и ранжирование эпитетов из полученного списка. В самом упрощенном варианте, если вы имеете дело с одним-единственным человеком (например, владельцем малого бизнеса), общий список будет равен одному частному списку. Дальнейшие действия те же, что и для «закрытого» варианта: вы производите преобразование эпитетов в качества сайта (декомпозицию) на уровне уточнения пожеланий подразделений, но не вмешиваясь в конкретные действия разработчика по технической реализации.
Еще один вариант проведения отбора эпитетов и голосования, который максимально сокращает время разработки и описания образа – это вариант с использованием мозгового штурма (можно использовать и открытую, и закрытую формы). Большое его преимущество – это возможность сразу же прояснить формулировки и развернуть интересную дискуссию, поучить максимально полный и взаимно разделяемый образ. И при этом работа над видением может сократиться всего лишь до одного-двух часов. Вам понадобится большая доска или флипчарт, бумага (список эпитетов для закрытого варианта), пишущие инструменты, круглый стол и опытный эксперт-модератор. Нужно жестко соблюдать последовательность действий: попросите всех участников записать свой список из 3-5 эпитетов или отметить эпитеты в бланке (листочки должны сохраняться перед глазами участников до конца процесса), после чего попросите по очереди каждого огласить свой перечень и сформируйте общий список по мере оглашения эпитетов на доске. Затем проведите подсчет голосов и обсудите пять самых популярных эпитетов. В первую очередь высказываться должны те участники, которые предлагали варианты, ставшие популярными (для этого и нужно сохранять листочки). После этого давайте слово остальным. Попутно предлагайте другие варианты расшифровки, их тоже обсуждайте. Самый явный претендент на неоднозначность расшифровки, который почти обязательно окажется в итоговом списке, это эпитет «быстрый»: вы должны разобрать его (как и некоторые другие эпитеты) во всех возможных ипостасях, однако, как мы помним, не переходя на уровень технической реализации. Опытный модератор, который хорошо разбирается в теме, поможет четко, без лишних трат времени, организовать обсуждение, привести его к конечному итогу и не дать «захватить власть» одному лидеру мнений – нет ничего опаснее лидера мнений, тем более некомпетентного (сам себя он некомпетентным никогда не считает). В заключение разбора по каждому попавшему в топ-5 эпитету обязательно формулируйте резюме, окончательную расшифровку, которая принята участниками штурма. Эта формулировка должна попасть в протокол, который фактически состоит из двух частей: начального топ-5 и соответствующих расшифровок. Довольно часто популярные и непопулярные варианты являются одним и тем же, высказанным разными словами.
Для примера снова возьмем эпитет «быстрый». Допустим, это слово попало в ваш список – а это произойдет почти наверняка. Вы спрашиваете у инициатора: что вы имели в виду? В ответ вы можете услышать: быстрое перемещение по сайту; чтобы сайт долго не грузился; чтобы можно было быстро найти информацию. Систему задач можно расписать следующим образом:
- Быстрая загрузка.
- Удобная система быстрой ориентации на сайте.
- Понятная архитектура (понятие «быстрый» смыкается с «понятный», «ясный», «четкий», и мы можем их объединить или выделить другой эпитет).
Обсуждая получившиеся задачи, вы выходите на объективное решение, что же такое удобная ориентация, быстрая загрузка или понятная архитектура конкретно для вас и ваших целевых групп, и эти особенности должны дополнить приведенный выше список. Если мы получаем список эпитетов, расписанный в таком виде, в дальнейшем контролировать работу разработчиков будет проще (а это одна из проблемных зон управления интернет-проектом).
Еще одно важное и эффективное применение метода эпитетов – при редизайне сайта, т.е. при переделке старого сайта компании: смене его внешнего оформления и внутреннего устройства. В этом случае вы сначала должны определить видение старого сайта: тот образ, который сложился у его пользователей и экспертов. Попросите несколько человек из групп пользователей и экспертов (консультанта, нескольких разработчиков) в нескольких словах выразить их впечатление от существующего сайта. Если это видение кардинально расходится с тем, что вы хотите получить от сайта, вам не нужно будет долго убеждать руководство в том, что сайт нуждается в переделке – просто предъявите ему сторонний взгляд. Ведь образ сайта часто переносится и на компанию, и если он описывается посетителями как «непрофессиональный», «неудобный», «непродуманный», «морально устаревший», «провинциальный» – никаких других аргументов уже не нужно. Имейте в виду, что при определении образа старого сайта с помощью метода эпитетов важно не столько мнение членов рабочей группы, сколько внешнее мнение. Это связано с «замыленностью» взгляда: находясь, условно говоря, «внутри» объекта исследования, т.е. стоя на позициях владельца сайта, трудно смотреть на него объективно. Важно также учитывать мнение именно ваших пользователей. Скажем, постоянные клиентки салонов красоты и покупатели АТС – это принципиально разные люди с разными вкусами и привычками. Поэтому метод «спроси мнение у мамы» (у самого неискушенного человека, оказавшегося рядом), популярный в среде разработчиков при оценке сайта, работает не всегда – только для массовых сервисов.
Роль подразделений в рабочей группе
Мы определили видение будущего сайта. Что дальше? Какова дальнейшая роль подразделений в работе над сайтом, помимо разработки его образа? От образа перейдем к конкретике бизнеса.
Идеологические вопросы
Прежде всего, нужно идентифицировать вашу потребность в сайте: какие цели перед ним стоят, какие задачи он будет выполнять и как именно. При работе над этой группой вопросов на первый план выходят отделы, работающие с клиентами и для клиентов: отделы маркетинга, продаж, внешнеэкономической деятельности, дистрибуции, рекламы, public relations. А также нужно спросить мнение отдела материально-технического снабжения (поставок), отдела логистики и отдела инноваций (R&D): какие функции, выполняемые на сайте, могли бы облегчить им работу. Имейте в виду, что в отделах работают люди, которые прекрасно знают свой участок работы, но не очень хорошо представляют, что может современная веб-разработка сделать именно для них. Подготовьтесь к разговору, изучите сайты, сходные по назначению с вашим, и обязательно попробуйте с ними поработать в режиме решения конкретных задач; почитайте литературу, сходите на семинары и выставки. Выступайте проводником для сотрудников своего предприятия, обсуждайте с ними идеи, которые у вас возникнут, постарайтесь глубже понять реалии их работы.
Технологические вопросы
К ним относится вопрос о выборе разработчика и технологии веб-разработки, хостинг-провайдере и о технических аспектах внедрения сайта. Кажется, что все эти вопросы должен решать отдел АСУ или системный администратор. Однако это неверное предположение. Отделы АСУ, которые могут осознанно и безошибочно решить вопрос о технологиях разработки сайта, скорее редчайшее исключение, чем правило. Выбирать технологию веб-разработки (какой «движок», т.е. программное обеспечение с определенными функциями, использовать для разработки сайта) однозначно должен веб-редактор, поскольку этот вопрос тесно связан с выбором веб-разработчика. Выбрать технологию – это все равно, что выбрать разработчика. И наоборот.
Кроме того, это решение не только технологических, но и гуманитарных вопросов: оформление сайта, таксономия разделов (выбор правильных названий в иерархической структуре), решение маркетинговых, имиджевых, рекламных и т.п. задач, наконец, разработка юзабилити (эргономических показателей удобства пользования сайтом). При выборе веб-разработчика нужно учитывать и эти его умения. Во всем же, что касается гуманитарных вопросов и вопросов вкуса, мнение отдела АСУ и системного администратора лучше не спрашивать.
Но отделы АСУ все-таки должны принимать участие в решении вопросов, связанных с внедрением сайта. А именно в вопросах стыковки информационных потоков, идущих через сайт, с информационными системами предприятия, т.е. в вопросах организации информационного обмена и электронного документооборота. Это как раз их непосредственная обязанность, и эти вопросы критически важны для сайта, который будет использован в бизнес-процессах работы с клиентами, а также в некоторых других. Например, в бизнес-процессе расчета оптимальной комплектации вагонов, расчета железнодорожного тарифа на перевозку груза из пункта А в пункт Б, и прочее. Эти расчеты выполняются (или должны выполняться) специальными программами или различными информационными системами, и обеспечить их интеграцию с сайтом бывает критически необходимо. А кстати, в рабочую группу нужно, помимо отдела АСУ, привлечь другие обеспечивающие подразделения: отдел логистики, исходя из нашего примера.
Выбором разработчика должен заниматься руководитель интернет-проекта, веб-редактор, при недостаточном знании рынка и критериев выбора – с помощью консультанта. А как выбирать веб-разработчика, используя вполне конкретный алгоритм, мы рассмотрим в главе 9.
Организационные вопросы
Кто будет управлять сайтом, поддерживать его, размещать на нем информацию, отвечать за его функционирование, функциональность, работоспособность? Кто будет заниматься продвижением вашего бизнеса в интернете? Необходимо разработать регламент группы поддержки сайта, подумать о внедрении в штатное расписание новых специалистов, а также о том, не возникает ли противоречия между уже сложившимся стилем работы и новыми веяниями. А также о том, как организовать систему поставки информации на сайт. Возможно, самый безболезненный путь – дополнить должностные обязанности специалистов разных отделов работой с интернет-сайтом: а мы с вами уже знаем, что в рабочую группу вошли представители тех подразделений, что заинтересованы в работе через сайт. Значит, им нужно позаботиться о внедрении соответствующего бизнес-процесса в обязанности сотрудников и отразить это решение в общем регламенте работы с информацией сайта (таблица 1.2).
Организационные положения стоит подкреплять приказом или регламентом, подписанным руководством предприятия. Тем самым от предположений и разночтений о роли сайта в вашей компании вы перейдете к однозначно понимаемому и принимаемому, согласованному и официально утвержденному руководству к действиям. Роль подразделений в решении организационных вопросов состоит в том, чтобы сначала высказать свое мнение и пожелания, обсудить и согласовать их, а затем исполнять.
Исполнение подразумевает, что:
- Подразделение регулярно поставляет на сайт свою информацию, в режиме «реакция на событие». Т.е. как только подразделение вырабатывает новую информацию, она тут же отражается на сайте (см. таблицу 1.2).
- Подразделение выполняет регламент по обслуживанию запросов и заявок, поступивших через сайт.
Таблица 1.2. Примерный регламент работы с информацией, заносимой на сайт
| Подразделение | Вид информации | Где производятся изменения | Кто вносит изменения на сайт |
| Отдел продаж | Прайс-лист: внесение новых позиций или удаление старых, редактирование позиций и цен. | Раздел «Цены», «Продукция», «Каталог». | Сотрудник подразделения либо веб-редактор через уведомление от сотрудника подразделения. |
| Отдел маркетинга | Маркетинговые акции, анкеты, опросы. | Раздел «Акции», «Специальные предложения», «Опрос» и т.п. | |
| Отдел PR | Пресс-релизы, годовые отчеты. | Разделы «Новости», «О компании», «Годовой отчет», «Пресс-комната», «Сообщение о существенных фактах» и т.п. | |
| Отдел рекламы | Рекламная акция. | Раздел «Акции», локальная баннерная сеть. | |
| Отдел кадров | Размещение информации о вакансиях. | Раздел «Вакансии». | |
| Отдел дистрибуции | Размещение информации для партнеров. | Раздел «Партнерам», закрытый раздел «Дистрибуторам». | |
| Отдел инноваций | Размещение информации о новой продукции, предложений о партнерстве. | Раздел «Инновации», «Новости», «Продукция». | |
| Отдел закупок | Размещение потребностей, информации о тендерах, тендерной документации. | Раздел «Потребность», «Тендер». | |
| Отдел внешнеэкономической деятельности | Размещение информации для иностранных покупателей. | Разделы на иностранных языках. | Переводчик, сотрудник подразделения или веб-редактор через уведомление от сотрудника подразделения. |
Конечно, регламент будет отличаться на предварительном этапе и после сдачи сайта в эксплуатацию. Уточнятся цели и задачи, появится конкретная технологическая среда работы для всех сотрудников. Третий столбец с перечнем конкретных разделов на начальном этапе может вообще отсутствовать и прорабатываться позже, при разработке технического задания. Да и за то время, что уйдет на работу над проектом, поменяется та реальность, которую вы автоматизируете и дополняете каналом работы через интернет: т.е. поменяются или уточнятся реалии работы каждого отдела, ваши представления и пожелания. После сдачи сайта в эксплуатацию вам нужно будет таблицу регламента дополнить сроками исполнения, ответственными за исполнение, конкретными реквизитами доступа к системе управления (профилями пользователей).
Сайт – это проект
Как уже говорилось, сайт – это проект. Причем проект, который не ограничивается лишь созданием: успех зависит от решения организационных вопросов. Поэтому так важно обеспечить вашему проекту статус, который соответствует его важности для предприятия. И помните: управление проектом снижает стоимость проекта! Т.е. если вы подойдете к сайту как к чему-то простенькому и отпустите его в свободное плавание, пренебрежете системным управлением, вы потратите гораздо больше времени и денег с гораздо худшим результатом.
Часто веб-редактор попадает в замкнутый круг: ему говорят, что сайт не может давать существенной доли прибыли, поэтому члены рабочей группы отдают ему низший приоритет и многие вопросы, без которых проект не может сдвинуться с места, не решаются. Особенно это критично на этапе открытия проекта. Мне известны случаи, когда подобные вопросы решаются (а точнее, не решаются) годами. Но сайт не будет давать заметную прибыль, пока ему выделяется низший приоритет. Всем известно, что низший приоритет означает полное отсутствие внимания. Именно поэтому веб-редактор не должен совмещать обязанности: он не должен делать эту работу в нагрузку к основным обязанностям в отделе маркетинга, рекламы или АСУ. Управление веб-сайтом, который претендует на роль инструмента бизнеса, должно быть его основной и, очень желательно, единственной работой: поверьте, это очень большая нагрузка.
У всякого проекта есть цикл жизни. Проект «Веб-сайт» в этом смысле не отличается от любого другого проекта. Примерный состав работ на протяжении цикла его жизни приведен в таблице 1.3. Проект требует квалифицированного управления и разнообразных знаний, поэтому если нет сотрудника с высокой квалификацией в управлении интернет-проектами и знанием рынка веб-разработки (и его нет в отделе АСУ, даже если вам утверждают обратное), то на отдельных стадиях нужно привлекать консультанта.
Таблица 1.3. Стадии жизни проекта «Корпоративный веб-сайт»
| Стадия | Состав работ | Исполнитель |
| Открытие проекта | Определение целей и задач проекта, анализ и разработка концепции (см. главы 2, 8).
Определение состава рабочей группы (см.. таблицу 1.4). Разработка плана-графика работ, объема и порядка финансирования. Разработка и утверждение регламентирующих документов, включая статус проекта и его роль для предприятия. Постановка задачи (глава 8). Выбор и регистрация доменного имени сайта или группы сайтов. |
Консультант совместно с заказчиком, квалифицированный заказчик[3]. Регистрацию доменного имени (п. 6) может производить либо заказчик, либо по его поручению разработчик. Во втором случае необходимо проследить, чтобы договор был заключен на организацию заказчика. |
| Выбор разработчика | Определение требований к разработчику (глава 9).
Поиск информации и рекомендаций, отбор претендентов. Тестирование портфолио претендентов (глава 9) и формирование шорт-листа. Телефонные интервью и второй круг отбора. Личное знакомство с разработчиками, изучение их технологических возможностей (CMS – систем управления сайтом). Конкурс коммерческих предложений. Принятие окончательного решения и заключение договора. |
Консультант совместно с заказчиком, квалифицированный заказчик. |
| Разработка сайта | Разработка технического задания, информационной архитектуры сайта.
Утверждение технического задания. Разработка эскизов дизайна главной и второстепенной страниц сайта. Согласование и утверждение эскизов. Разработка и настройка программных модулей, верстка страниц, настройка системы управления содержимым (Content Management System, CMS). Тестирование функциональной работы сайта, юзабилити-тестирование. Определение семантического ядра сайта. Разработка паспорта сайта. Наполнение сайта информацией, текстами и иллюстрациями (с учетом семантического ядра). Ввод сайта в эксплуатацию. Обучение персонала заказчика работе с системой управления сайтом и основам интернет-маркетинга (параллельно разработке). |
Разработчик под надзором квалифицированного заказчика или консультанта. Наполнение осуществляется заказчиком либо по отдельному пункту договора разработчиком по предоставленным заказчиком материалам.
Обучение работе с системой управления сайтом производит разработчик. Обучение основам интернет-маркетинга – специализированные учебные центры. |
| Регистрация и продвижение сайта | Проведение мероприятий по регистрации и стратегическому продвижению сайта (поисковая оптимизация сайта) с учетом семантического ядра и паспорта сайта.
Медиапланирование и проведение рекламных и PR-кампаний, тактическое продвижение сайта (интернет-реклама). Анализ проведенных мероприятий с помощью инструментов интернет-статистики. Корректировка плана мероприятий по продвижению сайта. |
Квалифицированный заказчик или специализированное агентство, разработчик. |
| Анализ поведения посетителей, разработка предложений по дальнейшему развитию сайта | Регулярное и постоянное изучение посещаемости сайта с помощью инструментов интернет-статистики.
Аккумуляция предложений по изменению функциональных возможностей, юзабилити, внешнего вида сайта в заинтересованных службах, отзывов посетителей и пользователей сайта, клиентов. Корректировка целей, задач, образа сайта. Постановка задачи для редизайна сайта. |
Квалифицированный заказчик или заказчик совместно с консультантом. |
Как мы видим, первая стадия проекта завершилась переосмыслением целей, задач и образа сайта вашей компании. Вы, пройдя весь круг – от замысла до воплощения и первого опыта работы – возвращаетесь к необходимости дорабатывать и перерабатывать сайт, с учетом накопленного опыта, изменившихся взглядов и приоритетов. Вы вновь обращаетесь к разработчику и повторно проходите весь цикл работы. Переработка носит название «редизайн» и относится не только к изменению не только внешнего вида сайта, но и его информационной архитектуры и функциональности: у вас может возникнуть потребность в новых разделах, программных функциях, изменении или расширении возможностей, изменении названий разделов, навигации по сайту, и прочее.
Работа над редизайном выводит ваш проект на новый виток, следующий цикл работы, который включает те же этапы, что и первоначальный. Некоторые этапы, описанные в таблице 1.3, могут быть изменены или опущены, например, выбор разработчика: если ваш разработчик вас устраивает, менять его ни к чему и даже вредно. Возможно, не нужно будет менять графическое оформление и вновь утверждать эскиз дизайна. Однако в целом в редизайне необходимо придерживаться тех же процедур, что и при первоначальной разработке: например, написание технического задания на все изменения, в том числе на изменения в оформлении – обязательный этап редизайна. Если его опустить, то результат может оказаться неудовлетворительным даже для незначительных изменений: могут «поплыть» какие-то прежние качества сайта. А постановка задачи обязательно должна включать не только модель будущего сайта, т.е. не только проект «как должно быть», но и анализ положения «как есть»: что хорошо, а что плохо в работающем интернет-проекте. Это позволит ненароком не разрушить достижения и не тащить за собой груз ошибок, сделать интернет-проект, который учтет недостатки и будет действительно лучше предыдущего во всем, от конкретных решений разработчика до организационных схем работы через сайт.
Несмотря на то, что основная нагрузка по управлению интернет-проектом ложится на веб-редактора, его положение на предприятии нельзя назвать ключевым. У него есть лишь исполнительные полномочия. Поэтому в составе и даже руководителем рабочей группы проекта должен быть сотрудник, который имеет полномочия по принятию окончательных решений и влияние, чтобы эти решения претворялись в жизнь, и будет таким образом осуществлять патронаж интернет-проекта. У него должно быть достаточно высокое положение на предприятии, чтобы успешно влиять на высшее руководство, доносить до него смысл нововведений, и в то же время конкретная заинтересованность в успешной реализации проекта. Самый удачный в моей практике опыт участия руководства компании в проекте – это руководители коммерческой дирекции (1-2 уровня). Как именно, насколько формальным будет участие такого «крестного отца» в рабочей группе (часто у них нет времени), и насколько он нужен в ваших условиях, зависит от культуры и традиций компании. Примите этот совет как пожелание. Для веб-редактора, который руководит всей исполнительской частью интернет-проекта, т.е., собственно, руководит интернет-проектом, наличие в рабочей группе такого патрона – положительный момент, поскольку его собственные возможности влияния на руководство ограничены. Проект будет двигаться быстрее, решения не будут «повисать», вовремя будет выделяться финансирование и решаться организационные вопросы, повысится значимость. В общем, наличие «крестного отца» в рабочей группе очень желательно. И, конечно, в её состав должны входить сотрудники заинтересованных подразделений, которые таким образом получают возможность влиять на то, как учитываются их интересы.
Таблица 1.4. Примерный состав рабочей группы проекта «Корпоративный веб-сайт»
| Член рабочей группы | Подразделение или должность | Роль в рабочей группе |
| Руководитель рабочей группы | Заместитель коммерческого директора, руководитель коммерческой дирекции | Общий надзор над проектом, отвечает за внедрение решений рабочей группы, взаимодействие с руководством предприятия, бюджетирование интернет-проекта, соблюдение коммерческой тайны, утверждает концепцию сайта. |
| Редактор корпоративного сайта (веб-редактор), руководитель интернет-проекта | Сотрудник службы маркетинга, рекламы, пресс-службы или специальной службы сопровождения интернет-проектов | Основной исполнитель проекта. Готовит проекты решений, приказов, договоров, документирует проект. Отвечает за организацию встреч рабочей группы, взаимодействие ее членов, проведение обследования и интервью, сбор документов, необходимых для разработки проекта, исполнение решений. Подбирает и привлекает внешних исполнителей. Отвечает за полноту и своевременность предоставляемой информации. Проводит первичное согласование концепции сайта во всех заинтересованных подразделениях. Следит за соблюдением графика работ. Администрирует права доступа. Координирует работу по продвижению сайта. Осуществляет анализ посещаемости сайта, аккумулирует предложения по развитию сайта. Инициирует работы по редизайну сайта. Осуществляет текущий надзор над функционированием и текущими изменениями в работе сайта. Отвечает за актуальность и полноту информации, размещаемой на сайте. В курсе всех событий, связанных с сайтом. |
| Веб-консультант | Внешний сотрудник, привлекаемый по договору подряда либо на временной основе | Координирует направления работ. Отвечает за аналитическую работу. Проводит обследование в подразделениях предприятия. Разрабатывает проекты «как есть», «как должно быть», системный проект (модель требований), аналитические отчеты, постановку задачи (концепцию сайта). Рекомендует перечень организационных мероприятий и определяет потребность в обучении сотрудников, разрабатывает регламент и должностные инструкции сотрудников по работе с сайтом. Определяет требования к разработчику, помогает провести конкурс на разработку сайта. Осуществляет надзор над разработкой и качественную приемку сайта, рекомендует и курирует мероприятия по продвижению сайта. |
| Руководитель проекта со стороны веб-разработчика | Специализированная компания по разработке веб-сайтов, студия веб-дизайна | Осуществляет взаимодействие со стороны разработчика сайта. Отвечает за определение и согласование бюджета на разработку сайта в соответствии с концепцией сайта, разработку и согласование технического задания, эскизов дизайна, согласование договора на разработку сайта и прочих регламентирующих документов, выполнение сроков разработки. Проводит необходимые мероприятия для качественной разработки сайта: определение состава меню, содержания и названия конкретных разделов, материалов, юзабилити-тестирования. Инициирует запросы и осуществляет совместную работу по подключению к сайту модулей, произведенных третьими лицами. Координирует совместное тестирование сайта при вводе в эксплуатацию. Отвечает за обучение сотрудников заказчика работе с сайтом в среде, предоставляемой разработчиком (наполнение сайта с помощью системы управления содержимым сайта в администраторской части сайта, CMS – Content Management System, инсталлированном на сайте). |
| Сотрудник | Отдел маркетинга | Предоставляют информацию для разработки моделей «как есть» и «как должно быть», осуществляют экспертизу концепции в отношении сбытовой части сайта.
Отвечают за полноту и актуальность сбытовой части сайта, организационную поддержку и выполнение поступающих через сайт запросов и заказов. |
| Сотрудник | Отдел продаж | |
| Сотрудник | Отдел дистрибуции | |
| Сотрудник | Отдел внешнеэкономической деятельности | |
| Сотрудник | Отдел материально-технического снабжения | Предоставляет информацию для разработки моделей «как есть» и «как должно быть», осуществляет экспертизу концепции в отношении потребностей предприятия, публикуемых на сайте.
Отвечает за полноту и актуальность части сайта, отвечающей за работу с поставщиками, организационную поддержку и выполнение поступающих через сайт коммерческих предложений. |
| Сотрудник | Отдел рекламы | Предоставляет информацию для разработки моделей «как есть» и «как должно быть», осуществляет экспертизу концепции в отношении использования приемов рекламы и поддержки рекламных акций, выставок и т.п. на сайте. |
| Сотрудник | Пресс-служба | Предоставляет информацию для разработки моделей «как есть» и «как должно быть», осуществляет экспертизу концепции в отношении размещения информации о компании, пресс-релизов, новостей, информации для прессы и общественности на сайте.
Отвечает за полноту и актуальность части сайта, отвечающей за размещение общезначимой информации о компании, пресс-релизов, новостей, информации для прессы и общественности, а также за обратную связь, модерирование горячих линий, форумов, конференций, гостевых книг и т.п. |
| Сотрудник | Служба поддержки, Call-центр | Предоставляет информацию для разработки моделей «как есть» и «как должно быть», осуществляет экспертизу концепции в отношении внешней и внутренней (администраторской) части разделов вопросов и ответов, ответов на запросы, переключения запросов на соответствующие службы, контроля исполнения запросов, стыковки и гармоничной работы с существующими системами управления взаимоотношениями с клиентами (Client Relationship Management — CRM) и т.п. |
| Сотрудник | Сервисный центр | Предоставляет информацию для разработки моделей «как есть» и «как должно быть», осуществляет экспертизу концепции в отношении раздела сервисного обслуживания, приема заказов на сервисное и гарантийное обслуживание. |
| Сотрудник | Центр разработок и инноваций, R&D | Предоставляет информацию для разработки моделей «как есть» и «как должно быть», осуществляет экспертизу концепции в отношении размещения информации о событиях и экспертной информации в области инноваций и разработок на предприятии. |
| Сотрудник | Отдел кадров | Предоставляет информацию для разработки моделей «как есть» и «как должно быть», осуществляет экспертизу концепции в отношении размещения информации о вакансиях предприятия. Обеспечивает подбор и обучение персонала для выполнения задач, возникающих в связи с внедрением бизнес-процессов работы через сайт. |
| Сотрудник | Отдел АСУ, отдел информационных технологий | Снабжает информацией и обеспечивает техническую и координационную поддержку, осуществляет экспертизу проекта в отношении стыковки внешней и внутренней части сайта с существующими и перспективными информационными системами предприятия (складская, управления товарными запасами, финансовая, бухгалтерская, кадровая, логистическая, ERP (информационная система управления предприятием – Enterprise Resource Planning), CRM (Client Relationship Management), почтовая и т.п.), взаимодействия с владельцами необходимых в работе внешних информационных систем, программного обеспечения, баз данных и справочников. Отвечает за техническую безопасность проекта, автоматизацию рабочих мест в соответствии с организационными и техническими требованиями проекта. |
| Сотрудник | Отдел логистики | Снабжает информацией и обеспечивает техническую и координационную поддержку, осуществляет экспертизу проекта в отношении использования в проекте данных внешних информационных систем, например, расчета тарифа на грузовую перевозку железнодорожным транспортом, взаимодействие с владельцами внешних логистических информационных систем, программного обеспечения и баз данных. |
| Сотрудник | Финансовая служба, бухгалтерия | Снабжает информацией и обеспечивает координационную поддержку, осуществляет экспертизу проекта в отношении использования в проекте платежных систем. |
Подобный состав и зоны ответственности в рабочей группе основаны на реальном проекте для крупного холдинга, с наукоемким производством, большой дистрибьюторской сетью, внешнеэкономическими связями, службой поддержки клиентов. Состав рабочей группы определен после детального знакомства с организационной структурой предприятия и серии интервью с руководителями отобранных подразделений. Для другого предприятия состав рабочей группы, скорее всего, вышел бы другим. Например, вы – авиакомпания, и для вас логистика смыкается с основным видом деятельности. Кто обеспечит стыковку системы бронирования билетов через сайт с глобальной системой бронирования авиабилетов – отдел логистики, отдел продаж, отдел маркетинга, отдел информационных технологий (АСУ) или кто-то еще? Кто отвечает за выбор, внедрение или стыковку с клиентскими базами данных – отдел АСУ, отдел маркетинга, отдел продаж, call-центр? Так или иначе, за эти вопросы кто-то должен отвечать. И если вы не понимаете, кто именно, проект будет буксовать – но это лишь отображение проблем в организации ваших бизнес-процессов. И именно поэтому в состав рабочей группы обязательно должен входить руководитель достаточно высокого ранга, чтобы решать проблемы, выходящие за рамки разработки веб-сайта и имеющие глубинный организационный характер. Если вы не планируете решать через сайт вопросы продаж, снабжения и осуществлять сделки и транзакции, то состав рабочей группы серьезно уменьшится, возможно, до первых четырех позиций.
Нет необходимости всем членам рабочей группы участвовать во всех встречах. Единственный участник, который участвует во всех встречах – веб-редактор (руководитель интернет-проекта). Остальные участвуют при решении вопросов, которые касаются их непосредственно. Однако необходимо проводить регулярные встречи для всех, на которых освещать ход работ и решать общезначимые вопросы и проводить мозговые штурмы, например, относящиеся к оформлению или удобству пользования сайтом. Вам нужно заразить всех участников процесса энтузиазмом, желанием работать совместно и сделать лучший сайт. И тогда ваш сайт действительно будет лучшим.
Порядок работ и матрица ответственности
Порядок ведения работ и зоны ответственности участников проекта – это всегда то, что по-английски называется tailor-made – «индивидуальный пошив», то, что создается «по месту», зависит от положения дел в компании, опыта сотрудников, ресурсов и возможностей. Скажем, есть ли на предприятии человек, который способен вести интернет-проект? Есть ли у него время? Если такого человека нет, то одной из начальных задач станет поиск такого человека: есть ли подходящая кандидатура внутри компании, есть ли возможность найти руководителя со стороны, привлечь ли внешнего исполнителя (отдать выполнение этой услуги на аутсорсинг). Т.е. решить кадровый вопрос.
Приведу пример решения организационных вопросов при редизайне сайта для одного университета. Положение «как есть» заключалось в том, что сайт в университете существовал и обновлялся, но отсутствовала системность: не было ни постановки задачи, ни технического задания, ни регламента сопровождения. Некое разделение обязанностей по ведению сайта существовало, но не было единого руководителя и единого понимания, для чего нужен сайт и как он должен развиваться. Информацию, которую поставляли подразделения и кафедры, заносил один человек, который владел основами HTML, но при этом не занимался ни продвижением, ни аналитикой, ни проектированием– ему никто этого не поручал, а собственных знаний, умений, и главное, инициативы, не было.
Если у кого-то на кафедрах, в подразделениях, у студентов появлялись идеи и потребности в размещении какой-то информации или новых функций, он мог пойти в отдел маркетинга, в отдел АСУ, в отдел связей с общественностью, в отдел по внеучебной работе и т.п. – и никто из них не мог помочь. В итоге, когда какое-то из подразделений ощущало потребность что-то изменить в своем разделе, оно просто создавало свой собственный «альтернативный» сайт в рамках своих возможностей (по сути, любительский, поэтому и «альтернативный», «неофициальный») – своими силами, в своей стилистике, со своей системой навигации и пр. – отдельные сайты у каждой кафедры, у библиотеки, у учебного отдела, сайт для студентов и т.д.
Количество таких разрозненных сайтов внутреннего пользования превысило всякие разумные пределы, а внешний потребитель компании – абитуриент, аспирант, партнер – не мог понять, является ли информация того или иного сайта официальной, или вообще не мог найти нужную информацию. Самое печальное, что в университете никто не отдавал себе отчет в том, что эти сайты годятся только для внутреннего пользования из-за любительского уровня разработки, куцей функциональности, одностороннего наполнения и плохого проектирования. В общем, количество никак не переходило в качество.
Чтобы исправить положение дел «как есть» и понять, «как должно быть», для начала в университете был издан приказ об инициации работ над редизайном сайта и определен состав рабочей группы. На эту рабочую группу была возложена работа по решению организационных вопросов, и в первую очередь встал вопрос о том, кто будет руководителем интернет-проекта и как будет сопровождаться сайт. Исходя из положения «как есть» и реалий университета, было предложено распределить работу по сопровождению между главным редактором сайта – руководителем интернет-проекта, которого предстояло найти, контент-редактором, который уже существовал и мог продолжать вести работу, только системно и на более качественном уровне, и, при наличии желания и возможностей, сотрудниками кафедр и подразделений.
Поскольку при имеющемся контент-редакторе требования к руководителю интернет-проекта владеть какими-то конкретными навыками, вроде умения работать с веб-изображениями, не вставали, на первый план вышли его руководящие, аналитические способности и знание реалий университета, и это упростило задачу, поскольку в университете можно найти подходящего сотрудника с такими качествами. Помимо этого, был произведен аудит умений и разработан план обучения этих сотрудников – объемом в 40 часов. Был разработан порядок работ и матрица ответственности по каждому виду работ.
Таблица 1.5. Состав работ и матрица ответственности для интернет-проекта
| № этапа | Вид работы | Руководитель рабочей группы | Заинтересованные подразделения | Рабочая группа | Руководитель интернет-проекта | Консультант | Контент-редактор | Разработчик |
| 0 | Определение заинтересованных подразделений и лиц (расширенного состава рабочей группы). Подбор и рекомендация рабочей группе группы сопровождения сайта — руководителя интернет-проекта, контент-редактора и пр. Определение и утверждение бюджета на постановку задачи и сопровождение сайта. Определение и утверждение бюджета на разработку сайта | Х | X | |||||
| 1 | Определение целей и задач. Определение видения сайта | ХХ | ХХ | ХХ | X | ХХ | ||
| 2 | Разработка регламента сопровождения сайта | ХХ | ХХ | ХХ | X | ХХ | ||
| 3 | Проведение обследования (интервьюирование, анкетирование, сбор документов) | ХХ | X | |||||
| 4 | Утверждение постановки задачи | X | ХХ | |||||
| 5 | Подбор разработчика. Уточнение бюджета на разработку | ХХ | X | |||||
| 6 | Утверждение разработчика | X | ||||||
| 7 | Согласование договора | X | ХХ | |||||
| 8 | Утверждение договора, перечисление предоплаты | X | ||||||
| 9 | Разработка технического задания на основе постановки задачи | ХХ | ХХ | XXX | ||||
| 10 | Утверждение технического задания | X | ХХ | ХХ | ХХ | |||
| 11 | Разработка эскизов страниц сайта в рамках технического задания | XXX | ||||||
| 12 | Утверждение эскизов | X | ХХ | ХХ | ХХ | ХХ | ||
| 13 | Подготовка материалов сайта в соответствии с техническим заданием | ХХ | ХХ | X | ||||
| 14 | Разработка программных модулей, кодировка, настройка системы управления сайтом, обучение сотрудников группы сопровождения сайта, внутреннее тестирование | XXX | ||||||
| 15 | Тестовая эксплуатация сайта, юзабилити-тестирование, занесение материалов на сайт | ХХ | ХХ | ХХ | X | |||
| 16 | Приемка сайта | X | X | X | X | X | XX | |
| 17 | Эксплуатация и сопровождение сайта, занесение новой информации в соответствии с регламентом | ХХ | X | |||||
| 18 | Продвижение сайта | X | ХХ | X | ||||
| 19 | Анализ посещаемости, аккумуляция предложений по корректировке продвижения и редизайну сайта | X | ХХ | ХХ | ||||
| 20 | Разработка постановки задачи на внесение изменений (редизайн сайта) | X | ХХ | |||||
| 21 | Далее повторение цикла ведения работ за исключением отдельных этапов в соответствии с постановкой задачи | X | X | X | X | ХХ | X | XXX |
Условные обозначения
Х исполнитель
ХХ вспомогательная роль
ХХХ внешний исполнитель
Использовать эту матрицу без изменений, переработать ее или найти свой собственный путь – у вас работа над интернет-пректом будет происходить по-своему. Главное, отдавать себе отчет, что на вашей стороне лежит не меньшая часть работы, чем на стороне внешнего исполнителя. По этой матрице видно, что объем работы, уровень внутренней согласованности и степень ответственности владельца сайта велики: не преуменьшайте их, выделяйте достаточно сил, времени и финансирования. Не тормозите работу: часто затягивание сроков сдачи связано с неготовностью заказчика.
Если матрицу выполнения работ дополнить датами, то получится план-график выполнения работ, который можно утвердить у руководства и приступать к делу.
[1] Кристина Вудке. «В чем залог успешности редизайна сайта». Перевод: Школа инернет-маркетинга Expertum.
[2] Существует несколько сложившихся де-факто неофициальных стандартов на дизайн интерфейсов, визуальный дизайн, дизайн навигации и т.п. Существует также официальный отраслевой стандарт консорциума W3C на верстку веб-страниц (http://www.w3c.org). При выборе веб-разработчика желательно понимать, будет ли он следовать этим стандартам. Однако это требует очень глубокого знания предмета и слишком пристального внимания к мелочам. Лучше обращать внимание на общее качество работ и управления проектом – подробнее см. главу «Выбираем разработчика».
[3] Сейчас и в дальнейшем под заказчиком понимается рабочая группа или делегированный представитель в лице веб-редактора, руководителя интернет-проекта.