Робоча демонстрація програми і придатний до експлуатації продукт можуть бути різними результатами. Замовник очікує код, документацію та можливість підтримувати систему; розробник може вважати завершенням успішну презентацію функцій. Договір потрібен, щоб такі очікування збігалися до початку оплачуваної роботи.
Розкласти проєкт на перевірювані результати
Для фіксованого обсягу погоджують функції, сумісність, вимоги до безпеки й критерії приймання. Якщо завдання змінюється під час розробки, потрібні порядок затвердження коротких етапів, облік часу та контроль бюджету. Саме слово Agile не визначає, за що платять і коли замовник може відмовитися від наступного етапу.
У специфікації варто описати залежності: доступ до тестового середовища, дані для інтеграції, участь представника замовника. Якщо потрібний API не надано, сторони мають розуміти, яку роботу можна продовжувати та як змінюється календар. Додаткові функції погоджують із оцінкою вартості, а не лише повідомленням у загальному чаті.
Кому належить код і з чого він складається
Комп’ютерна програма може містити власний код виконавця, нові модулі та компоненти третіх осіб. Передати більше прав, ніж має розробник, неможливо. Тому важливі перелік таких складників, їхні ліцензії та обмеження комерційного використання. Для відкритого коду перевіряють умови конкретної ліцензії, а не покладаються на слово «безкоштовний».
Погоджують обсяг майнових прав на створене, момент їх переходу та дозвіл використовувати попередні напрацювання. Особисті немайнові права авторів регулюються окремо. Якщо працює команда, виконавець має забезпечити належне оформлення прав від залучених розробників. Доступ до репозиторію сам по собі не вирішує питання правового титулу.
Приймання без суперечки про «майже готово»
Практичний протокол тестування пов’язує кожну вимогу з перевіркою та результатом. Дефекти варто класифікувати за впливом: блокування ключової операції, некоректне відображення, косметичний недолік. Критерії не повинні дозволяти безстроково відкладати оплату через будь-яке зауваження або примушувати приймати непридатний продукт.
- Зафіксуйте версію, середовище та тестові дані.
- Установіть канал подання помилок і процедуру повторної перевірки.
- Відокремте виправлення дефекту від нового функціоналу.
- Погодьте, що передається разом із релізом: код, інструкції, конфігурація, документація.
Підтримка та завершення відносин
Розробка не означає необмежену подальшу підтримку. Для супроводу описують години доступності, рівні критичності звернень, резервне копіювання та межі відповідальності за інфраструктуру. Час реакції слід відрізняти від часу повного усунення проблеми.
При виході з проєкту потрібні передача адміністрування, актуальних інструкцій та даних, відкликання зайвих доступів і завершення розрахунків. Обробка персональних даних та вимоги іноземного замовника можуть потребувати окремих умов. Перед підписанням зіставляють комерційну пропозицію, технічне завдання, склад ліцензій і план передачі продукту: саме на перетині цих документів зазвичай виникають прогалини.
Перевірка передачі продукту
Перед фінальним платежем корисно провести контрольне розгортання за переданою інструкцією. Якщо систему може запустити лише конкретний розробник зі свого облікового запису, замовник ще залежить від його участі. З’ясуйте, кому належать доменні, хмарні та сервісні облікові записи і хто оплачує їх після завершення. Доступи передають захищеним способом, із визначенням відповідальних осіб; секретні ключі не варто включати до відкритого акта. У документі достатньо зафіксувати факт передачі та перелік контрольованих ресурсів. Це окремий організаційний крок поряд із прийманням функцій і належністю авторських прав.