Телефон: +38 050 5605132, mail: info@aquaweb.com.ua

Нужен ли проект для курятника

Проектирование в строительстве и в сайтостроении

Процесс проектирования - очень важный этап в разработке сайта, особенно интернет-магазина. При этом, очень много людей пренебрегают данным процессом, что на наш взгляд довольно странно. Возьмем, к примеру, строительство дома. Здесь никто из клиентов наверное не согласился бы пренебречь этапом проектирования, это всем понятно и привычно. Перед тем как строить дом, инженеры делают проект. Готовятся чертежи, делаются необходимые расчеты. При этом в изначальную задумку архитектора могут вноситься изменения вызванные необходимостью обеспечения прочности конструкций, а также особенностями строительных материалов. После завершения разработки проекта (именно после разработки проекта, а не до), подсчитывается смета, которая дает ответ на вопрос, сколько конкретных материалов необходимо для постройки дома и в какую сумму они обойдутся. Далее, готовится документация, описывающая процесс постройки дома, строятся диаграммы Ганта и пр. Все это планирование необходимо для того, чтобы дать ответ на два вопроса: сколько это будет стоить и когда это будет построено. И только потом, бригада строителей разных квалификаций приступает непостредственно к строительству, по уже готовому плану.

Проект для курятника

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

Небольшие изменения SEO

Приведу пример: клиент присылает документ с рекомендациями SEO специалиста, описывающими правила динамической генерации содержимого meta-тегов на страницах категорий товаров в зависимости от выбранных пользователем фильтров. Клиент задает всего два вопроса - сколько будет стоить и когда будет сделано. Но мы понимаем, что генерация любых динамических данных - это дополнительные запросы к базе-данных. Кроме того, в процессе реализации мы можем столкнуться с серьезными проблемами, если выяснится, что изначальная архитектура программного продукта не позволяет например просто получить необходимые нам данные в определенном месте шаблона страницы. Но увидим мы эти проблемы только тогда, когда реально начнем работать над данной задачей. Посмотрим опять на то, как это делается в строительстве. Например, у клиента есть одноэтажный дом, и вдруг он просит вас взять и надстроить еще один этаж сверху. Реальна ли такая задача? Конечно же реальна. Но, никому в добром здравии не придет в голову идея просто взять и начать надстраивать второй этаж. Сначала делается проект реконструкции, проверяется фундамент здания, замеряются размеры стен, анализируются материалы и производится подробный расчет, с той целью, чтобы узнать, а выдержит ли имеющаяся конструкция еще один этаж сверху. Если в процессе разработки такого проекта, выясняется, что нет, то проектируются необходимые конструкции усиления. И только потом, приступают к строительным работам. С сайтами точно также. Конечно, можно сразу сесть писать код, часто так и делают чтобы проверить гипотезу (к счастью последствия неудачи здесь могут быть не настолько трагичными как со зданиями), но часто можно упереться в то, что увелившееся количество запросов к БД (точно как в случае возросшей нагрузки на стены здания) начинает сильно сказываться на скорости загрузки страниц. И тогда тот же SEO специалист прибегает вновь с претензиями, что теперь сайт не вписывается в определенные лимиты по скорости. А исполнитель попадает в довольно сложную ситуацию, поскольку результирующий объем трудозатрат и объем накопившегося технического долга оказывается несовместимым с названными впопыхах сроками и ценой.

Одна история редизайна

Давайте рассмотрим еще один, уже конкретный, пример. Мы не будем акцентировать внимание на конкретном магазине, но однажды мы столкнулись с такой задачей: клиент попросил натянуть новый дизайн на уже готовый и продающий интернет-магазин. Редизайн был заказан сторонней фирме и был очень глубоким, продумывали высококлассные специалисты (со слов клиента). Однако в процессе работы по натяжке нового дизайна, когда в мертвый изначально макет попытались вдохнуть жизнь, начало выясняться огромное количество нюансов, о которых как оказалось не задумывался ни дизайнер, ни клиент, и даже мы при первом просмотре. Не были продуманы следующие моменты: товары в категориях у нас разные, с разными характеристиками, а отрисована страница только для товара одной из категорий но с очень сильным акцентом именно на характеристики (вместо простой таблички дизайнер предлагал набор выпадающих списков); есть , а отрисована была только страница дочернего товара (для родительского товара имеющийся макет не подходил вообще) и т.д. Многие из проблем всплыли уже после того как мы взялись за работу. В результате, столкнувшись с данными проблемами, нашим сотрудникам (менеджеру, программисту и верстальщику) пришлось фактически стать дизайнерами и проработать недостающее число страниц. Проблемой также было то, что клиент не захотел дозаказать дизайнерам, работавшим над макетами, дополнительно продумать всплывшие спорные моменты, а по своей инициативе дизайнеры тоже этого делать не стали. При этом, в отличии от дизайнеров, у нас, как у находящихся на передовой, не было другого выбора как доводить макет до конца своими силами, поскольку мы взяли на себя ответственность за работоспособность сайта.

