Порядок роботи над веб проєктом. Загальні рекомендації.
Домовленості. Що з себе має являти завдання
Завдання з верстки має містити в собі основні вимоги:
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 Оплата після приймання роботи
Необхідно обговорити дату після приймання роботи. Тобто, протягом якого часу буде проведено розрахунок. Наприклад, протягом робочого тижня або двох. Це для разових проєктів.
Річ у тім, якщо компанія віддає фрілансеру проєкт, то деякі дуже хитрі компанії розраховуються, як розрахується з ними клієнт. Що ставить відразу підрядника у вкрай несправедливе становище.
Підрядник не партнер і не отримує прибуток від проєкту у вигляді %, а працює за певну суму. І чекати місяцями, а так часто і буває, поки клієнт прийме проєкт і розрахується з компанією не повинен.
У відносинах компанія-підрядник, роботу приймає компанія. Тому завжди потрібно ставити умову приймання і розрахунку за роботу безпосереднім клієнтом, а не якимось кінцевим клієнтом, про якого ви нічого не знаєте і не дізнаєтеся.
Вас може зацікавити