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