+7 (918) 436-1993 |
Белый шар - студия дизайна


Разработка сайта – руководство для Заказчика

Статьи Сайты - создание

(перепечатка) 

Часто, когда требуется создать или переработать сайт, компания, а точнее люди, её представляющие, относятся к этой задаче с некоторой снисходительностью. Снисходительность проходит постепенно. Понимание того что, разработка сайтов сама по себе является весьма и весьма объёмным и сложно-структурированным процессом приходит где-то в середине проекта, когда бОльшая часть ошибок уже совершена. Осторожные специалисты стремятся подготовиться к решению подобных задач заблаговременно, но чаще всего не преуспевают. Очень многие из тех, кто имел опыт участия в проектах разработки сайтов на стороне Заказчика, вспоминают о нём как о сущем кошмаре. На наш взгляд, проблема кроется именно в том самом позднем осознании, в отсутствии у Заказчика (а чего греха таить, порой и у отдельных разработчиков) целостного представления о составе проводимых работ, их структуре и способах организации, временных границах, критериях принятия решений в рамках реализации подобных проектов и многом другом. Часть этих знаний приобретается специалистами уже по ходу, простите за цинизм, но строго после того, как они были нужны. Другая часть – не приобретается, так как требует участия во множестве подобных работ.

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

Опыт последних лет показывает, что 90% обращений по направлению разработки Интернет-сайтов имеют одну из двух предысторий:
Специалисту в области рекламы / маркетинга / PR / IT (трудно удержаться от замечания, что даже сегодня в компаниях нередко встречаются люди, вынужденные совмещать по нескольку из этих функций) поручают задачу разработки сайта. Иногда – переработки уже существующего сайта, которые был создан несколько лет назад человеком, уже не работающим в компании. Часто никогда в ней не работавшим.
Руководитель стартующей или уже состоявшейся структуры решает сам заняться разработкой сайта. В первом случае по причине отсутствия подчинённых, во втором по причине наличия времени и/или желания держать процесс под максимальным контролем.

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

Ниже приведено наше видение действий заказчика, которые привели бы его к разработке эффективного сайта.
1. Знайте, чего хотите

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

Приведём примеры правильно сформулированных целей:

Увеличить количество телефонных обращений / посещений торгового зала потенциальных клиентов на 15%.
Способ проверки: провести подсчёт количества обращений / посещений в неделю до создания сайта и после создания.

Избежать увеличения штата специалистов call -центра при положительной динамике роста продаж.
или
Обеспечить оптовых покупателей сервисом online заказа для увеличения скорости обработки заказов и снижения риска ошибок операторов.
Способ измерения: засечь среднее время обработки обращения до создания сайта (в данном случае чаще в паре с интранет-порталом) и после его запуска. Также можно посчитать количества жалом на ошибки операторов при оформлении заказов.

Создать сервис публичного пользования «назначение_публичного_сервиса» с посещаемостью не менее 10 000 человек в сутки, для последующего размещения рекламы.
Способ измерения: отслеживать динамику посещаемости.

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

В рамках разработки сайта Вам предстоит последовательно пройти следующие этапы:
Сбор и структурирование предварительных пожеланий относительно сайта и материалов для размещения;
Выбор подрядчика ;
Разработка и согласование технического задания;
Согласование и подписание договора ;
Контроль выполнения работ ;
Обучение ;
Приёмка работ ;
Период тестовой эксплуатации ;
Сопровождение и гарантийное обслуживание .

Если Вам нужно предположить сроки создания сайта, то, придерживаясь средних практических результатов, можно исходить из приведённых в таблице ниже. В таблице условно обозначены типы сайтов: 1 – визитка, 2 – корпоративный, 3 – промо-сайт, 4- Интернет-магазин, 5 – Интернет-портал. № Работа Длительность, дн.
1 2 3 4 5
1 Выбор подрядчика, согласование требований и заключение договора 7-14 14-21 14-28 14-28 14-28
2 Маркетинговое и технико-технологическое проектирование - - 21 0 – 21 28
3 Техническое проектирование - 7-14 - 0 – 14 -
4 Разработка креативных концепций - - 14-28 - -
5 Разработка дизайн-макетов 7-14 14-21 14-21 21-28 21-42
6 Вёрстка и наполнение 1-3 7 7-14 7 14-28
7 Разработка (приобретение) программного обеспечения, работы по интеграции, наполнению, тестированию, документационному обеспечению - 14-28 7-14 21-42 21-49
8 Тестовая эксплуатация - 30 10 60 90
Итого до запуска : 15-31 56-91 77-126 77-126 98-175
Итого до самостоятельной эксплуатации : 86-121 87-136 137-186 188-265

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

