На демонстрації все може виглядати готовим: сторінки відкриваються, кнопки працюють, замовлення з'являється в кабінеті. Але цього недостатньо для приймання. Після передачі проєкт має працювати в узгоджених умовах, належати замовнику в обумовленому обсязі й не залежати від єдиної людини, яка знає, як його запустити.
Приймання потрібне не для пошуку приводу не платити розробникам. Це перевірка загального результату: що зроблено, які обмеження залишаються і хто відповідає за систему після запуску. Що раніше команда й замовник узгодять ці умови, то менше спірних ситуацій буде наприкінці.
Нижче розберемо, що можна перевірити самостійно, які підтвердження запросити й де знадобиться технічний фахівець.
1. Перевіряти сценарії, а не окремі екрани
Основою приймання мають бути вимоги та сценарії користувачів, узгоджені до розробки. Якщо очікування залишилися лише в листуванні, спочатку зберіть їх у спільний список і окремо позначте зміни, які команда взяла в роботу.
Перевіряйте шлях повністю. Для інтернет-магазину це не лише картка товару, а й вибір варіанта, розрахунок вартості, оформлення замовлення, оплата, підтвердження та відображення замовлення в менеджера. Для сервісу запису важливо, щоб зайнятий слот зникав із доступних, а скасування коректно змінювало розклад.
У кожного сценарію варто перевірити не лише успішний результат:
- Що відбувається за неправильних даних або недостатніх прав?
- Чи можна випадково створити два замовлення повторним натисканням кнопки?
- Що побачить користувач у разі обриву з'єднання або недоступності зовнішнього сервісу?
- Чи зберігається результат після оновлення сторінки та повторного входу?
- Як виконуються скасування, повернення коштів і виправлення помилки?
Проводьте перевірки на узгоджених пристроях і браузерах, із різними ролями користувачів. Платежі спочатку тестуйте в тестовому режимі провайдера. Перевірку реальної операції узгодьте окремо, включно із сумою, поверненням коштів і відповідальним, щоб приймання не створювало випадкових витрат.
Знайдені проблеми фіксуйте з кроками відтворення, очікуваним результатом і скриншотом або відео. Формулювання «оплата працює дивно» менш корисне, ніж конкретний сценарій, який команда може повторити.
2. Отримати код, доступи та контроль над акаунтами
Архів вихідного коду в месенджері не замінює повноцінну передачу проєкту. Замовнику потрібні доступ до репозиторію, версія релізу та розуміння, який код працює на сервері. Історія змін допомагає іншій команді розібратися в рішеннях і продовжити розробку.
Попросіть скласти реєстр ресурсів:
- Репозиторії та організація, у якій вони розміщені.
- Домен, DNS та акаунт реєстратора.
- Сервери, хмарні сервіси, бази даних і сховища файлів.
- Платіжний провайдер, поштові сервіси та зовнішні API.
- Аналітика, моніторинг, магазини застосунків і пов'язані акаунти.
Для кожного ресурсу потрібні власник, адміністратори, спосіб відновлення доступу та джерело оплати. Критичні акаунти краще оформлювати на замовника там, де це дозволяють умови сервісу. Доступ підрядника можна зберегти як робочий, але він не має бути єдиним способом керування продуктом.
Паролі та секретні ключі передавайте через узгоджений захищений канал, а не в спільній таблиці або відкритому репозиторії. Після передачі перегляньте права, увімкніть багатофакторну автентифікацію, де вона доступна, і замініть чутливі ключі за узгодженим планом. Різка заміна всіх ключів без перевірки залежностей може зупинити сервіс.
3. Переконатися, що проєкт можна запустити й відновити
Документація вважається корисною, якщо за нею можна виконати роботу, а не просто прочитати опис архітектури. До комплекту передачі мають входити інструкції запуску, збірки та оновлення, список необхідних сервісів і опис налаштувань середовища без розкриття секретів.
Окремо потрібні порядок зміни бази даних, резервного копіювання та відкату релізу. Важливо знати не лише де зберігається копія, а й що вона містить: базу, завантажені файли, налаштування або лише частину системи.
Хороша перевірка передачі: інженер, який не брав участі в розробці, розгортає проєкт в окремому середовищі за документацією. Якщо йому доводиться постійно запитувати автора коду, які команди виконати, інструкції ще потребують доопрацювання.
Відновлення резервної копії теж перевіряють окремо, не поверх чинної бази. Після нього потрібно переконатися, що дані читаються й основні сценарії працюють. Наявність файлу з назвою backup не підтверджує можливість відновлення.
Узгодьте допустиму втрату даних і час відновлення. Для невеликого інформаційного сайту та сервісу, який приймає замовлення цілодобово, вимоги будуть різними. Універсальної норми тут немає, але відсутність домовленості залишає бізнес без зрозумілого плану в разі збою.
4. Перевірити безпеку та роботу з даними
Замовнику не обов'язково читати весь код, щоб поставити правильні запитання. Попросіть команду показати, як розділені ролі, де зберігаються секрети, які дані потрапляють до логів і що відбувається під час спроби відкрити чуже замовлення або документ.
Прихована кнопка в інтерфейсі не є захистом. Обмеження мають перевірятися на сервері: звичайний користувач не має отримувати адміністративні дані лише тому, що знає адресу запиту.
До базової перевірки зазвичай входять:
- Контроль доступу до чужих даних і дій адміністратора.
- Відсутність секретів у публічному коді та клієнтській збірці.
- Коректне опрацювання повторних платіжних сповіщень.
- Обмеження зайвих даних у логах, вивантаженнях і відповідях API.
- Перевірка залежностей і усунення або документування значних ризиків.
Обсяг перевірки залежить від наслідків помилки. Для продукту з грошима користувачів, чутливими даними або смарт-контрактами може знадобитися незалежний аудит. Його межі потрібно узгодити: що перевірено, якою версією коду обмежений звіт і які зауваження закриті.
Успішний тест або звіт не гарантує відсутність усіх вразливостей. Він дає підтвердження конкретних перевірок. Приймання має фіксувати залишкові ризики та відповідальних, а не зводитися до обіцянки «у нас усе безпечно».
5. Розібратися з правами та підтримкою після запуску
Доступ до вихідного коду й право використовувати або змінювати його не одне й те саме. У договорі та документах передачі потрібно перевірити обсяг переданих прав, умови роботи з дизайном і контентом, а також ліцензії сторонніх компонентів. Для спірних питань залучіть юриста з урахуванням застосовного права.
Не всі бібліотеки стають власністю замовника разом із проєктом. Деякі елементи використовуються за ліцензією, інші потребують підписки. Потрібен список таких залежностей, обмежень і регулярних витрат, зокрема шрифтів, зображень і зовнішніх сервісів.
До фінальної передачі узгодьте, що відбувається після релізу:
- Хто стежить за помилками та доступністю системи?
- Які дефекти входять до гарантійних виправлень і на який строк?
- Чим виправлення помилки відрізняється від нової функції або зміни вимог?
- Як приймаються звернення та які строки реакції узгоджені?
- Хто відповідає за оновлення, резервні копії та продовження сервісів?
Приймання не має вимагати нескінченних безкоштовних доопрацювань. Але й передача проєкту без зрозумілої межі відповідальності створює ризик: під час першого збою кожна сторона може вважати, що ним має займатися інша.
6. Окремо перевірити результат AI-розробки
Використання нейромереж саме по собі не є недоліком. AI може допомогти швидше написати типовий код, тести та документацію. Але замовник приймає робочу систему, а не кількість згенерованих рядків.
Попросіть підтвердження того, що зміни проходять рев'ю, основні сценарії охоплені перевірками, а використовувані залежності відомі команді. Особливо важливі права доступу, платежі та обробка помилок: зовні переконливий код у цих місцях може містити серйозні дефекти.
Згенерована документація має відповідати реальному проєкту. Перевірка запуску в окремому середовищі швидко показує, чи існують зазначені команди, змінні та сервіси насправді.
Також варто узгодити правила використання AI-інструментів: які дані можна передавати провайдеру, чи допускається завантаження закритого коду та як захищаються секрети. Умови залежать від інструмента, налаштувань і договору. Відповідальність за обраний процес і результат залишається в команди.
Таблиця приймання: що запросити в команди
| Що перевірити | Яке підтвердження отримати | Що блокує запуск |
|---|---|---|
| Основні сценарії | Результати перевірок за узгодженим списком | Критичний шлях неможливо завершити |
| Код і доступи | Репозиторій, версія релізу та реєстр акаунтів | Замовник не контролює критичні ресурси |
| Розгортання | Перевірений запуск за інструкцією | Проєкт неможливо відтворити без автора |
| Резервні копії | Перевірка відновлення в окремому середовищі | Немає підтвердженого відновлення критичних даних |
| Безпека | Результати перевірок і список залишкових ризиків | Відома критична вразливість або доступ до чужих даних |
| Права | Узгоджені документи та список ліцензій | Немає необхідних прав для запланованого використання |
| Підтримка | Зафіксовані зони відповідальності | Для запуску немає узгодженого плану реагування на збої |
Не кожне зауваження має зупиняти реліз. Невелику візуальну неточність можна перенести до узгодженого списку виправлень, якщо вона не заважає використанню. Втрату даних, неправильне списання грошей або порушення прав доступу відкладати не можна. Пріоритети та допустимі обмеження сторони фіксують разом.
Належно переданий проєкт можна зрозуміти, запустити, відновити й розвивати іншою командою. Саме це, разом із робочими сценаріями користувачів і зрозумілими правами, варто вважати результатом приймання. Красиве демо показує інтерфейс. Повноцінна передача показує, що бізнес справді отримав власний продукт.