Передача завершена не тоді, коли надійшов архів або повідомлення «всі доступи надані». Відповідальна людина з боку бізнесу має самостійно відкрити потрібні сервіси, знайти актуальну версію сайту та зрозуміти, хто продовжує оплату й відновлює роботу при збої. Перевіряти це краще до завершення співпраці, поки виконавець доступний для пояснень.
Нижче — навчальний приклад приймання, а не звіт про конкретний проєкт чи обіцянка однакового комплекту для всіх сайтів. Перелік залежить від платформи й погодженого обсягу. Для конструктора, статичного сайту та сайту з базою даних він буде різним.
1. Зберіть реєстр із доказом, а не лише назвою сервісу
Замість колонки «доступ передано: так» запишіть, що саме власник перевірив зі свого облікового запису. Паролі, секретні ключі й резервні коди у цьому документі не зберігайте. Для кожного рядка додайте дату, відповідального та невирішене питання.
| Що передаємо | Хто контролює | Як перевірити результат |
|---|---|---|
| Домен і продовження | Відповідальний у бізнесі | У кабінеті реєстратора видно потрібний домен, реєстраційні дані, строк і спосіб продовження. |
| DNS та пошта | Власник акаунта; технічний виконавець має окрему роль | Знайдено чинну DNS-зону, збережено її копію й визначено поштового провайдера. |
| Хостинг і публікація | Власник проєкту та погоджений адміністратор | Видно production-домен, останній успішний реліз, журнал публікації та оплату. |
| Вихідні файли або CMS | Уповноважений представник бізнесу | Є потрібний доступ до репозиторію чи редактора; зрозуміло, яка версія працює на сайті. |
| Дані та резервні копії | Названий відповідальний за відновлення | Зафіксовано склад копії, місце зберігання і результат перевірки відновлення. |
| Підключені сервіси | Окремий власник кожного акаунта | У реєстрі є точні ідентифікатори ресурсів, призначення, ролі та відповідальний за оплату. |
2. Відокремте технічний доступ від прав на результат
Можливість увійти в панель не пояснює, на кого зареєстрований домен і на яких умовах можна використовувати код, фотографії, шрифти або шаблон. Це різні пункти передачі. Зіставте реєстраційні дані з домовленостями, а для сторонніх матеріалів попросіть перелік джерел і ліцензійних обмежень.
Якщо сервіс або ліцензія залишаються в акаунті виконавця, не позначайте їх як передані бізнесу. Запишіть залежність: хто продовжує підписку, що відбудеться після завершення супроводу та який погоджений спосіб переходу. У конструктора можливості експорту можуть відрізнятися від передачі звичайного репозиторію. З’ясуйте це до приймання, а не після відключення тарифу.
3. Зв’яжіть переданий код із працюючим сайтом
Архів із назвою «final» не підтверджує, що всередині остання версія. Попросіть позначення релізу або commit, дату публікації й коротку інструкцію: як зібрати сайт, які налаштування потрібні та як повернути попередню версію. Для CMS окремо уточніть, де зберігаються тексти, зображення й база даних: вони можуть бути поза кодом.
Перевірку збирання або відновлення проводять у відокремленому тестовому середовищі. Там блокують реальні заявки, оплату й зовнішні сповіщення; доступ до копії з персональними даними обмежують. Доказом буде записаний результат перевірки, а не сама наявність ZIP-файлу. Публікувати тестову копію у відкритий доступ для цього не потрібно.
Передача GitHub-репозиторію також не означає автоматичного очищення старих доступів: за документацією GitHub, пов’язані секрети й ключі розгортання можуть залишатися, як і учасники. Їх переглядають окремо після перевірки залежностей.
4. Не поєднуйте передачу з непотрібним переїздом
Зміна відповідального не завжди вимагає нового хостингу, реєстратора чи nameserver. Якщо чинна схема працює, спершу прийміть контроль над нею. Перенесення інфраструктури оформлюйте окремою зміною з планом перевірки та відкату.
- Зафіксуйте поточні домен, DNS-провайдера, хостинг, пошту й дату продовження. Збережіть DNS-зону доступним у провайдера способом; Cloudflare, наприклад, описує експорт записів.
- Надайте представнику бізнесу потрібну роль. Нехай він прийме запрошення й увійде самостійно, без чужої відкритої сесії.
- Перевірте способи відновлення акаунта, багатофакторний захист і відповідального за платежі. Коди відновлення зберігайте захищено, не у загальному листуванні.
- Зіставте підключення: звідки збирається сайт, який сервіс приймає форму, куди надходить звернення, які ресурси аналітики використовуються. Перегляд звіту не замінює права керувати ресурсом.
- Лише після перевірок погодьте відкликання зайвих ролей і заміну ключів. Не вимикайте навмання акаунт, від якого ще залежить публікація або доставка повідомлень.
Для Search Console окремо перевірте статус власника й спосіб підтвердження: Google розрізняє підтверджених і делегованих власників. Не видаляйте DNS-записи або файли підтвердження лише тому, що вони здаються зайвими.
5. Закрийте передачу коротким підсумком
Для кожного пункту використовуйте один із трьох станів: «перевірено», «залишилося зробити» або «не входить у погоджений обсяг». Біля незавершеного пункту мають бути виконавець, наступна дія і строк, а не порожня позначка.
Наприкінці власник має знати: де керувати сайтом, де лежить актуальний код чи контент, коли оплачувати сервіси, хто відновлює роботу й до кого звертатися по погоджену підтримку. Це підсумок передачі, а не гарантія безперебійної роботи назавжди. Регулярні перевірки після неї — окремий план підтримки сайту.
Якщо сайт лише замовляється, включіть цей результат у погоджений склад робіт. Перевірку зовнішнього вигляду, форм і технічної готовності винесіть у окремий QA-чекліст, щоб не плутати працюючий інтерфейс із повною передачею проєкту.