До того, как предпринимать какие-либо шаги, необходимо подготовить вводные материалы. Вам предстоит общение с людьми, которые не имеют ни малейшего представления ни о Вашем бизнесе, ни о Ваших целях и задачах. Более того, это общение будет многократным, т.к. требуется последовательно изложить свои ожидания относительно проекта всем потенциальным его участникам. Лучшим способом будет подготовить информационную карту и разослать его потенциальным разработчикам. В карту стоит включить следующие разделы :
Название Вашей компании / проекта.
Область деятельности и позиции на рынке, если это имеет значение для проекта.
Цель разработки сайта.
Перечень материалов, предполагаемых к размещению на сайте с указанием их объёма и степени готовности.

В действительной готовности материалов следует убедиться лично. Отсутствие или некомплектность материалов для размещения – одна из самых распространённых причин создания «мёртвых» сайтов.
Перечень функций, которые должен предоставлять сайт своим пользователям.
Информация о проектах-аналогах, если она у Вас есть.
Информация об уровне ИТ-квалификаии специалистов, которые предположительно будут эксплуатировать сайт.
Контактная информация.

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

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

Как же определиться с выбором основной группы потенциальных разработчиков? Здесь всё совсем просто. Делается это в три шага в течение 20 минут.

Шаг первый

Введите в любимой поисковой системе запрос «разработка сайтов ваш_город» и выпишите первые десять результатов. После этого введите «создание сайтов ваш_город» и снова выпишите первые 10. Вы только что избавились от компаний, не имеющих навыков поискового продвижения. Это крайне важный критерий, так как бОльшая часть посетителей Вашего сайта, скорое всего, будет приходить к Вам с поисковых систем. Заказывать сайт у тех, кто с поисковыми системами «не дружит» крайне нерационально.

Шаг второй

Последовательно просмотрите сайты каждой компании. Вас должны интересовать следующие моменты:
Перечень услуг. Является ли разработка сайтов основным видом деятельности, или же представленная до количества.
Перечень выполненных работ. Смотрите только последние 10-15 работ. Дело в том, что старые работы, как правило, не отражают текущей уровень профессионализма. Он может, как расти с ростом специалистов и наймом квалифицированных работников, так и падать в результате «текучки кадров». Обращайте внимание также на даты работ. Если студия делает 1 сайт в два месяца или реже, это должно вызвать подозрения.
Длительность работы компании и информация о количестве сотрудников, уровне развития инфраструктуры и технологического оснащения. Слишком маленькие компании могут быть нестабильны, как в долгосрочной перспективе, так и в рамках одного проекта. Работать с компанией, действующей менее 3х лет и насчитывающей менее 10 человек, без крайней необходимости не стоит.
Название юридического лица. Крайне желательно в данной отрасли работать с юридическими лицами, ведь Вам будет необходима длительная гарантия на результат работ, получить которую от частных лиц проблематично.
Контактная информация.

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

Сведите полученные данные в таблицу. Вычеркните непонравившихся разработчиков.

Шаг третий

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

Каждый из разработчиков в ответ на ваше обращение вероятнее всего скинет Вам «подшивку» документов, включающую:
Ценовое предложение (иногда с техническими предложениями)
Информацию о компании
Перечень клиентов / портфолио
Набор отзывов о собственной работе

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

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

