Каким сайтам веб-студии чаще всего отказывают в поддержке и продвижении, от чего это зависит и можно ли найти компромисс.
Все причины отказов в сотрудничестве можно разделить на две группы.
Первая: студия просто не работает с языком программирования/фреймворком/CMS, на которых создан сайт. Здесь мы подразумеваем, что программисты не знакомы с программным обеспечением и его особенностями достаточно близко, чтобы в разумные сроки решить поставленные заказчиком задачи. Обычно это означает, что сайт создан на какой-то редкой платформе, с которой разработчики ещё не успели плотно поработать, но бывают и другие причины. Студия может специализироваться на одной конкретной платформе и вообще не брать проекты на любой другой. Некоторые студии идут ещё дальше: они не берут на поддержку и развитие сайты, которые были созданы не у них. Выход из подобной ситуации прост — продолжать искать. Обязательно найдутся разработчики, которые работают с вашим кодом. Но, возможно, в другом городе.
Вторая распространённая причина отказов — в том, что сайт по каким-то параметрам плох: на нём нельзя либо очень трудозатратно выполнять необходимые доработки. В эту категорию чаще всего попадают:
— Конструкторы. Безусловный лидер по числу отказов в доработке. Возможности для развития сайта ограничены функционалом конструктора, поэтому глобальных изменений на сайте проводить обычно нельзя. Кроме того, может быть проблематично создать достаточно простые сущности, которые по умолчанию легко редактируются в других системах. При работе с конструктором студия вынуждена работать только с тем функционалом, который предоставлен в «Личном кабинете» и не редактирует код сайта напрямую. Кстати, о коде. Для того чтобы предоставить вам возможности для создания сайта с нуля самостоятельно, разработчикам пришлось пожертвовать чистотой конечного кода. Поэтому сайт-конструктор по умолчанию генерирует много мусорного кода, который невозможно оптимизировать. И это весьма веская причина для отказа от продвижения подобных сайтов.
— Некоторые шаблонные решения. В основном речь идёт о различных площадках формата маркетплейс, которые предлагают неограниченному кругу лиц купить уже готовый сайт. Доработки предполагаются минимальные: в лучшем случае вам помогут создать дополнительные типовые страницы, заменят лого и текстовую информацию, в рамках уже имеющихся в шаблоне возможностей отредактируют меню и раскрасят сайт в корпоративные цвета. Но, скорее всего, это вам придётся делать уже самостоятельно — взаимодействия с разработчиком нет. Недостаток шаблонов в том, что покупаете вы кота в мешке: оценить код заранее невозможно, так что ориентироваться можно только на дизайн. А загружать работы в маркетплейсы могут разработчики очень разного уровня, что однозначно сказывается на качестве. Даже если вы покупаете шаблон у компании, которая на них специализируется и производит их сама, — невозможно заранее угадать, какого уровня будет код, как легко его будет дорабатывать.
— Одностраничный сайт. Если вас интересует SEO-продвижение, но в распоряжении только он, то с вероятностью 99% вам откажут. Лендинги нельзя продвигать по SEO, они оптимизируются единоразово — и студии очень не любят браться за такую работу. Если лендинг хорош, то делать на нём практически нечего, а значит — не показать и значимых результатов. Если же он плох, то придётся создавать его с нуля. И здесь результат не всегда стоит вложений.
— Некоторые самописные системы. Ситуация похожа с шаблонами. Нельзя сказать, что самописные системы по умолчанию плохи, — тут всё зависит от мастерства разработчика. Поэтому предварительно у клиента обычно запрашиваются доступы к коду. И уже после того, как найдены критичные ошибки, выносится решение о возможности/невозможности работы с данным сайтом.
— Сайты на популярных бесплатных CMS. Например, Wordpress или Joomla. Недостатков у этих систем порядочно. Например, не всегда хватает заложенного функционала для реализации всех идей заказчика. А добавляется он иногда очень проблематично, особенно если речь идёт об интеграции со сторонними сервисами и программами. Для подобных задач обычно используются уже готовые модули и плагины, которые учитывают особенности системы. Но пишутся эти модули под конкретную версию CMS. Это значит, что плагин для версии, например, 2.2, может не работать либо работать некорректно в версии 2.3. Ещё одна распространённая проблема в том, что разработчики стремятся заложить побольше самого стандартного функционала в систему. И не всегда этот функционал необходим конкретному сайту. Ненужные функции усложняют работу в административной панели, создают лишнюю нагрузку на сервер, требуют дополнительных финансовых вложений.
Как найти компромисс
Так что же делать в подобной ситуации? Мы предлагаем два варианта развития событий, при которых вы и студия окажетесь в плюсе.
Первый и очевидный — создать новый сайт. Не обязательно он будет стоить дорого. Если вы с разработчиком грамотно подойдёте к техзаданию и заложите только нужные вещи, то можно получить вполне бюджетное решение.
Но не всегда новый сайт — это выход. Бюджета может не быть даже на экономрешение, перед компанией могут стоять другие бизнес-задачи. В этом случае нужно смириться с недостатками той платформы, на которой создан сайт, и пересмотреть список задач — оставить только те, которые действительно нужны для вашего бизнеса. Если вы поясните разработчику, что понимаете риски — невозможность прогнозирования сроков выполнения задач, а также реализуемость сложного функционала, то вполне можно найти компромиссное решение.
Чтобы проект не вырос в чёрную дыру, поглощающую ваши средства и время, лучше договориться о тестовом периоде, на который вы дадите несколько задач, и работать в таком цикле:
- постановка задачи, предварительная оценка исполнителями степени её реализуемости и времени на выполнение;
- выполнение, фиксация найденных особенностей системы и затраченного времени;
- сравнение прогноза с фактом;
- постановка следующей задачи, оценка времени на выполнение и его корректировка в соответствии с ранее полученными данными.
Так, по итогам выполнения первых 3–4 задач вы можете прийти к выводу, что прогноз и факт расходятся, например, на 20–30%, понять, что это приемлемая вилка и в таком режиме можно продолжать работать с сайтом. Или же что некоторый жизненно важный функционал реализуем только через «костыли» — решения, которые ненадёжны, могут сломаться и работать не всегда корректно, плохо масштабируются. А без этого функционала вложения в сайт не имеют смысла. В любом случае у вас будут конкретные данные: понимание, что можно и нельзя сделать, как рассчитывать бюджет.
