Заблуждения и мифы о сайтах (часть 2) -Docode Development: Создание сайтов и WEB-приложений

Заблуждения и мифы о сайтах (часть 2)

Мифы и заблуждения о сайтах

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

  • Почему так дорого?
  • А мы будем сразу в первых строках гугла?
  • Тебе же это быстро!
  • Это же просто!
  • А давайте это поменяем!

Продолжим с другими запросами, которые на первый взгляд кажутся Клиентам простыми и очевидными, но по факту так же являются заблуждениями.

Хочу как у них, с тем же функционалом, но легче, чтобы быстрее грузилось! И недорого!

Как ни парадоксально, такие пожелания появляются касательно каких-то крупных систем или сервисов. Например, аналогов каких-либо маркетплейсов. Дескать, хочу аналогично, с таким же функционалом, но чтобы работало быстрее и лучше. Возникает вопрос: когда вы смотрите условный ebay с множеством товарных групп, предложений фильтров и тд, вы задумываетесь, какое количество людей трудятся над тем, чтобы система работала хотя бы относительно быстро и постоянно дорабатывалась? При этом и у пользователей и у администраторов подобных маркетплейсов были все необходимые для работы функции. Какая нагрузка на сервер при этом происходит? Ответ тут довольно прост и банален: если вы хотите купить “мерседес” по цене “жигулей”, готовьтесь, что он приподнесет определенные сюрпризы.

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

Мне же только доработать!

Да, порой бывает так, что доработка сопоставима по срокам и стоимости со всем изначальным проектом. Например, есть сайт на конструкторе (или просто изначально “криво” собранный сайт), нужно внести дополнения в функционал, которые данный конструктор не позволяет. Даже есть доработка будет в том, чтобы внести дополнительный тип пользователей на сайт для просмотра, например, закрытых статей. Вроде мелочь. Но… такай доработка может потребовать полного переноса сайта на новую платформу, то есть, фактически полностью собрать весь сайт с нуля на навой платформе, плюс перенести всю прежнюю информацию (которой за несколько лет работы предыдущего сайта может накопиться очень много), а так же сделать корректные редиректы со старых страниц на новые. И не забываем, что нужно внести еще и дополнения. Уже по этим моментам видно, что объем работ вырастает в разы относительно изначальной работы по созданию “изнаального” сайта. Оттуда и рост стомости.

Если же менять систему не требуется, то и в этом случае объем работ будет больше, чем кажется изначально. Наиболее простой и наглядный пример – через ремонт в квартире. Вы, например, хотите поставить перегородку в комнате. Сама эта перегородка, например, из гипсокартона с деревянным каркасом, стоит, к примеру, 500$. Но не забывайте, что еще есть ряд работ по приведению ее в вид, подходящий под вашу комнату, возможные повреждения обоев (как ни крути, строительные работы, 100%-й аккуратности быть не может априори), параллельно при возведении перегородки может пострадать старая штукатурка на стенах или всркыться никому (кроме первых строителей) неизвестные полости и огрехи в несущих конструкциях, и много чего другого. Да и такую “мелочь”, как окончательную чистовую уборку никто не отменял. Само собой, в программировании и разработке “повреждений” образуется меньше, чем в строительстве, но они неизбежны, как и “чистовые работы”. И, кроме того, сразу неочевидны.

А это возможно сделать?

Возможно все, за исключением, наверное, зеркально фона экрана. Более важный вопрос: а насколько это рационально? Если уже есть полное понимание, как и что должно работать, поведение пользователей при взаимодействии с Продуктом, какие-то маркетинговые аспекты, то да, их нужно делать. Но довольно часто получается так, что полного понимания изначально нет, а “хотелок” много. Отсюда вытекает совет, аналогичный для всех стартаперов: выпусти на рынок продукт, который закроет основные потребности клиента,  проверь свои гипотезы и на итерациях уже дорабатывай свой продукт. Поэтому, важнее понимать не “возможность”, а целесообразность.

Это же очевидно!

Правда? Нужно понимать, что вы знаете всой бизнес лучше, чем ваш подрядчик, и то, что для вас очевидно, для него – нет. И наоборот, разработчкиу ряд вещей кажется очевидными, но Заказчик о них даже не думает, для него все происходит “само”. Поэтому, при обсуждении даже мелкого проекта, очень важно проговаривать и прописывать максимальное количество аспектов, чтобы одинаково понимать конечный результат проекта.

Это же просто скопировать!

Далеко не всегда. Как упоминалось выше, в разных системах требуется адаптация функций/внешнего вида под работу логики вашей конкретной системы (даже если у “донора” та же CMS, что и у вас).

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

К тому же, нужно учитывать возможность аспектов, оговоренных к разделе “только доработать”.

Итоги

Подытоживая вышесказанное, замечу, лучше сразу обратиться к специалистам, чтобы они могли примерно оценить объем работ, и уже от этого отталкиваться. При этом не забывая, что затраты могут быть увеличены на 50-70% от ожидаемых до определения состава работ и хотя бы предварительного технического задания.