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

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

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

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

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

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

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

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

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

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

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

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

Автор: XanderBass