Достаточно интересная ситуация часто возникает в фрилансовых лесах.

Да это конечно здорово когда дешево. Но вот обратная сторона такой медали — часто результатов не дождешься.

Причин там много, как и рисков. Расскажу про историю «Лебедь, рак и щука».

Есть Заказчик и ему нужен результат. Он платит за него деньги.

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

И значит заказывает он сайт у дизайнера. А так уж сложилось что на Руси под словом «дизайн» понимается рисование картинок.

Рисуются такие вот картинки. А дальше что? А дальше нужен программист, который якобы по картинкам напишет код. Ну пишет.

И все хорошо, до тех пор, пока не придет пора наполнения и тестирования продукта. И вот тут оказывается что модель данных не предусматривает некоторые нюансы, которые находятся за картинками. С точки зрения требований и картинок дизайнера — все хорошо. А результатов нет.

Дизайнеры крутят головой и говорят что то типа «к картинкам вопросы есть?». К картинкам вопросов нет.

Программисты не могут реализовать код, потому что модель данных составлялась по картинкам. А она не подходит для реализации требуемого функционала.

Это примерно как пытаться разрабатывать двигатель по цвету и форме заднего бампера.

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

А требования были к двигателю? Нет. Зачем? Картинки же заднего бампера есть…

А был тот кто отвечал за машину в целом? Нет. Был тот кто рисует бамперы и тот кто собирал двигатель. А то что машина должна была ездить на дизеле — никто и не подумал.

Вернемся к модели данных.

По уму это все должно было входить в дизайн. На этапе дизайна должна была быть составлена модель данных, а затем отрисовка элементов и их взаимоотношений. Ну ладно, это в сказках теории. В России, дизайнеры тока рисунки рисуют.

Хорошо, если дизайн дают разработчику, надо бы составить ТЗ, структурировать хотя бы тут модель данных и на этом этапе в случае проблем, не поздно поправить картинки нарисованные дизайнером. Но не тут то было. Зачем ТЗ? Картинки же есть… давайте разрабатывать логику по картинкам. Это как рисовать голую бабу на слух. Смешно? А вот именно так и делается 🙂

Нет, я конечно же за то чтобы в проекте было максимум графики и отрисофки форм. Это важно. Но попытка заменить графикой логику — это мовитон. Но вполне себе популярная забава на Руси.

Потому ТЗ — важнейший элемент когда встает вопрос дизайна (не путать с рисованием, давайте еще раз — НЕ ПУТАТЬ С РИСОВАНИЕМ!!!). В результате ТЗ должен появляться дизайн страниц, дизайн модели данных и дизайн логики (контроллеров). Взаимоувязанные. Те самые 3 элемента паттерна MVC.

А кто это должен делать? Кто пишет ТЗ? Вот! Вот это как раз тот человек, который редко появляется на фрилансе. Это руководитель проекта. Не путать с менеджерами проектов (продавцы и подлизы), которых гнобят дизайнеры и программисты. Руководитель проекта это тот с кем дизайнеры и программисты считаются. Такой если скажет — кровь в жилах стынет. И это именно тот с кого заказчик может спросить. Тот кто может ответить. Такого человека еще называют — «ответственный за проект». Тот кто может ответить (повтор) Заказчику за результат. И тот с кого можно спросить. С программиста или дизайнера не спросишь. Они ответить не смогут. Одни будут переводить стрелки на других, а другие на первых.

Бывают программисты уровня РП, бывают и дизайнеры уровня РП. Но это редкость. Первый признак что перед вами РП — он может отвечать за результат по проекту, а не переводить стрелки. Если вы нашли такого человека — значит повезло. Поздравляю.