Имея
большой опыт работы менеджером проектов по созданию сайтов, как на
стороне исполнителя, так и на стороне заказчика, я хотел бы выделить
типовые ошибки, совершаемые Заказчиком при разработке сайта на уровне
менеджмента. Этот материал может быть использован как руководство к
действию для менеджеров, на которых возложено курирование разработки
сайта, так и их руководителей.
Тот
факт, что мне приходилось находиться "по обе стороны баррикад”
позволяет взглянуть на ситуацию с разных сторон и постараться выделить
ключевые моменты, определяющие ход проекта. 1. Отсутствие четкого осознания целей проекта
Очень
часто при создании сайта у заказчика отсутствует четкое понимание
целей, которые стоят перед проектом. И в итоге результат может
оказаться плачевным: вы "что-то” попросили, мы "что-то” и сделали.
Четкое понимание, что сайт нужен только для галочки и указания на
визитках (а для многих компаний это так и есть) избавило бы множество
заказчиков от головной боли и лишних трат.
Помните, что сайт – это не набор красивых изображений в Интернете, а,
прежде всего, маркетинговый инструмент, который должен выполнять свое
предназначение, а не "просто быть”.
Крайне рекомендуется перед началом проекта провести предпроектное
исследование и заказать разработку веб-стратегии (о ней подробнее в
пункте про типовой цикл проекта), которая позволит сформировать некое
видение проекта на всех этапах его жизненного пути.
2. Неправильная оценка и распределение бюджета проекта
Довольно часто заказчик не может правильно оценить бюджет проекта и
правильно расставить приоритеты по аспектам работ. Очень часто заказчик
исходит из личных предпочтений и устоявшихся стереотипов (например,
"дизайн сайта не важен, главное - информация”). Это неверно, бюджет
должен формироваться исходя из четкого понимания целей и задач проекта
(см. пункт выше). Если вы определили, что основная задача сайта –
поддержание бренда или определенной марки продукта в Сети, глупо
экономить на разработке дизайн-концепции.
Типичная ошибка – большой бюджет на продвижение проекта (допустим,
сотни тысяч долларов в год) - и мизерный на сам сайт. Подумайте,
вкладывая такие деньги в рекламу, логично потратить немного больше
денег на разработку, чтобы посетители сайта не были разочарованы. Верно
и обратное: не имеет смысла раздувать бюджет на сайт, если никаких
целей, кроме, собственно, его наличия нет.
Если у вас есть сомнения в собственных возможностях определения общего
бюджета или распределения его по составным частям, обратитесь за
консультацией во внешнюю экспертную организацию (только не к
подрядчику). Желательно, чтобы эта организация не занималась
разработкой сайтов, а специализировалась именно на консалтинге, иначе
ее анализ может быть предвзятым. СРОКИ
Не секрет, что более 80% проектов по созданию сайтов не укладываются в
изначально установленные сроки, и работа затягивается на время, иногда
превосходящее календарный план в разы. Это касается практически всех
проектов (как за 2-3 тысячи, так и за 20-30 тысяч) и
студий-разработчиков любого уровня.
Попытаемся выделить ключевые ошибки заказчика, которые приводят к затягиванию сроков по проекту:
3. Затягивание согласования работ
Главная причина затягивания сроков со стороны заказчика – мучительные
согласования результатов работ. Особенно это касается разработки
дизайн-концепции сайта. Чем больше людей со стороны заказчика участвуют
в этом процессе (а по дизайну каждый считает себя специалистом) – тем
больше хаоса привносится в проект. Это необходимо исключить – у проекта
должен быть менеджер, курирующий все вопросы по проекту, а так же четко
выделенный человек, принимающий окончательные решения. Разработчику
обязательно нужно обеспечить доступ как к менеджеру, так и принимающему
решения лицу, как бы трудно это ни было. Остальных "советчиков”
необходимо исключить из процесса, потому что выполнения всех их
пожеланий и комментариев (зачастую необоснованных и противоречащих друг
другу) затянет проект на неопределенный срок. Это ни в коей мере не
касается этапа тестирования сайта и выявления ошибок – тут нужно
привлечь максимально широкий круг людей, чтобы вычистить все огрехи.
Нужно четко построить модель взаимодействия по проекту с разработчиком
именно на уровне менеджмента компании.
При принятии решения по дизайну необходимо максимально абстрагироваться
от собственных предпочтений и мыслить в категориях пользователя из ЦА и
общей адекватности предлагаемых вариантов.
Очень часто заказчик начинает "придираться” к мелочам в дизайне, хотя
на самом деле ему не нравится предложенный концепт в принципе, но он
просто не может (или опасается) это выразить. Важно отследить этот
момент и предложить разработать новый вариант. Разработчику это будет
проще, чем потратить месяцы на согласование не играющих роли мелочей,
которые все равно не добавят удовлетворенности заказчику. Не теряйте за
мелочами общего видения проекта!
Еще один важный аспект – не пускайте проект на самотек. Очень часто
после первого срыва сроков по этапам, заказчик расслабляется и
перестает оперативно реагировать на ситуацию. Это может привести к
огромным задержкам по срокам, поскольку разработчик часто склонен
сделать то же самое. Проект может попасть в "мертвую точку”, когда все
потеряли к нему интерес. Сдвинуть ситуацию с этой точки может стоить
огромных усилий.
4. Неправильная организация этапа подготовки материалов на сайт
Второй по важности аспект, влияющий на затягивание сроков –
неправильная организация процесса подготовки материалов на сайт. Очень
часто заказчик подходит к этому процессу слишком оптимистично, обещая
предоставить материалы в кратчайший срок. Это иллюзия. Как правило,
подготовка таких материалов – дополнительная обязанность людей,
занимающихся чем-то внутри компании. Именно потому, что она
дополнительная (а также отсутствие мотивации)
Постарайтесь выделить какое-то время сотрудников непосредственно на
подготовку материалов на сайт. Установите жесткий дедлайн и примите
важное решение – если контент не будет готов к обозначенному сроку, то
он не будет готов никогда. Со стороны разработчика будет также
абсолютно оправдано установить некий срок, после которого он не будет
принимать от вас никаких материалов, и их отсутствие не будет влиять на
процесс согласования его работы.
Соберите готовый материал и закажите копирайтинг недостающего, если это
необходимо (крупные студии-разработчики с радостью предложат вам свою
помощь). Не забывайте предоставлять разработчику максимально полную
информацию, он всегда сможет отмести лишнее.
"Хорошая ситуация” – когда на момент старта проекта в студию приезжает
менеджер со стороны клиента и привозит кипу бумаг и высокую стойку CD с
информацией (все-все, что он смог собрать). Это правильно.
Разработчик не обманывает вас, когда говорит, что материалы крайне
важны для его работы. Это действительно так. Идеальная ситуация –
100%-ая готовность материалов на момент начала работ по дизайну.
Наличие материалов к этому моменты позволит вам существенно ускорить
процесс, а также лишить разработчика типичной отговорки "не было
материалов, поэтому задержали сроки”, хотя, как правило, это не
является отговоркой, а действительной причиной.
Жесткий дедлайн, о котором известно вам и разработчику – отличное
средство мотивации деятельности по проекту с обеих сторон. Его наличие
позволяет отмести мелочи и долгое согласование незначительных моментов,
сформировать нацеленность на результат. Если жесткого дедлайна нет –
придумайте его (вплоть до указания финансовых санкций в случае его
несоблюдения). Отсутствие дедлайна расслабит как вас, так и
разработчика.
6. Оптимизм исполнителя при составлении календарного плана
Довольно часто при утверждении календарного плана разработчик
рассматривает "идеальную ситуацию” и указывает слишком малые сроки.
Идеальных проектов не бывает, это надо помнить. Календарный план нужно
оценить на общую адекватность, обязательно проверить на наличие этапов
на согласование работ и подписание документов, получение оплаты и пр.
Кроме того, нужно помнить, что малые сроки в плане – конкурентное
преимущество разработчика, и он мог намеренно занизить их на стадии
коммерческого предложения. С этим можно бороться прописанием жестких
санкций в договоре, а также предложением пересмотреть первичный план,
например, по итогам составления ТЗ.
7. Нарушение типового цикла проведения работ
Очень часто при работе над сайтом нарушается типовой цикл разработки
проекта. Это может происходить как по инициативе разработчика, так и
заказчика. Процесс по возможности должен идти последовательно по циклу.
Поскольку очень часто результат по предыдущему этапу влияет на
следующий, необходимо продолжать работы, только согласовав и утвердив
предыдущий этап.
Например, заказчик часто требует начать параллельно с этапом дизайна
этап сборки и верстки сайта. Это в корне неверно, поскольку при
внесении изменений в дизайн-макеты может поменяться вся концепция
ресурса, и все выполненные работы по дальнейшим этапам пойдут насмарку.
Типовой цикл прохождения проекта выглядит примерно так:
1) Определение целей и задач проекта
2) Определение позиционирования, анализ информации о продукции / услугах и ЦА
3) Разработка общей веб-стратегии компании (проекта).
В веб-стратегию должна войти информация о целях и задачах ресурса, ЦА,
проведен анализ конкурентов, должны присутствовать рекомендации по
структуре и функционалу сайта, а также разработан примерный план
дальнейшего продвижения ресурса (анализ действий конкурентов, примерные
мероприятия и бюджеты). Составление подобной стратегии существенно
помогает на всех стадиях жизненного цикла вашего проекта. Имеет смысл
заказывать разработку стратегии внешней по отношению к вашему
подрядчику экспертной структуре.
4) Разработка Технического Задания (ТЗ) на сайт, итоговой сметы и календарного плана работ.
Задача ТЗ – максимально подробно определить все аспекты работ по сайту,
создать единое видение (это очень важно) проекта и заказчика и
исполнителя.
5) Разработка дизайн-концепции сайта
6) Разработка макета главной страницы
7) Разработка макетов внутренних страниц 8) HTML-верстка сайта
9) Разработка анимационных FLASH-элементов
10) Сборка сайта на базе CMS-системы и разработка дополнительного функционала
11) Контент-наполнение сайта, пакетный внос данных в БД
12) Запуск пилотной версии сайта, тестирование, устранение ошибок
13) Перенос сайта на хостинг, тестирование, открытие сайта
Обратите внимание, в данном цикле не указаны моменты, связанные с
подготовкой необходимой информации и согласований этапов работ.
Необходимо помнить, что процесс разработки сайтов подчиняется
общепринятым принципам ведения проекта и разработки ПО. Согласно этим
принципам, рекомендуется по возможности вести процесс итерационно,
корректируя собственные действия по мере приобретения опыта и новых
знаний по проекту. Работая над большим проектом, крайне полезно создать
и отладить работу облегченной версии, постепенно дорабатывая новый
функционал.
8. Создание "сайта-памятника” Еще одна типовая ошибка заказчика – считать, что после создания сайта
его работа по развитию Интернет-направления заканчивается. Это в корне
не верно. Создание сайта – точка "ноль” для его существования. Чтобы
сайт стал эффективным маркетинговым инструментом, необходимо
разработать стратегию его продвижения, а также на постоянной основе
заниматься его обновлениями, мониторингом состояния, произведением
улучшений и доработок, развитием.
В сети существует множество примеров красивых "сайтов-памятников”,
которым не уделяется внимания со стороны их владельцев. Они висят
"мертвым грузом”, не принося никакой пользы и сводя к нулю все усилия,
потраченные на их разработку.
Небольшой пример – большинство заказчиков хотят видеть на своем сайте
ленту новостей, которая публикуется на главной странице. При этом у
большинства компаний не хватает сил поддерживать ее в актуальном
состоянии (или просто нет должного количества информационных поводов).
Определите этот момент еще на стадии проектирования, ведь нет ничего
хуже сайта с новостями за прошлый год на первой странице – он
моментально создает у пользователя ощущение "заброшенности ресурса”.
Лучше не публикуйте новости вообще, они, как правило, не очень
интересны пользователю.
МЕЛКИЕ ОШИБКИ
Так же можно выделить ряд более мелких ошибок, обычно совершаемых
заказчиком, рассмотрение которых при этом может быть интересно:
9. Регистрация домена студией или лично менеджером проекта
Зачастую такой вопрос, как регистрация домена, отдается на откуп
разработчику, и разработчик регистрирует домен на себя. В случае
возникновения конфликтной ситуации (особенно на стадии, когда проект
уже запущен и имеет какой-то индекс цитируемости, а почта и адрес сайта
указаны в рекламной продукции). Компания подрядчик может разыграть этот
козырь, угрожая снять сайт и почтовый сервер с вашего домена. Это же
относится и к регистрации домена лично на имя менеджера с вашей
стороны. Если отношения не сложатся, он сможет забрать его себе,
оставив вас ни с чем. Поэтому надо обязательно проконтролировать, чтобы
домен был зарегистрирован именно на вашу компанию как на юрлицо.
Работая с фрилансером, необходимо помнить. Что получение большой
предоплаты крайне расслабляет человека и сводит его мотивацию
практически к нулю. Этот грустный факт подтвержден многолетним опытом.
Не давайте предоплату частнику более 10-20% процентов, даже если вы
очень в нем уверены. Это не касается работы с крупными студиями –
получение предоплаты в 40-60% процентов от бюджета проекта является
нормой для рынка.
11. Отсутствие контроля откатов
Мы живем в Украине, и не надо забывать о существующей повсеместно
практике откатов. Если ваш менеджер, которому вы поручили создание
сайта, настойчиво рекомендует конкретного исполнителя, и у вас
появляются сомнения в разумности представленной сметы, ее необходимо
проверить. Отправьте запрос в 2-3 компании, работающие в диапазоне
вашего общего бюджета, и сравните их с предлагаемой сметой. Возможно,
вы будете неприятно удивлены.
