Чому важливе правильне приймання
Приймати проєкт без належного тестування — це як підписуватися за доставку, не відкриваючи коробку. Усе виглядає добре, поки ви не виявите, що предмет усередині розбитий.
На українському фріланс-ринку багато суперечок виникає не через нечесність розробників, а через те, що обидві сторони мали різне уявлення про те, що означає «готово». Належний процес приймання усуває більшість цих суперечок.
Перш ніж навіть починати проєкт
Визначте критерії приймання заздалегідь. Буквально запишіть у договорі: «Робота вважатиметься виконаною, коли X, Y і Z працюватимуть, як описано».
Розмито: «Виправити оформлення замовлення». Чітко: «Користувачі можуть завершити покупку з вибраною доставкою "Нова Пошта", оплачуючи через Liqpay, без помилок — перевірено на десктопному Chrome і мобільному Safari».
Чим конкретніші ваші критерії приймання, тим легше буде перевірка.
Контрольний список приймання
Основна функціональність
- Чи працює те головне, за що ви заплатили?
- Перевірте це самостійно, крок за кроком, як справжній користувач
- Протестуйте на десктопі та мобільному
- Протестуйте в Chrome І ще одному браузері (Firefox або Safari)
Крайові випадки
- Що станеться, якщо користувач помилиться? (неправильний формат email, порожні поля)
- Що станеться при повільному інтернеті?
- Що, якщо хтось спробує замовити 0 товарів або 9999 товарів?
Продуктивність
- Чи завантажується сторінка менше ніж за 3 секунди на мобільному? (Перевірте в PageSpeed Insights)
- Перевірте на своєму телефоні через мобільні дані, а не Wi-Fi
Доступ і облікові дані
- Чи отримали ви всі паролі та дані для доступу?
- Адмін-панель, хостинг, FTP, база даних — все у ваших руках?
- Чи видалив розробник власний доступ, якщо ви просили?
Документація
- Чи знаєте ви, як самостійно виконувати базові завдання? (додати товар, змінити ціну, додати сторінку)
- Чи знаєте ви, кому зателефонувати, якщо щось зламається?
Як надавати відгуки без початку війни
Уникайте: «Це не працює» або «Це все неправильно».
Використовуйте: «Коли я натискаю [кнопку] у мобільному Chrome, я бачу [конкретну помилку]. Очікувана поведінка: [що має статися]».
Конкретні звіти про помилки виправляють. Розмиті скарги створюють суперечки.
Створіть спільний Google Doc або сторінку Notion. Перелічіть проблеми з:
- Що ви зробили (кроки для відтворення)
- Що сталося
- Що ви очікували
Позначте кожен пункт номером. Коли його виправлять, позначте як виконаний. Це рятує нерви обох сторін.
Що входить у період виправлень
Завчасно домовтеся про гарантійний термін. Стандартна практика:
- 2–4 тижні безплатного виправлення помилок для речей, які мали працювати, але не працюють
- Не входить: нові функції, які ви придумали після здачі, зміни до того, що було узгоджено
Приклад: якщо ви платили за виправлення оформлення замовлення, а воно не працює — це помилка, виправлення безплатне. Якщо тепер ви хочете додати систему балів лояльності — це новий проєкт.
Ця різниця важлива. Багато суперечок між клієнтом і розробником виникають через те, що клієнт вважає щось «помилкою», а розробник — «виходом за межі». Визначте це до початку роботи.
Остаточне підтвердження
Коли все за вашим контрольним списком працює:
- Надішліть письмове підтвердження: «Я підтверджую, що проєкт завершено та прийнято».
- Виплатіть остаточний платіж.
- Отримайте всі облікові дані задокументованими.
- Попросіть розробника бути доступним для запитань протягом 2 тижнів.
Ось і все. Чиста передача, без суперечок, без неоднозначностей.
Скорочена версія
Якщо ви не хочете проходити через усе це, принаймні зробіть:
- Протестуйте головну функцію самостійно на телефоні
- Переконайтеся, що маєте пароль адміністратора та доступ до хостингу
- Запитайте: «Що робити, якщо щось зламається через місяць?»
Ви не можете повністю захистити себе без належного тестування, але ці три дії врятують вас від 80% типових проблем.