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