10 ошибок начинающего разработчика сайтов

1. Прислать заказчику типовой бриф

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

2. Продавать то, что научились делать, а не то, что требуется заказчику

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

3. Неверно оценить бюджет и сроки

   
   В погоне за заказом и хоть каким-то заработком начинающий разработчик часто готов предложить демпинговые цены и сроки. Практически всегда такой проект обходится заметно дороже (причём, и заказчику, и разработчику), чем сразу рассчитанная справедливая цена. Почему? Назначая низкую цену, разработчик не в состоянии вложить в проект серьёзные ресурсы и выполняет задачу поверхностно; у недовольного заказчика возникают замечания и коррективы (а, как известно, исправлять работу труднее и дороже, чем сразу делать её правильно); в результате разработчик либо безответственно бросает проект, либо тянет его без сил и интереса, стараясь дотащить заказ до конца, плюнув на прибыль. То же касается и сроков.

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

4. Ориентироваться в первую очередь на модные технологии

   
   Мало кто из свежеиспечённых выпускников технических вузов, объединившихся в команду разработчиков сайтов и веб-приложений, думает о том, что технологии (языки и методы программирования, сервисы, библиотеки и алгоритмы), которым их только что обучили, для коммерческого сектора Интернета имеют чаще всего глубоко вторичное значение. Пассажиру неважно, на каком топливе движется его транспортное средство и какой марки в нём стоит двигатель, — его заботит в первую очередь прибытие в место назначения — точно и в срок. У каждого сайта есть своя задача, своё назначение, а также своя среда существования, в которой выполняется эта задача, и свой жизненный цикл. Если это учтено и работает — сайт успешен, если нет — он провален. Технологии имеют значение только и исключительно в той степени, в какой они работают на задачу.

5. Использовать побольше сервисов, предлагаемых «движком» сайта (CMS-платформой)

   
   Нередко можно встретить сайты, построенные на популярных «движках» (от Джумлы до ВордПресса и Битрикса), в которых включены какие-то программные сервисы — только по той причине, что они есть в движке. Определение географии посетителей по IP, возможность комментирования едва ли не любого блока текста на странице, подгрузка почти всего контента на страницу Ajax'ом, интеграция всего и вся с социальными сетями, различные модули, анализирующие профиль и поведение пользователя — всё это висит на каждой загружаемой странице по принципу «а что? пускай будет!», висит, тормозит, сбоит, бесит посетителя и заставляет заказчика верить в не зря заплаченные такому крутому разработчику деньги. В действительности же для каждого использованного сервиса у разработчика должен быть чёткий ответ — зачем он нужен и какую задачу решает (не сам по себе, а в контексте задачи сайта).

6. Использовать тот «движок», который знаком, а не тот, который требуется для проекта

   
   Несмотря на то, что практически все современные «движки» сайтов (как коммерческие, так и платные) позиционируются на рынке в качестве универсальных конструкторов, у каждого из них есть свои сильные и слабые стороны, есть своя специфика. Точно такая же специфика есть и у любого разрабатываемого сайта — структурная и функциональная сложность, планируемая посещаемость, одновременная нагрузка и т.д. Одно должно соответствовать другому. «Движок» должен быть выбран потому, что он позволяет наиболее оптимально выполнить задачу, а не потому что разработчик умеет работать только с ним.

7. Ориентироваться на сайты конкурентов

   
   Как правило, заказчик, длительное время работающий на своём рынке, неплохо знаком со своими конкурентами и, конечно, с их сайтами тоже. Поэтому, когда он обсуждает с разработчиком свой будущий сайт, нередко в качестве примера рассматриваются сайты конкурентов — и задача ставится в терминах «надо, как у них» или «надо круче, чем у них». И то, и другое неверно — поскольку означает попытку, по сути, догнать чужой паровоз. Правильная методология для разработчика — внимательно изучить сайты конкурентов, их слабые и сильные стороны, удачные решения, — но делать проект, ориентируясь на нужды потребителей, а не на предложения конкурентов.

8. Ориентироваться на вкус заказчика

   
   Вкус заказчика — того, кто платит за получаемый продукт, очень важен, но гораздо важнее, чтобы сайт нравился той целевой аудитории, которой он предназначен, — т.е. не заказчику, а клиентам заказчика, потребителям его товаров или услуг. Лично заказчик может любить мороженое — но когда он идёт на рыбалку, то берёт с собой не его, а червей — потому что рыбы любят червей. Так почему же в Интернете должно быть иначе?

   Визуальными ограничителями (и критериями оценки) в разработке сайта могут быть требования фирменного стиля, но не личного вкуса заказчика. Самый кошмарный вариант этой ошибки — когда заказчик устраивает коллективное обсуждение дизайна, а разработчик на это соглашается.

9. Представить больше 2-3 вариантов дизайна

   
   Если дизайнер предлагает больше 2-3 вариантов дизайна — это верный признак того, что он не вник в задачу, не нашёл для неё наиболее точное, оптимальное, эффективное решение — а вместо того играет с заказчиком в «угадайку». Заказчик, если соглашается (и хуже того — если сам требует) увидеть большое число вариантов, — в свою очередь, не сумел сформулировать для себя и для разработчика точное описание задачи и не выработал для себя критериев оценки при её приёмке. Эффективное и работающее решение в такой ситуации может появиться только случайно — и с очень невысокой вероятностью.

10. Взять сайт на ведение

    
    Даже для грамотно спроектированного, профессионально разработанного и удачно выведенного на рынок сайта можно совершить ещё одну серьёзную (и, к сожалению, распространённую) ошибку. Это когда разработчик берёт на ведение сайт, сделанный им для заказчика. «А что? — рассуждает заказчик, — они сделали сайт, они в нём разбираются, так пусть они его и ведут».

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

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

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