Уявіть, що ваша компанія щойно отримала прибутковий та довгостроковий проєкт. Ви будете розробляти мобільний додаток для європейського Medtech-стартапу для Android та iOS з нуля. Якщо робота буде ефективною, клієнт продовжить співпрацю і ваша команда буде працювати над оновленнями продукту та технічною підтримкою. Цей проєкт важливий для вашого бізнесу, оскільки у нього є потенціал для тривалої співпраці. Щоб забезпечити комфортну роботу та виправдати очікування, важливо заздалегідь укласти MSA договір, який допоможе встановити правила взаємодії та попередить виникнення можливих непорозумінь. MSA agreement заздалегідь робить правила більш чіткими для обох сторін та усуває плутанину.
У цій статті наші юристи розкажуть про переваги підписання MSA та опишуть важливі пункти, які необхідно включити до документа.
Що таке Master Service Agreement?
MSA — це контракт між компанією з розробки програмного забезпечення та клієнтом, у якому описані очікування від проєкту, правила взаємодії, обов’язки сторін, відповідальність, строки надання послуг та оплати роботи, перехід прав інтелектуальної власності та інші важливі питання. MSA підходить для довгострокових проєктів та допомагає зробити процес розробки передбачуваним, незважаючи на зміни у команді, об’ємі робіт та баченні проєкту. MSA — це основа для інших документів, таких як технічні завдання (ТЗ), запити на внесення змін та інші.
Як працює MSA?
MSA визначає умови, які регулюють відносини IT-компанії та клієнта, щоб забезпечити взаєморозуміння між ними. Якщо ви опинитеся в непередбачуваній ситуації, ви зможете знайти відповідь у MSA.
MSA — це керівництво для команди компанії з розробки програмного забезпечення та клієнта. Завдяки MSA менеджер проєкту (PM) буде знати як вирішувати проблеми. Наприклад, типовою проблемою, з якою зіштовхується PM, буде затримка зі сторони клієнта. Уявіть, що ви працюєте на умовах Time & Materials, а клієнт не надає матеріали, які потрібні для продовження роботи, це призводить до простою та втрати грошей. Щоб захистити інтереси IT-компанії, у MSA повинне бути правило про те, що простой оплачується, а дедлайни зсуваються на час очікування матеріалів. Це правило допомагає дисциплінувати клієнтів. Вони будуть вживати усіх можливих заходів, щоб виконати свої обов’язки вчасно, оскільки ніхто не хоче платити команді, яка не працює.
Поради щодо створення ефективного MSA
Зазвичай MSA складає IT-компанія та передає клієнту на узгодження. Завдання компанії — скласти угоду, яка враховує ризики та інтереси обох сторін. Нижче ви знайдете декілька порад від наших юристів для створення збалансованого документа, який задовольнить запити клієнтів та одночасно захистить інтереси вашої компанії.
Постановка, зміна та розірвання ТЗ
MSA визначає загальні правила управління проєктом, яких повинні дотримуватися обидві сторони, але конкретні деталі кожної нової задачі описуються в окремому ТЗ. Цей документ – невід’ємна частина MSA. Правила постановки, внесення змін та розірвання ТЗ повинні бути зафіксовані у MSA.
Ми рекомендуємо встановити, яка інформація повинна бути включена до кожного ТЗ: визначення послуг та об’єму робіт, члени команди, строки, процедури оплати та виставлення рахунків, способи передачі результатів роботи та правила їх прийому.
Наприклад, ваша компанія надає послуги з UI/UX для приптопроєкту. Один із етапів проєкту — робота над пакетом брендингу. В такому випадку до ТЗ повинно бути включено наступне:
- Послуги та об’єм робіт. До прикладу, розробка двох варіантів логотипу. Ваша команда дослідить конкурентів, щоб перевірити їх tone of voice, основні цінності, повідомлення і т. д. Наступний крок — розробка логотипів та презентація ідеї, основних компонентів та прикладів реалізації. Презентація складатиметься із шаблону Google Slides (9-10 слайдів).
- Команда. Наприклад, бренд-дизайнер та менеджер проєкту.
- Строки. Два місяці з моменту підписання ТЗ. При цьому, IT-компанія заздалегідь сповістить клієнта, якщо робота займатиме більше часу, ніж планувалося.
- Ставки та оплата. Пакет брендингу буде надано за фіксованою ціною розміром $6500. Будь-які додаткові функції або матеріали повинні бути оцінені, узгоджені та схвалені клієнтом до початку роботи. Додаткові матеріали будуть оплачуватися окремо.
- Рахунки та умови оплати. Компанія виставляє рахунок клієнту заздалегідь, виходячи з окремих етапів, описаних в ТЗ. Вартість бренд-айдентики повинна бути розділена на два окремих платежа по $3250 кожний. Рахунок повинен бути оплачений в повному розмірі протягом п’яти робочих днів після його виставлення та передачі клієнту.
- Комунікація. Для зв’язку використовується електронна пошта, WhatsApp, Google Chat, Slack, Discord або аналогічні засоби зв’язку.
- Артефакти та матеріали. Файли Figma з доступом через захищений URL. Презентації Google Slides або PDF з доступом через захищений URL.
Зверніть увагу, що ТЗ для послуг аутстафінгу буде відрізнятися. В такому ТЗ повинні бути, як мінімум, список членів команди, фіксований рейт та роль кожного члена команди.
Наступний важливий крок – узгодити з клієнтами умови зміни, зупинки та розірвання ТЗ. Клієнт може змінити об’єм робіт, тому MSA повинен визначати точну процедуру на цей випадок.
Запит на зміни означає одне з двох:
- Вимогу клієнта про виконання додаткових робіт, не передбачених в узгодженому та затвердженому ТЗ.
- Зміну технічних специфікацій.
Наприклад, наступні ситуації можуть вважатися змінами:
- Додавання нової задачі або етапу (функції, модуля, послуги)
- Оновлення об’єму узгоджених задач
- Зміна порядку виконання узгоджених задач
- Видалення існуючої задачі
- Зміна технології
Нові послуги, додані через запит на зміни, заново оцінюються компанією та вимагають додаткових витрат, які понесе клієнт.
Ми радимо вам серйозно ставитися до оформлення запитів на внесення змін та їх змісту, оскільки лише правильно складені документи можуть бути використані в суді, якщо клієнт відмовиться оплатити роботу. Така ситуація сталася з CIGNEX, глобальною консалтинговою компанією, що пропонує рішення, послуги та платформи на базі технологій Open Source, Cloud та Automation. Клієнт компанії відмовився сплатити більше $350 000 за послуги, надані в межах п’яти запитів про зміни. Три з них були підписані сторонами та визначали кількість часу, затраченого членами команди CIGNEX на певні етапи проєкту, а також їх погодинні ставки. Два інших запити не були узгоджені та оформлені у письмовому вигляді. Тому суд США округу Делавер постановив, що стягнення боргу можливе лише за трьома правильно оформленими запитами на зміни. Кейс CIGNEX ілюструє наскільки важливо зафіксувати навіть мінімальні зміни у проєкті за допомогою запиту на внесення змін.
Наступний крок — встановити процедуру розірвання. Одна або обидві сторони можуть розірвати будь-яке ТЗ повністю або частково. Щоб захистити права компанії, важливо встановити строк, протягом якого клієнт повинен повідомити про розірвання, наприклад, 30 робочих днів. Після отримання такого повідомлення, компанія інформує клієнта про всі роботи, виконані на момент надходження повідомлення. Клієнт зобов’язується прийняти та оплатити роботу, виконану до дати розірвання ТЗ.
Крім цього, компанія залишає за собою право призупинити або припинити виконання робіт у випадку, якщо клієнт вчасно не оплатив інвойс.
Правильно оформлене ТЗ, запит на зміни та процедура розірвання забезпечують чіткість та прозорість, допомагають уникнути спорів та знижують фінансові ризики.
Простій в роботі команди
До MSA слід додати пункти про простій, щоб пом’якшити фінансові ризики та ефективно впоратися з затримками проєкту. Нижче перелік таких пунктів.
- Визначення простою. У MSA важливо написати, що вважається простоєм. Це час, протягом якого команда проєкту не працює через затримки зі сторони клієнта.
- Список ситуацій на стороні клієнта, які будуть вважатися простоєм. Затримки можуть включати відмову клієнта надати необхідні доступи, матеріали, несвоєчасне узгодження ТЗ та етапів проєкту.
- Наслідки простою. Ми пропонуємо додати до MSA положення про оплату часу простою за ставкою, вказаною в ТЗ.
Дебаг
Перш за все, включіть до MSA визначення того, що вважається багом. Наприклад, баг – це будь-яке порушення коректної та стабільної роботи програмного забезпечення, що зумовлене помилками членів команди компанії-розробника. Помилки можна класифікувати наступним чином:
- Помилки, що блокують: роблять використання програмного забезпечення неможливим. Такі помилки негативно впливають на програмне забезпечення та бізнес клієнта.
- Істотні помилки: заважають правильній роботі ключових функцій програмного забезпечення, це такі помилки як значні відхилення від бізнес-логіки або некоректна реалізація деяких функцій.
- Неістотні помилки: не впливають на правильне функціонування програмного забезпечення, але погіршують користувальницький досвід, наприклад, помилки в дизайні UI/UX.
Далі встановіть гарантійний строк, протягом якого клієнт може звернутися до компанії з запитом про виправлення помилок. До прикладу, клієнт може надіслати запит компанії-розробнику програмного забезпечення протягом 45 днів з моменту повної оплати наданих послуг.
Коли клієнт надсилає запит, компанії належить визначити, це є виправлення помилки чи запит на зміни. Компанія повинна ідентифікувати та виправити помилки безкоштовно, якщо:
- Помилка не була і не могла бути виявлена на момент прийняття роботи.
- Баг викликано технічною помилкою зі сторони члена команди, в результаті якої програмне забезпечення не відповідає технічним вимогам.
- Треті сторони не вносили змін до коду програмного забезпечення і компанія є єдиним розробником коду.
У той же час, наступні випадки не повинні класифікуватися як баги:
- Помилки, викликані дефектами вихідних матеріалів клієнта.
- Додаткові роботи, які не описані в ТЗ.
Як розробити ефективний MSA?
Щоб написати ефективний MSA, вам необхідно враховувати ключові особливості проєкту, такі як ваша модель роботи (аутсорсинг чи аутстафінг) та модель оплати (фіксована ціна чи погодинна оплата). Ці характеристики створюють різні ризики, тому MSA повинен містити положення, що враховують специфічні виклики вашої компанії.
MSA – це не єдиний документ, який необхідно підписати з клієнтом. Щоб зрозуміти повний об’єм документів, необхідних для захисту вашої компанії, ознайомтеся з нашими статтями про NDA та угоду про захист даних (DPA).