Внимание! Очень популярным шагом среди разработчиков, предлагающих малые цены на создание сайтов, является требование абонентской платы за его использование. Заказчику не передаются исходные материалы, права на доменное имя и прочее. В результате, сайт фактически остаётся в руках разработчика и функционирует на условиях абонентской платы, выдаваемой за обязательное / необходимое сопровождение / поддержку.
Передаст ли разработчик все исходные материалы по сайту?
Будет ли в договоре / акте приёма-передачи указано, что исключительные имущественные права на вновь созданный сайт передаются Заказчику?
Готов ли разработчик гарантировать (приемлемы только финансовые гарантии!) свободу передаваемых Вам результатов от прав третьих лиц или наличие соответствующих лицензий? Являются ли лицензии бессрочными или подразумевают периодическео продление?
Готов ли разработчик нести финансовую ответственность за нарушения условий договора, в первую очередь за срыв календарного плана?
Будет ли сайт сделан грамотно в части будущей его индексации поисковыми машинами? Что именно будет сделано? Или эту работу нужно оплатить отдельно?
Каковы порядки сопровождения? Есть ли такая возможность? Какие расценки на типовые работы? Шаблоны типовых договоров на сопровождение ?
Готов ли разработчик в перспективе заняться продвижением? Есть ли у него такой опыт (запросите контакты продвигаемых)?
Есть ли возможность ознакомиться с примерами технических заданий / технических проектов, действующих проектов? Обратите внимание на то, понятны ли они Вам.
Есть ли возможность ознакомиться с примерами Руководств пользователя / Руководств администратора созданных ранее сайтов? Обратите внимание на то, понятны ли они Вам.
Каковы условия оплаты? Требуются ли авансы? Этапируются ли работы? Старайтесь не давать авансов более 30%. Это позволит поддержать высокий уровень мотивации разработчика на доведение работы до конца. 100% авансы неприемлемы вообще. Если потенциальный разработчик настаивает именно на таких условиях, лучше без крайней необходимости с ним не работать. Модель 50/50 является компромиссным вариантом. Условия оплаты 100% по факту подписания акта приёма-передачи, особенно, если они предложены разработчиком (хотя бы как один из вариантов), говорят о высокой устойчивости компании и о её уверенности в успешном выполнении работ.
На каком уровне возможно участие представителей Заказчика в проекте? Стоит отметить, что вопрос очень тонкий. Здесь важно получить ответ, нужный именно Вам. Дело вот в чём. Самым острым всегда является вопрос дизайна. Причём, как показывает практика, проблемы здесь плохо прогнозируемы и зависят от совершенно субъективных обстоятельств. Поэтому Вам нужно заранее знать, в каком объёме Вы сможете корректировать получаемые результаты. Иногда разработчики предлагают жесткие схемы, когда Заказчику выдаётся несколько концепций дизайна на выбор, к выбранной можно предоставить некоторое ограниченное количество замечаний. Иногда говорят, что будет делать, пока не понравится Вам. Это крайние варианты. Вам нужен вариант, который, как это ни банально звучит, нужен Вам:

Если Вы, либо лица, принимающие решения, требовательны к мелочам, или если в Вашей компании есть специалист по техническому дизайну, выбирайте разработчика, который сможет предложить модель с карандашным макетированием, ежедневной отчётностью и возможностью организации совместной работы своего дизайнера с вашим(и) специалистом(ами) на своей или Вашей территории. Это напряженный режим, но только он позволит Вашему специалисту оказать на разработчика необходимое влияние, а чересчур требовательному руководству почувствовать себя соавторами. Если вы не договоритесь о такой модели сразу, согласование дизайна затянется на месяцы. Сомневаетесь? Расспросите коллег и знакомых, кому доводилось участвовать в разработке сайта.

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

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

Отрицательные или невнятные ответы на эти вопросы должны обязательно насторожить Вас в отношении данного разработчика.
6. Определите задачи до начала работ

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

Примечание: отсутствие единого названия связано с тем, что у разработчиков на сегодняшний день нет устоявшейся формы этого документа. Единственный стандарт, который мог бы её регламентировать – ГОСТ Р 34.602. Но он, во-первых, описывает техническое задание на разработку информационной системы, а во-вторых, последний раз переиздавался в 91 году. И теперь часть студий адаптирует его под задачи создания сайтов и сегодняшние реалии, в результате чего получаются совершенно разные «стандарты», а другая – не признаёт его подходящим или попросту не знает о его существовании.

Как бы ни назывался документ, критериев его правильности всего три:
Он Вам понятен.
Он содержит все положения, которые Вас интересовали.
Он достаточно подробен, чтобы минимизировать разночтения, но не раздут незначительными деталями.

