Discovery та R&D договори на розробку софту

IT ринок – галузь, що динамічно розвивається, а тому сповнена інновацій та постійне перебуває у пошуку рішень та створенні нових продуктів. Discovery та R&D договори можуть стати ефективним інструментом оформлення співпраці у сфері дослідження та формулювання характеристик майбутнього проекту з безпосередньої розробки програмного забезпечення або бути його першим невід’ємним етапом.

Однак, оформлення надання IT послуг для визначення цілей, обмежень та загального обсягу проекту може відрізнятися від звичних договорів на розробку програмного забезпечення. Різниця полягає у встановленні специфікацій, часових рамок, майлстоунів та спільного бачення кінцевого результату. Усе це потребує проведення детального аналізу та професійного підходу до формулювання положень контракту.

Тому пропонуємо розглянути деякі ключові моменти, що необхідно враховувати при складенні умов Discovery та R&D договорів.

Формати оформлення Discovery та R&D послуг: один з етапів розробки або окрема послуга

З однієї сторони, Discovery та R&D можуть сприйматися як перша необхідна фаза розробки програмного забезпечення, адже саме вони дозволяють як клієнту, так і виконавцю окреслити проект, визначити усі ключові особливості, майбутні обсяги та строки роботи. Водночас, можливо замовник ще до кінця не визначився, а бажає лише  отримати дані про можливості реалізації певної ідеї та тільки згодом, залежно від результатів дослідження, замовляти розробку.

Тому, договірні відносини щодо Discovery та R&D послуг на розробку софту можуть бути оформлені як у вигляді додатку до основного договору на надання IT послуг/розробки ПЗ, так і окремим договором на проведення дослідження. В обох випадках важливо чітко зафіксувати предмет саме як надання послуг за Discovery чи R&D моделлю, наприклад:

Company shall provide the project discovery services to Customer (the “Services”) and Customer shall accept the Deliverables and pay to Company for the Services provided on terms and conditions stipulated herein.

Або, у випадку з окремим додатком, як доповнення до загального предмету в MSA:

The Services shall be provided by the Contractor pursuant to the «Project Discovery Phase» model as it is set forth in the current Annex.

Рекомендуємо також зазначати назву або загальну характеристику проекту для його індивідуалізації:

For the purposes of this Agreement, the project shall mean Customer’s future project, which consists in creating a dating mobile application (the “Project”).

На що звертати увагу при визначенні специфікації?

Як правило, сторони бажають укладати контракти тільки тоді, коли вже знають, що будуть разом працювати над проектом, а не на підготовчому етапі проекту. Тим не менш, саме надання послуг з планування подальшої роботи, визначення необхідних фінансових та людських ресурсів для втілення ідеї в життя, є основою успіху всього проекту. Тому спільне розуміння сутності (специфікації) послуг є корисним як для замовника (він розуміє, що отримає), так і виконавця (він розуміє, що він пропонує як послугу) . Якщо у договорах на розробку предметом є власне розробка програмного забезпечення, а результатом, що передається – код та інші елементи софту, то діскавері фаза може містити перелік різноманітних та неочевидних специфікацій. Головне – коректно відобразити реально запланований скоуп, наприклад:

The specification of the Services under this Agreement shall be as follows:

(i) gathering and analyzing information about the project, its goals, needs, product vision, target audience and market;

(ii) defining the project’s specification, success criteria, budget, UI/UX prototypes, technical diagrams, project schedules, architecture…;

(iii) analyzing the project’s scope, limitations and available resources;

…

Що в результаті?

Важливим також залишається передбачення результатів, які б відповідали специфікації. У такому разі сторони зможуть орієнтуватися на них у процесі співпраці та уникнути конфліктних ситуацій. Результати Discovery та R&D послуг можуть бути орієнтиром у майбутній роботі над розробкою програмного забезпечення, як для замовника, так і виконавця, тому їх вордингом не слід нехтувати. 

