«Підрядник-привид» та «рамковий документ» — як скласти ІТ-договір, який спрацює?
Якщо два-три роки тому позовів між ІТ-компаніями та їх підрядниками практично не було, то зараз з’явилися перші ластівки. В часи війни та COVID-19 у підрядників все частіше виникає спокуса просто зникнути, замість того, щоб закінчувати проєкти, відпрацьовувати свій notice period і передавати справи. Оксана Данкевич, адвоката і партнерка Dexis Partners розглянула кейси ІТ-компаній, з якими таке трапилось, і поділилась порадами, чому правильно складене ТЗ – це вже половина успіху.
Кейс 1: Немає погодженого ТЗ – не може бути претензій
Справа № 922/3978/21 Господарський суд Харківської області, рішення від 07 грудня 2021 р.
ФОП вирішив односторонньо розірвати договір. Договір був рамковим і передбачав, що виконавець надає послуги у сфері інформатизації, передбачені у технічному завданні:
«Замовник надає виконавцеві ТЗ в письмовій або в усній формі, які містять перелік, опис, обсяги, строки та порядок надання послуг. Завдання вважається прийнятим та погодженим виконавцем, якщо протягом трьох днів він не надав вмотивовану відмову від надання послуг за конкретним завданням».
Якщо виконавець без поважних причин не приступить до виконання своїх обовʼязків за договором в погоджений строк, передбачена неустойка у розмірі $3000. У разі дострокового припинення договору з ініціативи виконавця, останній зобовʼязується завершити надання всіх погоджених послуг або ж сплатити неустойку в розмірі $10 000 та відшкодувати всі збитки, повʼязані з припиненням договору.
Компанія звернулася з позовом про стягнення збитків, коштів сплачених за ненадані послуги і неустойки за відмову від виконання договору. Позивач зазначав, що «відповідач не виконав взяті зобовʼязання та не розпочав надання послуг у погоджений строк, не надав послуг програмування, пропав і перестав виходити на звʼязок, припинивши його виконання, фактично не розпочавши».
Рішення суду: У позові відмовлено повністю, оскільки «позивач не довів належними та допустимими доказами порушення відповідачем умов Договору». Суд зробив висновок, що позивач не довів факту передачі конкретного завдання та визначення строків його виконання:
«Технічне завдання містить вказівку лише на абстрактне поняття за завданням замовника надавати послуги з компʼютерного програмування та консультування з питань інформатизації».
Коментар: У цій справі суд не розглядав, чи можна стягувати штраф з виконавця за дострокове розірвання. Це питання було б передчасним, адже не було доведено факту порушення договору. Примітною є оцінка судом рамкових договорів, які так широко використовуються в ІТ. Можна зробити висновок, що формулювання «послуги з комп’ютерного програмування» є занадто абстрактним і не буде достатнім для обґрунтування порушення договору. Погоджене ТЗ – це дуже важливо, і воно має бути сформульоване з достатньою конкретикою та чітко прописаними дедлайнами.
Кейс 2: Чому б не вказати в договорі нікнейми?
Позивач сформував ряд Технічних завдань у JIRA і оплатив відповідачеві 92 310 грн авансу за послуги програмування. Відповідач послуги не надав, тому позивач подав позов про повернення безпідставно отриманих коштів. Згідно з договором відповідач розпочинає надання послуг після отримання опису послуги, котра має бути надана, у технічному завданні. Технічне завдання викладається у JIRA у формі завдання (issue), котре описує дії, які мають бути виконані для надання послуги належним чином. Відповідач ідентифікується у JIRA за допомогою погодженого в договорі нікнейму.
Суд постановив, що кошти безпідставно набуті відповідачем і підлягають поверненню позивачу. Обґрунтування: відповідач не надав суду жодних доказів того, що робота виконана (щодо виконання якої було укладено відповідний договір і сплачено кошти), а її результат переданий позивачу і прийнятий ним.
Коментар: Хоча у цій справі питання правильності оформлення ТЗ не було пріоритетним, побіжно суд погодився із законністю такого алгоритму. Наприклад, у договорі можна прописати, що «замовник передає ТЗ з визначеним дедлайном через конкретний таск-менеджер (Jira, Slack, Notion – будь-що) або обмін мейлами». При цьому в договорі є сенс зазначати, які нікнейми використовують сторони, а також вказувати доменну і особисту електронні пошти на випадок, якщо компанія заблокує доменну в цілях безпеки. Додаково необхідно прописувати процедуру погодження (чи мовчазного погодження) таску виконавцем.
Кейс 3: Порушив порядок розірвання договору – плати
ФОП повідомив про одностороннє розірвання договору. Разом з тим, договір передбачав, що «Виконавець не має права в односторонньому порядку припинити цей договір протягом одного року з моменту підписання договору, а у разі розірвання договору раніше, ніж один рік, Виконавець сплачує пеню у розмірі 20 000 грн».
Крім того, відповідач не повернув усю передану документацію, програми, дані, вихідні коди програм, результати (протоколи) тестування з усіх носіїв інформації. Відповідно до договору, за таке порушення виконавець зобовʼязаний сплатити замовнику штраф у розмірі 100 000 грн. Позивач надіслав на юридичну адресу відповідача лист-претензію з вимогою сплатити штраф та пеню. Претензію відповідач проігнорував.
Рішення суду: Відповідач не спростував позовних вимог щодо стягнення з відповідача пені та штрафу, підтверджені документально та нормами матеріального права, тому вони підлягають задоволенню. У мотиваційній частині – посилання на положення ЦК України, якими визначено, що «сторони є вільними в укладенні договору, виборі контрагента та визначенні умов договору з урахуванням вимог цього Кодексу, інших актів цивільного законодавства, звичаїв ділового обороту, вимог розумності та справедливості. Зміст договору становлять умови, визначені на розсуд сторін і погоджені ними, та умови, які є обов’язковими відповідно до актів цивільного законодавства. Договір є обов’язковим для виконання сторонами».
Коментар: Тут зіграло роль, що замовник зміг довести факт порушення порядку розірвання договору, а також те, що в договорі використали правильне формулювання – штраф не за дострокове розірвання, а за порушення процедури дострокового розірвання. Важливо, що при обґрунтуванні, чому штраф у цій справі виправданий, суд посилався на свободу договору та обов’язковість його виконання.
Кейс 4: Хочеш стягнути штраф – доведи факт порушення
Компанія доводила, що ФОП порушив порядок одностороннього розірвання договору, а ФОП – що договір розірвано без порушень, із завчасним повідомленням. Компанія намагалась стягнути неустойку.
За умовами договір може бути розірваний на вимогу виконавця, яка має бути отримана замовником не пізніше ніж за 60 робочих днів до дати розірвання договору, в іншому разі – штраф. При цьому виконавець не може відмовитися від виконання нових і поточних замовлень замовника протягом 60-ти робочих днів, якщо не сплачено штраф у розмірі 3000 грн за кожен день скорочення вказаного строку.
Рішення суду: В позові повністю відмовлено. Причина №1: Відповідач зміг довести, що скористався наданим йому правом, передбаченим договором та заявив про намір розірвати договір за 60 днів. Причина №2: Позивач нарахував неустойку за дострокове розірвання договору, а не за його порушення. Суд акцентував на тому, що «по своїй суті неустойка є видом забезпечення виконання зобовʼязання та правовим наслідком його порушення. У ЦК України регулювання неустойки відбувається тільки з позицій забезпечення виконання зобовʼязання. При цьому навіть визначення неустойки дозволяє констатувати, що законодавець повʼязує її стягнення саме з порушенням зобовʼязання».
Коментар: Пункт договору про штраф за дострокове розірвання – це не панацея. Суди схиляються до трактування, що штраф може застосовуватись тільки в разі порушення «господарських зобов’язань», а це в свою чергу, передбачає поставку товару, оплату, надання послуги і т.д. Тобто немає сенсу передбачати в договорі штраф за одностороннє розірвання договору, якщо дотримана процедура розірвання. Набагато більше перспектив стягнути штраф за невиконання завдань або ж порушення порядку розірвання договору.
Розірвання договору з недотриманням строків попередження є спірним моментом. Формально це порушення договору, з іншої сторони – не є порушенням саме «господарського зобов’язання». Тому для таких випадків краще підходить формулювання «компенсація завданих замовнику збитків, які сторони попередньо оцінили у Х грн/дол».
Що об’єднує ці справи?
Усі розглянуті кейси мають спільне коріння. Більшість договорів в ІТ-галузі, якщо не говорити про договори на розробку сайту, визначають дуже загальні умови співпраці: розробка ПЗ, консультаційні послуги в сфері інформатизації і таке інше. Натомість конкретні завдання і дедлайни узгоджуються усно.
Звісно, складно уявити компанію, яка щоразу укладає додаткові угоди на кожне завдання, тому в більшості випадків все тримається на довірі. Проте в такому разі, довести в суді чи то невиконання договору, чи то його прямий саботаж, стає практично неможливо.
Зрештою, усні домовленості створюють також великі ризики й для підрядників. Якщо немає зафіксованого ТЗ у будь-якій придатній формі, і доказів передання результатів наданих послуг, а замовник при цьому не оплатив виконану роботу і не підписав акт наданих послуг, тоді в суді виконавець практично безсилий. На відміну від попереднього варіанту, таких кейсів в реєстрі є вже чимало.
Рамкові договори в ІТ – це нормально, і було б безглуздо рекомендувати сторонам фіксувати в договорі детальний обсяг робіт, принаймні в класичному аутсорсі. Проте варто докласти зусиль і насамперед налагодити процедуру постановки ТЗ, а також правильно відобразити цю процедуру в договорі. Тоді можемо сміливо казати, що такі договори матимуть цінність.
Автор: Оксана Данкевич, адвокатка, партнерка в АО Dexis Partners
Коментарі | 0