Расшифруем эти пункты :

Первый. С ним всё просто. Вы должны понимать каждое слово ТЗ и все эти слова вместе.

Второй. Всё, что Вы наговорили и записали до начала переговоров и в их процессе должно содержаться в ТЗ. Одна оговорка: часть моментов может попасть в текст самого договора, часть в выделяемый иногда отдельным приложением календарный план.

Третий. Самое больное. Детализация ТЗ. Очень хочется написать что-то, что подойдет для 95% Заказчиков, но в здесь это невозможно. Вопрос детализации ТЗ очень индивидуален. Ответ на него зависит от сроков реализации проекта, уровня понимания задачи специалистами стороны Заказчика, уровня сложности проекта и его важности, доверия между Заказчиком и разработчиком и многого другого. Всё, что мы можем дать, это одно правило, и 14 вопросов, на которые в ТЗ должны быть даны ответы.

Итак правило: Ели не имеете чётких представлений о желаемом результате, признайте это сразу.

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

Что не следует забывать отражать в ТЗ (в простых проектах часть этих пунктов можно исключить):
Цель разработки сайта.
Информацию о целевой аудитории (для каждой из целевых групп, следует указать предполагаемую цель посещения ими сайта).
Описание групп пользователей сайта (если предполагается регистрация на сайте и разделение прав пользователей).
Структура разделов сайта.
Описание функций каждого раздела и сайта в целом в т.ч. в разрезах возможностей отдельных групп пользователей.
Информацию о фирменном стиле компании и требованиях к графическому оформлению, желательно получить схематичные макеты типовых (неповторяющихся функционально) страниц.
Требования к наполнению. Состав и объем материалов, размещаемых на сайте. Даты их передачи разработчику.
Требования к первичному продвижению. Перечень мероприятий по оптимизации и продвижению сайта, включенных в разработку.
Требования к документированию: состав и глубину проработки пакета руководств и регламентов.
Требования к размещению. Информация о том, где сайт будет храниться физически, под каким доменным именем будет действовать, какое количество и объём электронной корреспонденции будет проходить через почтовые ящики на сайте и т.п.
Требования к интеграции. Информация о том, с какими программными средствами, эксплуатируемыми или планируемыми к эксплуатации у Заказчика сайт должен взаимодействовать, какие данные получать, а какие отдавать.
Вопросы лицензирования и авторских прав.
Гарантийные обязательства и порядок гарантийного обслуживания.
Порядок приёма-передачи работ.

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

Если Вы не выделяете ТЗ в отдельно оплачиваемую работу, Вам будет значительно сложнее предъявлять требования к его качеству, более того, на Вас будут давить сроки начала работ, чем непременно воспользуется разработчик, предложив поверхностное ТЗ. Поверхностное ТЗ всегда на руку разработчику, ведь юридически он может выполнить общую задачу «на сайте должна присутствовать новостная лента» как угодно, с любой, а чаще с малой, глубиной проработки. Если же Вы ожидаете разделения новостей по категориям, ведения архива новостей, иллюстраций к новостям, возможности импорта новостей с других сайтов и экспорта своих, это нужно писать в ТЗ. Плюсы создания ТЗ за рамками договора, в процессе его согласования в определённой экономии, т.к. разработчик не станет делать значительной наценки из-за подготовительных работ.

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

Для принятия решения об оплате ТЗ или отказе от неё заполните таблицу (обведите ответы): № Вопрос ТЗ до договора ТЗ как этап работ
1
Предполагаемая разработчиком ориентировочная длительность работ превышает 40 дней? Да Нет
2
Какое количество сайтов-аналогов (подобных по решаемым задачам, функционалу) Вам известно в сети Интернет.? Менее 30 Более 30
3
Имеет ли место работа с денежными средствами или ценными бумагами на сайте? Да Нет
4
Должен ли сайт взаимодействовать (получать / отдавать данные) с какими-либо используемыми или планируемыми к использованию программными средствами? Да Нет
5
Каковы ожидания относительно посещаемости сайта? До 500 человек в день Более 500 человек в день
6
Является ли сайт основой бизнеса или лишь элементом комплекса маркетинга? Элемент Основа

Если Вы обвели хотя бы один из пунктов в столбце «ТЗ как этап работ», лучше заказать ТЗ отдельно.
7. Следите за ценой

