Порядок работы над веб проектом. Общие рекомендации.
Договоренности. Что из себя должна представлять задача
Задача по верстке должна содержать из себя основные требования:
1.1 Соответствие с макетом.
Перед тем, как оценить проект, необходимо внимательно осмотреть все элементы макета, предупредить о косяках дизайна, что может иметь иной вид в реальности. Это текст, отступы однотипных элементов.
1.2 Кроссбраузерность.
Обычно это Firefox, Chrome, Safari последних версий. Отдельно уточняется версия Internet Explorer. Возможно, другие браузеры, такие как Opera. Но список тестируемых браузеров указывается, чтобы потом не мучиться с какой-нибудь экзотикой.
1.3 Прохождение верстки на валидаторе.
С html валидатором все просто.
Обратите внимание, что при проверке CSS на валидаторе может выдать ошибки с указанием на названия свойств. Это значит, что какие-либо свойства CSS3 могли быть не добавлены в валидатор и они вызывают ошибкой. Это является допустимым и крайне редко проверяют CSS на предмет ошибок.
1.4 Мобильная версия.
В идеале должен быть дизайн под портрет планшета и мобильника. Но это бывает редко. Обычно, только портрет мобильного устройства. Если вообще нет дизайна под мобильные устройства, то лучше согласовать с клиентом порядок отображения контента в мобильной версии и как должен выглядеть «гамбургер» меню. Если ему все равно – стилизуем под общий стиль. Если нет – пусть поищет пример сайта, который нравиться и оттуда возмете стиль.
Можно и самому подготовить дизайн и согласовать, если есть навыки. Ваша задача – код, фантазия дело дизайнера или клиента. Всегда сначала согласовываем, а только потом делаем. Избегайте экспериментов с кодом.
То есть, «ты покажи, а я решу» — можно, если за деньги. Бесплатно – пусть напрягает дизайнера, на макете это быстрее сделать, чем в коде поменять.
1.5 Прочие технические моменты.
Использовать css-фреймворк или кастомный код. Использование препроцессоров. Бибилиотеки jQuery и т.п. Если задачи не сформировано – сформируйте сами, отправьте на утверждение клиенту.
Кроме этого, всегда лучше уточнить, максимальный размер страницы под десктоп. Дело в том, что есть Responsive верстка которая называется Full Responsive, это значит, что она умещается в экран не только при уменьшении экрана, но и при увеличении. То есть, масштабируются элементы – увеличивается шрифт, иконки и тому подобное.
В целом по порядку согласования.
Не надо ставить себя в пассивную позицию и необходимо отсекать сразу подобные фразы «если мне понравиться твой код» или «вам понравиться мой код» — код не должен нравиться или не нравиться, как и любая выполненная работа. Она может соответствовать требованиям и может не соответствовать требованиям. Для этого нужны параметры задачи. Нет параметров – невозможно работу согласовать, и она становиться бесконечной.
Если параметров нет – «сделай хорошо» или «давай начнем, а там разберемся» — не стоит связываться с такими людьми. Потеряете время и ничего не получите. Или вымучают до невозможного состояния. Если нет времени на обсуждение задачи или постоянные затруднения с коммуникацией – не стоит связываться. Это говорит о несерьезном отношении к работе. Как следствие – за работу могут вообще не рассчитаться, просто не приняв ее и пропасть. При этом объяснив себе, что раз я не запустил это в работу и не использую, то я ничего и не должен разработчику. Справедливо не только для верстки.
Кроме этого, есть «золотое правило» — ничего не делать бесплатно. Любая мелочь, сделанная бесплатно может повлечь за собой еще одну мелочь и эти мелочи выльются в часы и дни. Поэтому сразу стоит это обговорить как объемные правки/пожелания вне первоначальной задачи (общая сумма до 1 часа, например), так и мелкие. Самые крупные выносить в отдельные договоренности и это нормально. Например, % от проекта или общая сумма правок, которая может быть сделана в рамках начальных договоренностей.
Документирование задачи и всех договоренностей (слова к делу не подошьёшь)
2.1 Каждое слово и договоренность должна быть зафиксировано. Лучше всего использовать почту для коммуникации.
Всю работу перебрасывать ссылками через почту, предварительно загрузив на Google Drive / Dropbox. Файлы в месенджеры перебрасывать – путь в никуда. Ничего не найдете потом, когда что отправляли. Люди разные – потом сделают виноватым, что не отправил ничего.
2.2 Избегать устных договоренностей или требовать после разговора основные моменты прописывать в чате или почте.
Порядок оплаты: сумма и порядок оплаты
3.1 Должна быть четкая договоренность о сумме и валюте до начала работы
Сумма указывается в иностранной валюте с пересчетом в национальную на день расчета или в национальной
3.2 Порядок оплаты – предоплата
Предоплата 50% это нормально. И никого не может обижать. Вы же не дружбу заводите, а делаете работу за деньги, поэтому и отношения должны быть прежде всего деловыми.
3.3 Оплата после приема работы
Необходимо обговорить дату после приема работы. То есть, в течении какого времени будет произведен расчет. Например, в течении рабочей недели или двух. Это для разовых проектов.
Дело в том, если компания отдает фрилансеру проект, то некоторые силно хитрые компании рассчитываются, как рассчитается с ними клиент. Что ставит сразу подрядчика в крайне несправедливое положение.
Подрядчик не партнер и не получает прибыль от проекта в виде %, а работает за определенную сумму. И ждать месяцами, а так часто и бывает, пока клиент примет проекта рассчитается с компанией не должен.
В отношениях компания-подрядчик, работу принимает компания. Поэтому всегда нужно ставить условие приема и расчета за работу непосредственным клиентом, а не каким-то конечным клиентом, о котором вы ничего не знаете и не узнаете.
Вас также может заинтересовать