По завершенню Discovery чи R&D послуг, виконавець має передати матеріали, якими, по суті, є висновки, зроблені у ході надання відповідних послуг згідно із специфікацією. Це можуть бути як листи через електронну пошту, текстові файли, документи за заздалегідь встановленою формою, так і усні консультації телефоном чи через відео-конференції. Рекомендуємо передбачити результат для кожного пункту специфікації. Це можна зробити, як у скоупі, так і окремим списком:

The deliverables that are created and transferred during Services provision under this Agreement (the “Deliverables”) may include, but are not limited to, documentation on asset assessments, planned specialists requirements, timelines and milestones suggestions…

 Можливо також, що передання результатів по окремим етапам/категоріям не передбачається, а замість цього встановлено створення єдиного документу, яким завершується діскавері фаза, у вигляді технічної пропозиції (плану).

(a) As a result of the provision of the Services, the Contractor undertakes to make a technical proposal (project plan) that enables to create a time and budget estimate of the Product (the “Plan”). Such Plan shall include the following sections: ….

(b) The Parties agreed that the Contractor shall present the Plan not later than …, unless the Parties determine otherwise in writing.

Порядок надання послуг та приймання-передання результатів: оптимальні варіанти

Оскільки Discovery та R&D послуги мають зазвичай свої чіткі рамки, в залежності від специфікації, сторони мають можливість встановити строк, протягом якого повинні бути надані послуги або передбачити терміни виконання робіт за окремим етапами.

Якщо проект за погодинною оплатою, то в інтересах замовника мати можливість відслідковувати кількість витрачених годин у процесі, щоб уникнути витрат за неспівмірно витрачений час та за необхідності корегувати хід проекту. Цього можна досягти встановленням порядку щотижневого чи місячного звітування виконавця по кількості витрачених годин та створених результатів.

At the end of each week, the Contractor shall provide the Customer with information on the scope of work performed by the Contractor within that week. Such information shall be in the form of …

Актуальним для виконавця у Discovery та R&D послугах, як і в інших договорах на надання IT послуг, є обмеження клієнта у можливості надавати заперечення щодо результатів/звітів та вимагати внесення змін до результатів. Це особливо важливо, враховуючи, що діскавері фаза передбачає більшою мірою творчі роботи та надання суб’єктивних оцінок виконавцем, що може не відповідати уявленням замовника. Звісно, що зовсім виключати можливість модифікацій та доопрацювань недоцільно, тому раціональним видається встановлення тестового періоду, протягом якого це є можливим, наприклад, так:

The Customer shall review the Contractor’s report and/or the uploaded Deliverables for the relevant Reporting period within five (5) days from the date of their receipt. Unless the Customer makes any objections within such period, the Services and Deliverables for the applicable week, including their scope, number of hours spent and cost, are deemed duly provided and accepted.

Для діскавері фази критичною є наявність у виконавця обсягу інформації про майбутній проект, яка має бути вчасно та у повному обсязі надаватися замовником. Невиконання цієї умови може позбавити виконавця можливості дотримуватись умов надання послуг, особливо часових, та виконувати інші свої обов’язки.

Тому, одним з ключових пунктів, які необхідно включити, є прямий обов’язок замовника надавати дані, необхідні для надання послуг. Не зайвим у зв’язку з цим буде також виключити відповідальність виконавця за порушення узгоджених строків, через дії замовника.

Customer shall provide Company with all the necessary data about the Customer’s future project, in particular, those requested by Company, for the provision of the Services.

Слід також враховувати важливість правильного встановлення інших умов договору, в залежності від обраної моделі. Фінансові умови, інтелектуальна власність, конфіденційність – всі ці аспекти мають бути прописані з урахуванням специфіки реально запланованої співпраці та з увагою до забезпечення балансу інтересів сторін.

Висновок

Як бачимо, складення договірної документації для оформлення співпраці у сфері IT досліджень та за моделлю діскавері є непростим процесом, який потребує вивчення ситуації та врахування багатьох факторів. У Legal IT Group ми завжди раді допомогти та проконсультувати наших клієнтів щодо юридичних аспектів складення Discovery та R&D договорів на розробку софту.

Якщо Ви розумієте, що потрібен кастомізований Discovery чи R&D договір, ми радо підготуємо його під Ваші потреби та запропонуємо рекомендації для захисту Ваших інтересів.