Есть риск как сверхвысоких, так и сверхнизких цен. По цене часто можно судить о качестве. Например, если вам предлагают сделать корпоративный сайт за 50 000 руб. и 40 дней времени работы, структура расходов разработчика будет выглядеть примерно (оптимистично) следующим образом: № Статья затрат Сумма
1 Приобретение лицензии на CMS 5 000
2 Приобретени доменного имени и хостинга сроком на 1 год 2 700
3 Затраты на эксплуатацию оборудования, электричество, расходные материалы, транспорт, связь и прочие отчисления, аренду офиса 6 000
4 Фонд оплаты труда 28 300
За вычетом подоходного налога 13% 24 621
5 Налог с оборота (6%), допустим, что используется именно такая форма УСН 3 000
6 Поддержание минимального уровня рентабельности в 10% 5 000
Итого: 50 000

Даже при беглом взгляде на таблицу бросаются в глаза две вещи.

Пункт 3 – невыполним. Т.к. в проекте будут участвовать как минимум 2 человека. Для достижения сколько-либо адекватного результата должно быть не менее 4х профильных специалистов – проектировщик-координатор (ведущий инженер), дизайнер-верстальщик, программист, специалист по информационному наполнению и продвижению (в народе – контент-менеджер), но пока говорим о крайних условиях. Им нужно не меньше 4*2 = 8 кв. м. офисных помещений, а при цене квадратного метра в 700-1000 р./месяц. (это в Краснодаре, не в Столицах!), очевидно, что только аренда «съест» не менее 7 470 рублей за 40 дней.

Пункт 4 – странен. За 40 дней два специалиста, пусть даже действуя не всё время вдвоём (допустим, что один из них проработает только половину времени) заработают 24 621 руб. Это значит, что один человек за 20 календарных дней заработает 8 207 руб. чистых денег, а другой за 40 – 16 414. Страшно даже предположить, какой уровень качества обеспечат специалисты, работающие за такие деньги. Ясно, что это должны быть либо студенты, либо люди, одновременно выполняющие не менее 3х проектов. Минимальная стоимость работ, при которой подрядчик сможет обеспечить достойное качество, составляет 3 000 – 5 000 руб. за 1 день работы одного человека в регионах и 6 000 – 10 000 руб. – в Столицах. На цифрах выше начинается «перегиб» в другую сторону. Суммы больше заявленных, уже призваны обеспечить явно излишние (с точки зрения интересов Заказчика, конечно) «бонусы» для разработчиков, прямая или косвенная полезность которых для результата конкретной работы весьма и весьма сомнительна.

Поэтому, даже стремясь сэкономить, не навредите результату. Чтобы не получилось, как в притче: «- А можешь 6 шапок из одной шкуры? — Могу! – А 10? – Могу!» Торгуясь, важно помнить, что речь не идёт о товаре в магазине, который уже произведён, и где торгом Вы лишь уменьшаете наценку продавца, речь идёт о вновь создаваемом продукте, который будет стоить столько, сколько Вы за него заплатите. При этом не нужно думать, что большой бюджет – гарантия успеха. Вовсе нет, часто наоборот. Гарантия успеха в обоснованном бюджете, детальной предпроектной подготовке, грамотном выборе подрядчика и строгом, непрерывном контроле работ.
8. Изучайте документы

Всё что Вам пообещали, должно быть просто и понятно изложено в документах. Фактически в момент подписания договора 80% Вашего участия в нём позади. Кроме, конечно, моделей разработки с высокой частотой предоставления отчётов или регулярным присутствием представителей Заказчика на территории разработчика. Допускать мысль о том, что «по ходу уточним» не стоит. Договариваться нужно сразу. Опять же, следите, чтобы в документах Вам было понятно ВСЁ. Если что-то непонятно, знайте, там лежат грабли, на которые придётся наступить в процессе работ. Лишний день или два, которые вы потратите на согласование мелких деталей в текстах документов, сэкономят вам неделю, а то и две длительности согласования результатов самих работ.
9. Контролируйте процесс

