Метод Прогрессивного Джипега во фрилансе

в 10:17, , рубрики: Веб-разработка, фриланс, метки:

Некогда в «Ководстве» Артемия Лебедева появился один любопытный параграф. Назывался он "Метод Прогрессивного Джипега". Суть его в том, что на любой стадии проект готов. Всё остальное — степень «прожарки». Под катом — как оно работает в реальной жизни.

По моим наблюдениям существует два класса фрилансеров: те, кто работает по официальным бумагам, и те, кто работает безо всяких договоров. Первый класс сразу отметём, ибо там другие критерии и принципы. Второй же класс делится на два подкласса: те, кто работает на площадке заказчика, и те, кто работает на своей площадке, сдавая в конце работ заказчику дамп и архив с файлами. Давайте пока затронем только сайтостроительство. Опять таки же первый подкласс отметаем. Ниже объясню почему. Нас интересует второй подкласс — неофициальная работа на своей площадке. Под площадкой в данном случае понимается свой адекватный хостинг, где можно создавать поддомены, и есть хороший запас по дисковому пространству.

Отдельно следует остановиться на том, что один в поле — не воин. Команда по созданию сайтов должна состоять, как минимум из программиста, верстальщика и дизайнера. Если Вы делаете сайты на хорошем движке, программистом и верстальщиком может быть одно лицо. Так или иначе за дизайн отвечает один человек, за техническую часть — другой. Притом заказчику полезно держать связь со всеми основными членами Вашей команды. Это рациональнее всего, ибо дизайнер лучше поймёт, что надобно заказчику в плане дизайна. И Ваше посредничество, если Вы программист, ничего не даст, кроме потери времени и нервов.

Возьмём среднестатистическую «вкусную» задачу — интернет-магазин. Будем его делать на движке MODx. Я надеюсь Вы уже поняли для себя, что велосипеды изобретать — это зло в подобных задачах, и используете готовые движки вместо движков-под-конкретный-заказ. Если нет, сочувствую. Лирическое отступление — почему именно MODx. Здесь всё просто — дело привычки, да и вообще просто удобный пример. Большая часть заказчиков не выдвигает конкретных требований по CMS. Так зачем Вам тратить время на изучение другого движка, когда Вы уже знаете один в совершенстве? Если же выдвигает, то просто сопоставьте стоимость и требования по срокам со временем и количеством терпения на изучение нового движка. Лучше потерять заказ, который Вы не в состоянии адекватно выполнить, чем впоследствии обрести массу проблем. Как говорится, подпись — Ваш Капитан Очевидность.

Итак задача поставлена, запасы пива кофе восполнены — в путь! Вот Вы уже отправили заказчика к дизайнеру, чтобы те обсудили дизайн. А теперь вопрос: что Вы должны сделать в любом случае? Прежде всего Вы должны создать рабочий поддомен и залить движок на хостинг. Для чего? Во-первых, «на живую» работать безопаснее. Что бы не случилось с Вашей машинкой, проект останется в целости. Во-вторых, так заказчик сможет наблюдать за ходом работ над проектом и видеть, что Вы работаете, а не лясы точите. А это, знаете ли, прибавляет градуса уверенности заказчика в Вас. Ну и в-третьих, заказчик сразу может работать над контентом. Но о третьем моменте ниже.

Здесь я как раз поясню почему Метод Прогрессивного Джипега (далее МПД) не эффективен в случае работы на площадке заказчика. Всё очень просто. Если Вы залили на сервер заказчика движок и настроили его, заказчику ничего не мешает изучить движок и послать Вас подальше. Пока Вы возитесь с дизайном, заказчик быстренько научится пользоваться движком и наймёт втихую какого-нибудь Васю-Кузькина-за-пять-килорублей вместо Вас-за-тысячу-убитых-енотов. Или сразу же наймёт, даже не изучая движок. Большинство заказчиков в состоянии после заливки Вами движка на их сервер принять для себя решение, что Вы пол-работы уже сделали. Притом эти «пол-работы» уже никуда не денутся, достаточно закрыть Вам доступ на хостинг. А потом, поди докажи, что ты не Лёлик, как говорилось в одной сказке Гайдука. Будете мне вещать про договоры? Напомню: речь о работе без бумажек. И большинство заказчиков таковы, что не способны удержаться от соблазна «кинуть» исполнителя. Это не пессимизм, это жизнь. Nothing personal, just business, amigo.

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

И вот наступает момент, когда основные требования по дизайну утверждены. Соответственно заказчик теперь ждёт макет и… его можно занять каталогом. Я надеюсь, Вы уже создали разделы каталога. Теперь заказчику предстоит пояснить Вам для начала, где какие характеристики продукции должны показываться. Проще говоря, если брать, скажем, отопительное оборудование, понятно, что в одном разделе каталога будут газовые котлы, у которых один набор характеристик, в другом — электрические котлы с другим набором, в третьем — трубы, у которых из наборов по сути только размеры и материал. Всё это обсуждается с заказчиком. Для каждого раздела составляется свой набор параметров. Я, например, называю такой набор тайпсетом (typeset). Создать шаблон без вёрстки и прикрутить к нему набор параметров — дело недолгое. А самое главное, что заказчик теперь может наполнять каталог товарами. Это огромный плюс! Мало того, что Вам есть с чем наглядно работать, но и уже ведётся проработка контента. Работа над сайтом идёт по всем направлениям сразу. Кстати, по части многопоточности движок MODx наиболее удобен в работе.

Таким образом, пока дизайнер делает макет, Вы работаете над функционалом, а заказчик уже работает с контентом. В результате сайт делается в среднем в два-три раза быстрее, чем при последовательном подходе. Когда готов макет, его остаётся только раскидать по шаблонам и отшлифовать под фукнционал. А заказчик в итоге получает не просто готовый к работе сайт а полностью готовый сайт. По сути сайт готов в любой момент работы над ним. Прорабатываются лишь нюансы. А за счёт многопоточности работы сайт создаётся в весьма короткие сроки.

На сим всё. Спасибо за внимание.

P.S. Статья отражает субъективную точку зрения и не претендует на объективность.

Автор: XanderBass

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js