Доработка сайта - реальный кейс о неприятной ситуации с одним проектом

Ситуация

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

Скрытая проблема

Немного углубившись в проект, стало понятно, что он в принципе не пригоден для продвижения в плане поисковой оптимизации. Весь контент каталога отдается в JS. А для площадок SEO — это ключевой источник трафика. За счет большого количества контента (карточки товаров разных поставщиков, пересечения фильтров и т.д.) создается преимущество в плане SEO.

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

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

Почему так происходит?

У меня есть 2 версии причин подобного:

1. нет человека, который охватывал бы весь проект в целом. Есть разные узкие специалисты, которые не особо интересуются смежными областями — например, юзабилити специалисты, дизайнеры, программисты. Каждый отвечает за свой блок, и решает локальную задачу, не задумываясь о глобальных проблемах проекта.
2. нет карты движения пользователя (CJM). Т.е. нет полного понимания, как пользователь придет на ваш сайт, какое он получит обслуживание и т.д.

Как уменьшить риски подобных ситуаций в своих проектах?

Во-первых, изучать мат часть. Нужно хотя бы базово понимать основные элементы веб-проектов.

В отдельной статье мы разбирали основные понятия веб-проектов.

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

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

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

Допустим риск уже реализовался. Что делать?

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

2. Получить стоимость по доработкам от разных компаний. Важно только получать оценку по конкретному ТЗ, а не по общему описанию.

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

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

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

6. В проекте должна быть панель основных метрик. В самом простом случае это посещаемость, новых пользователей, заказы, приходы (пополнения).

Именно показатели являются суровым беспристрастным судьей — проект развивается или стагнирует.

Заключение

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

Изучайте интернет-маркетинг, продукт-менеджмент, веб-разработку — эти знания помогут вам принимать более правильные и взвешенные решения.

Источник: https://falconspace.ru/blog/nepriyatnaya-istoriya-s-odnim-proektom