Если вы не используете модель разработки с высокой частотой предоставления отчётов или регулярным присутствием представителей Заказчика на территории разработчика, не пожалейте времени раз в 3-4 дня прозванивать ответственному со стороны разработчика. Спрашивайте, как идут дела, нет ли вопросов или сомнений, пусть даже мелких, можно ли взглянуть на промежуточные результаты. Важно именно звонить, а не писать электронные письма. Если время позволяет, посетите разработчиков лично (приглашать к себе не всегда оправдано, т.к. подготовка визита и он сам отнимут у разработчика не меньше 6ти часов рабочего времени). Никогда, как бы сильно Вы ни доверяли разработчику, какими бы жесткими не были условия договора, не пускайте его на самотёк. Следствие Закона Мерфи о том, что события, предоставленные сами себе, развиваются от плохого к худшему в нашей отрасли действует ВСЕГДА.
10. Проверяйте результаты

Когда приходит время согласования промежуточных или итоговых результатов, проверяйте их досконально. Желательно сразу выделите от 1 до 8 (в зависимости от объёма принимаемых работ) часов и лично, в присутствии Разработчика (даже, если он будет против, требуйте, чтобы так и было) проверьте всё! Зайдите в каждый раздел, в том числе и административный, попробуйте заполнить имеющиеся формы, в том числе и неадекватными данными. Смотрите за поведение системы. Сверяйте каждый пункт ТЗ с полученным результатом. Если Вы что-то упустите и заметите после подписания акта приёма-передачи, скорее всего, разработчик не откажет Вам в доработках (тем более, если прописаны гарантийные обязательства), но все работы, выполняемые после сдачи проекта, будут выполняться медленно, т.к. специалисты уже будут заняты на других проектах. Все недочёты документируйте, подписывайте протокол разногласий в двух экземплярах (печатей на него ставить не обязательно, достаточно подписей ответственных лиц со стороны Заказчика и разработчика), в протоколе должна присутствовать дата устранения недостатков, или, если назвать её на месте не представляется возможным, сроки согласования этой даты.
11. Используйте

Тут просто. Сайт должен быть актуален. Не обязательно постоянно выкладывать на него высосанные из пальца новости (хотя, если плотно займётесь раскруткой, скорее всего, придётся) или писать себе сообщения в гостевую книгу. Но то, что на сайте размещено, в первую очередь в части контактной и ценовой информации ВСЕГДА должно быть актуально. Все сообщения, получаемые с сайта, ВСЕГДА должны обрабатываться в течение 4х часов и не более. Все пустые разделы, должны быть заполнены или скрыты. И, раз уж мы вспомнили о новостях, если на сайте есть хоть какие-то даты, они не должны показывать, что сайтом занимаются. Если есть дата разработки, она должна быть оформлена в формате Год_разработки-Текущий_год, например 2003—2008. Если сделали новостную ленту, что ж соизвольте писать туда не реже раза в месяц. Даты утверждения в размещенных прайс-листах, также, должны быть свежими.
12. Продвигайте

Какой бы цели не преследовал сайт, для её достижения необходимо, чтобы на него приходили люди. Именно они получают Ваши рекламные обращения, пользуются Вашими сервисами, голосуют за Вас и так далее и тому подобное. Поэтому рано или поздно, а в современных условиях, скорее всего рано, Вы столкнетесь с необходимостью продвижения сайта. Безусловно, бывают ситуации, когда продвижение сайта является нецелесообразным, но это, как правило, как раз те ситуации, когда его создание было нецелесообразным. Типовой случай – создание сайта региональной компании, чьи товары / услуги не упоминаются или упоминаются крайне редко пользователями Интернет в её регионе. Но частный случай. Почти всегда продвижение окажется необходимо. Вопросы поискового продвижения или, как модно говорить «раскрутки» сайтов выходят за рамки этой статьи, и касаться их здесь мы не будем. Дабы не перегружать, да и просто из уважения к предмету, заслуживающему подробного описания. Скажем лишь, что исходить из того, что сайт придётся продвигать, а лучше бы продвигать силами той же компании, что сайт разработала: это, как правило, менее затратно – нужно с самого начала.

Сергей Карулин,
Студия «SpellSystems» ООО «Кубнет»,
Краснодар, 2008 г.

 

Метки: создание сайтов, сайт

Cloudim - онлайн консультант для сайта бесплатно.