Создание благотворительного сайта: от аналитики до продвижения. Опыт эксперта Даниловцев
ПРОДОЛЖЕНИЕ. НАЧАЛО ЧИТАЙТЕ ЗДЕСЬ
Аналитика и проектирование
С правильным разработчиком наступает третий этап, которым очень много студий пренебрегают. Этот этап называют аналитикой и проектированием. Обычно когда мы говорим о каком-то сайте, мы представляем, что у него есть какой-то внешний вид, определенная программная внутренняя начинка. Вроде бы все понятно, и казалось бы, что после выбора разработчика уже пора приступать к созданию сайта. Но нет.
Как мы изначально готовились и прописывали цели и задачи, так и разработчик должен подготовиться к своей работе и еще раз правильно прописать все цели, задачи и возможности их решения. Допустим, мы на первом этапе сделали совершенно потрясающий документ, который потрясающе точно описывает все задачи, которые перед нами есть. Но задача прекрасна тем, что предполагает множество разных решений. Особенно, если говорить про интернет.
Сайт может выглядеть по-разному. И когда мы начинаем работать над задачей, очень важно понять, что мы все видим задачу одинаково, и что разработчик уже продумал решение и видит его с нами одинаково. Потому что иногда получается, что между ожиданиями и реальностью получается бешеный зазор. Заказчики начинаются ругаться с разработчиками, первые пытаются взять свои деньги обратно, вторые не соглашаются, потому что не были обговорены нюансы. За доработку они еще платят деньги. В итоге до бесконечности начинаются эти переделки, доработки, и вам ваш сайт обойдется в разы дороже, чем заранее было обговорено.
Мы вообще практически на всех разработках должны следовать нескольким правилам, которые меня не подводили никогда. Мы должны договариваться с исполнителем и если исполнитель сам не говорит, то мы должны на этом настоять. Если он все равно не понимает, мы должны сменить исполнителя. Мы должны двигаться маленькими эффективные шагами, из которых мы получаем результат.
Например, этап аналитики и проектирования – это возможность для разработчика очертить более четко и подробно, что нужно, если это не сделано на первом этапе. А также возможность начать прописывать решения, причем не реализовывать их еще, а прописывать на понятном языке и объяснять их заказчику, чтобы прийти к единому пониманию конечного результата.
Концепт
Аналитика и проектирование обычно начинаются с составления разработчиком короткого концептуального документа, в котором перечисляются приметно то, что мы обговорили выше – цели, задачи, целевая аудитория и структура сайта. У нас, допустим, были другие ожидания. Т.е., зазор получается, но он очень маленький. Мы еще работаем на бумаге, так что этот зазор легкоустранимый. Дальше следующий шажочек, так же подробно обговариваем нюансы и в итоге, так постоянно сверяя мнения, приходим к идеальному результату.
Концептуальный документ по сути тот же документ, который мы разработали на стадии подготовки, только более глубокий. Например, очень полезно бывает описать целевую аудиторию не просто строчками «мужчины или женщины в возрасте 15-45 лет, достаток выше среднего, живущие в Москве и т.д.». Эти сухие слова обычно ни о чем не говорят. И крайне полезным на этом этапе бывает проговорить не сухую статистику, а конкретный портрет своей аудитории.
Получив от разработчика этот концепт, заказчик должен внимательно посмотреть все пункты, сопоставить его с изначальным документом и скорректировать, потому что разработчик в любом случае может что-то сделать не так, как было обговорено заранее.
Документ Х
На этом этапе уже переходим на поиск решений. Этот документ бывает очень разным, но самое главное, в него должны входить: структура благотворительного сайта, описание основных элементов и фишек, а также прототип и дизайн. Изначально мы все делаем на бумаге. Мы даже прототип рисуем пока на бумаге. Прототип – это схематичное изображение дизайна сайта. Изначально все это выглядит довольно примитивно и поверхностно, т.е. мы пока не расписываем все подробно, где какая кнопочка будет, где новости, где колонки будут и т.д. Но эти картинки позволяют нам делать еще один шаг навстречу заказчику и понять друг друга лучше, понять, что мы одинаково видим не только условие задачи, но и ее решение. На этом этапе мы можем вмешаться и сказать, например, что вот этот слайдер лишний, надо его поменять на текст с картинкой. Всю эту волокиту мы называем «бумажный тигр», потому что работаем на этом этапе исключительно на бумаге.
Тут же можно уже заводить речь с заказчиком о дизайне. Тут тоже очень важно мыслить в рамах поставленных задач. После того, как мы договорились об основном пакете документов, мы делаем следующий шаг.
Детальный прототип
Тут схематическую картинку сайта, которую мы пока нарисовали на бумаге, дополняем деталями. Например, мы знали, что на главной будет блок «новости». Но если изначально мы не знали подробно, как он будет выглядеть, и что из себя будет представлять, то на этом этапе мы уже расписываем, сколько новостей будет на главной сайта, где будут заголовки новостей, где тексты и т.д. Прототип не определяет в точности, как должен выглядеть тот или иной сайт, он определяет, что на сайте должно быть. Дальше мы всю эту информацию отдаем дизайнеру, он там тоже рисует что-то, и в результате выходит то, что нам не было нужно. И нам надо как-то ему передавать, что нам в итоге нужно.
Этап составления технического задания (ТЗ)
Этот этап самый сложный и плохо проработанный в отечественной разработке. ТЗ – это текстовое описание технической задачи разработчику. Что он должен сделать, какие страницы создать, что на этих страницах должно быть расположено и как они должны работать. По сути, это все является квинтэссенцией всего того, о чем мы говорили раньше, но переведенный в текстовый вид, формальный, не терпящий никаких иносказаний. Но проблема в том, что никаких стандартов технических заданий нет.
Есть техническое задание по ГОСТу, которое применяется для разработки интернет-проектов, про него, наверное, будет достаточно сказать, что оно разработано в нескольких редакциях еще при советской власти. Проблема в технологической жуткой путанице. Советское предельно бюрократизированное громоздкое, выламывает мозг – это страшное советское ТЗ ставит задачу разработчику, и разработчик дальше должен сидеть и придумывать, как реализовать эту задачу. Оно называется техническое задание, но скорее это техническое описание создаваемого сайта. Оно на 50% ставит задачу и на 50% описывает ее решение. Проблема в том, что когда разработчик будет писать вам ТЗ, вы можете на руки получить все, что угодно.
Техническое задание выполняет следующие функции:
– дает понять, что разработчик и заказчик договорились об одном и том же, т.е. консенсус.
– работает как ограничитель ответственности в действиях и разработчика, и исполнителя.
Поэтому ТЗ является юридическим документом и обычно прилагается к основному договору.
На разработке сталкиваются две в чем-то противоположные, но очень взаимодополняющие личности. С одной стороны – хороший аналитик, проектировщик и с другой – менеджер, который занимается разработкой. Проектировщик может быть очень грамотным и отличным специалистом, но он может не знать какие-то особенности благотворительной деятельности, например. В этом деле ему первый помощник – менеджер. Поэтому очень важно между ними наладить диалог для более продуктивного взаимодействия.
Что должно быть в ТЗ?
Оно может быть совершенно разных форматов, оно может быть написано абзацами текста, как сочинение школьное, оно может быть действительно структурированным формальным документом, как мы стараемся делать. Но в любом случае там должны быть следующие вещи:
– Структура сайта. Да, мы ее обсуждали раньше, но эти обсуждения не являются юридическим документом.
– Целевая аудитория и ее задачи.
– Цели и задачи наши.
– Описание отдельных страниц.
– Важные технические уточнения. Например, нагрузка, т.е. сколько человек в день предположительно будет заходить на сайт, или на экранах каких разрешений будет открываться сайт, требование к браузерам всех версий. Также необходимо продумать особенности захода на сайт с помощью мобильных приложений. Тут идеальный вариант – сделать мобильную версию сайта. Единственный минус – это вам будет стоить дороже. Кроме того, следует уточнять языки сайта.
В хорошем, грамотно составленном техническом задании не должно быть описаний, как это будет выглядеть. Не должно быть требований к колористике, цветам. Потому что техническое задание – это не задание для того, кто будет рисовать ваш сайт, а для того, кто будет его программировать.
Правильное ТЗ достаточно сложное для непросвещенного восприятия. И хороший разработчик всегда предложит обсуждение по пунктам это ТЗ. Вы должны с ним сесть, потратить на это пару часов и пройтись по пунктам подробно. После этого мы подписываем ТЗ и получаем его. После окончания разбора и подписания ТЗ, исполнитель должен вам уже сказать, сколько будет стоить ваш сайт.
Что очень важно указывать в техническом задании – это система управления сайтом. Сайты собираются из всяких разных отдельных элементов, называется CMS. У нас есть два выбора. Мы можем воспользоваться для построения сайта готовым набором элементов (CMS), а можем воспользоваться самописной CMS, который разработчик пишет специально под себя. И у того, и у другого подхода есть свои достоинства и недостатки. Если у нас есть готовый CMS, у нас оно заточено под определенные ресурсы – интернет-магазины, информационные сайты, сайты-визитки. Там никаких изысков нет, там все просто и быстро. Но если нам нужно что-то особенное, то необходимо позвать человека, которые напишет нам все это с нуля. В этом случае есть риск собрать все криво и некачественно. Одним словом, если вы не уверены в разработчике, то берите готовый вариант CMS.
Если ТЗ хорошее, то мы с разработчиком можем на этот момент распрощаться и с готовым ТЗ можно уже походить по рынку и посмотреть, какие ценовые варианты вам будут еще предложены.
Дизайн
Дальше наступает этап дизайна. Этап дизайна тоже составляет очень много работы. Дизайн – это по сути картинки всех страниц сайта. Обычно с заказчиком в договоре обговаривается, сколько вариантов дизайна он вам предоставляет, но как показывает мой опыт, лучше договариваться о том варианте, когда дизайнер дает вам один вариант дизайна, дальше мы его смотрим и дорабатываем. Мы начинаем обсуждать дизайн. Очень важно, чтобы он был сделан под ТЗ. В идеальном случае, у нас больших вопросов возникнуть не должно. Но тут надо учитывать не сколько ваши личные вкусы, а вкусы конечных потребителей. Т.е. ваш сайт должен нравится пользователям, которые будут на него заходить. На выходе мы получаем набор картинок, которые являются графическим изображением сайта во всей своей красе.
Верстка
Когда дизайнер присылает картинку, эту картинку надо каким-то образом разрезать и преобразовать ее в верстку. За верстку отвечает отдельный человек – верстальщик. Он берет каждую отдельную картину, предоставленную дизайнером, и преобразовывает ее уже в интернет-формат, который в дальнейшем можно будет использовать для разработки.
Программирование
Дальше начинается этап программирования. Он протекает от нас достаточно закрыто. На этом этапе происходит собирание и наполнение внутренних шестерёнок сайта. На этом этапе клиента редко когда дергают, только в том случае, когда у нас действительно очень сложная начинка.
Тестирование
Очень часто этот этап недооценивают и относятся к нему спустя рукава. Если проект сложный, то на тестировании специально обученные люди прогоняют сайт по всем возможным сценариям, схемам, и смотрят, как сайт работает, действительно ли сайт дает то, что от него требуется, не падает ли у него нагрузка и т.д. И только после этого сайт дается нам на тестирование. Часто разработчики этим грешат и отправляют клиенту очень сырой продукт, типа, сами его тестируйте. Этого стоит избегать и прописать тестирование в договоре.
Поддержка
Очень важно договориться с разработчиком об этапе поддержки, потому что при работе сайта все равно будут вылезать какие-то мелкие ошибки, которые еще ни один опытный разработчик до конца не учел. Поэтому разработчик должен гарантийно поддерживать ваш сайт еще месяц как минимум.
Продвижение
Мы должны постоянно думать над продвижением нашего продукта. Учитывать интересы целевой аудитории, отвечать их запросам и в конечном итоге приносить пользу своим продуктом.