Товар с вариантами в старом дизайнеПосмотрим на пример страницы в старом дизайне.

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

Кликайте для увеличения картинки.

Новый макет дизайна

Новый макет дизайна

А вот так выглядит новый макет дизайна, присланный клиентом:

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

На первый взгляд все было понятно: на какой странице товара находимся, те характеристики и должны быть в селектбоксах. Засучили рукава и принялись работать. Но когда мы реально подошли к верстке страницы товара, верстальщик уперся в серьезные проблемы. Что будет происходить дальше, если клиенту захотелось поменять один из параметров товара? Какой товар будет куплен в таком случае - тот, на странице которого мы стоим, или тот, параметры которого представлены в селектах? Дальше началось обсуждение с клиентом и посыпались версии решения того, как же должны себя вести эти селекты и какой товар в итоге мы сможем купить на этой странице. И тут оказалось, что четкого видения того, как этот функционал должен работать, нет ни у кого. Дизайнер нарисовал красивый интерфейс, клиенту он понравился, но в процессе рализации оказалось, что он настолько двусмысленный, что вместо запланированных нескольких дней, на работу только с этой одной страницей ушло около месяца.

Выбор вариант в селектбоксах

Как теперь этим пользоваться?

Допустим, что при выборе другого доступного варианта характеристик в блоке с селектами, этот блок должен ajax-ом перезагружаться, выдавая только подходящие элементы в соседних полях (selectbox), совместимые с выбранным вариантом:

Но если учитывать то, что некоторые свойства у дочерних товаров дублируются (например, одинаковое значения диаметра шины, но разные ширина или профиль), и нам была поставлена задача унифицировать данные параметров товаров, то получалось так, что некоторые товары вообще не было возможности купить вообще, если изначально попали на другие типоразмеры той же модели. Например, изначально попали на товар с параметрами: 165/60 R14. В старом дизайне видим все возможные варианты сразу.

Выбор дочернего варианта в старом дизайне

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

Пробуем по-другому

Другой вариант - это уменьшать количество доступных для выбора вариантов, соответственно с уже определенными в полях-селектами. Тогда мы столкнулись с тем, что наступал момент, когда уже нельзя выбирать характеристики, поскольку в доступных списках уже вариантов не осталось, а кнопка “Сброс” не была предусмотрена.

Третий вариант

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

Что получилось?

Хорош ли получился результат? На наш взгляд - не очень. Мы потратили неоправданно большое количество времени, что привело к убыткам фирмы (ведь оплата у нас не почасовая, но несколько высококлассных спциалистов были вынуждены отвлечься на работу с прототипами и ломание головы о задумку дизайнера). Получившийся в результате интерфейс конечно стал рабочим и возможно даже выглядит несколько привлекательней старого, но существенно менее удобен: раньше покупателю достаточно было только взгляда на страничку товара чтобы увидеть в списке, имеется ли в наличии необходимый ему типоразмер шины, теперь же ему необходимо сделать 5 кликов, чтобы посмотреть, будет ли активной кнопка “Купить”; количество кликов до нажатия кнопки “Купить”, даже если товар есть в наличии, возросло с 2-х до 5-ти; появилась путаница с тем, что находясь на странице одного товара мы покупаем совсем другой товар (цена которого кстати тоже может быть и скорее всего будет иной).

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

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

Проектируем курятник

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

Автор OlehKorkh

Система Orphus
Заметили ошибку? Пожалуйста, выделите ее мышкой и нажмите Ctrl+Enter