6 типових помилок при укладанні договорів на розробку

В черговий раз хочемо торкнутися теми, коли компанія розробник ПЗ виконує свою роботу, але замовник не хоче її оплачувати. І судячи з кількості публікацій на подібну тему, актуальність даного питання для вітчизняних розробників ПО зростає.

Описана нижче ситуація — це ситуація з життя. В момент написання статті дана ситуація ще не отримала остаточного позитивного дозволу для компанії розробника (далі будемо називати її ІТ компанія, назву компанії в даний момент розкрити не можемо), з яким ми працюємо вже більше року по стягненню семизначні суми заборгованості. Можливо, для когось ця стаття виявиться корисною і дозволить уникнути подібної долі, або дозволить мінімізувати можливі втрати, якщо ситуація ще не сильно запущена.

Передісторія
В кінці 2014 року між ІТ компанією і замовником було укладено договір на впровадження 1С. Справа йде до кінця року, і як завжди це буває, замовник хоче все швидко і як можна дешевше. Звичайна ситуація. Попередні переговори пройшли успішно. Справа дійшла до укладення договору. Договір був підготовлений ІТ компанією, його конструкція була досить простою. Дана форма договору використовувалася досить тривалий час і до певного моменту проблем не викликала. На вимогу Замовника договір було внесено ряд змін. Оскільки терміни виконання робіт зафіксовані в договорі підганяли і для того щоб не затягувати узгодження документа він був підписаний в тому вигляді, в якому його хотів бачити Замовник.

Проект йде повним ходом. Проведено проектування, підготовлено ТЗ, розпочато його узгодження. Як це часто буває, Замовник не поспішає з погодженням проектної документації. ІТ компанія приймає рішення почати розробку на основі ще неузгодженого ТЗ на свій страх і ризик. Залишається трохи більше двох тижнів до завершення робіт по розробці і ТЗ нарешті узгоджено. Терміни здачі робіт при цьому офіційно зрушені не були. Було вже зрозуміло, що у визначений договором строк вкластися не вдасться. Однією з вимог замовника було почати працювати в новій системі відразу після новорічних свят. Виконавець вирішив ризикнути, почати експлуатувати частина підсистем створеного програмного рішення як планувалося, тобто відразу після новорічних свят, виконавши для цього під час новорічних канікул підготовчі роботи. Але як це зазвичай буває в подібній ситуації, білий пухнастий звір підкрався непомітно. Пішовши на поводу ІТ компанія недооцінила інертність спеціалістів замовника, а також взяла на себе зобов'язання виконати ряд робіт не зазначених у договорі, задіявши для цього частину ресурсів зайнятих розробкою, що в свою чергу знизило її швидкість. А проблеми, що виникли в ході дослідної експлуатації реалізованих підсистем переключили частину розробників на гасіння пожеж. Розробка іншого функціоналу фактично встала. Виникла криза управління всередині проектної команди виконавця. Взаємини із замовником стали посилюватися.

В якийсь момент з замовником вдалося знайти спільну мову, принаймні так здавалося ІТ компанії. Терміни виконання робіт були давно пройдені. В якийсь момент стали з'являтися ознаки того, що замовник просто в'є з виконавця мотузки і платити не збирається. Стало зрозуміло, що справа пахне гасом. Пізніше ці підозри стали виправдовуватися. Тільки в цей момент було вирішено залучити для консультацій спеціаліста з договірних відносин та повернення дебіторської заборгованості.

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

Виявлені помилки
Перша помилка – нечітко сформульований предмет договору. Але був сформульований наступним чином «… Замовник доручає, а Виконавець приймає на себе зобов'язання з постачання і впровадження програмного забезпечення 1С: Підприємство 8 згідно Додатку №2...». Додаток 2 містило мало конкретики, за формою це була специфікація із зазначенням видів робіт і трудовитрат за ним. Кожна зі сторін по-своєму трактувала предмет договору. Компанія виконавець розуміла під цим доопрацювання стандартної конфігурації 1С: Підприємство під завдання замовника, її налаштування та впровадження. Замовник бачив те, що буде проведена установка і налаштування 1С: Підприємство без будь-якої модифікації. Він виходив з буквального значення слів і виразів зафіксованих у договорі, такої ж точки зору дотримувався суд, ігноруючи факт створення складного програмного продукту в рамках виконання зобов'язань за договором.

Трохи судової практики:

Стаття 431 ГК РФ при тлумаченні умов договору судом береться до уваги буквальне значення містяться в ньому слів і виразів. Буквальне значення умови договору у разі неясності встановлюється шляхом співставлення з іншими умовами та змістом договору в цілому.

Якщо правила, які містяться в частині першій цієї статті, не дозволяють визначити зміст договору, повинна бути з'ясована дійсна загальна воля сторін з урахуванням мети договору. При цьому беруться до уваги всі відповідні обставини, включаючи попередні договору переговори і листування, практику, усталену у взаємних відносинах сторін, звичаї, подальша поведінка сторін.
Друга помилка – свідомо нездійсненні терміни виконання робіт. Однією з вимог замовника були дуже стислі терміни виконання робіт. Замовник хотів почати експлуатувати систему відразу після новорічних свят. Процес узгодження договору затягнувся, але терміни виконання проекту зрушені не були. Перший зсув термінів стався з вини замовника, коли він затягнув узгодження проектної документації, впливати на цей договір не дозволяв. Також не було враховано можливий внутрішній конфлікт інтересів між службами компанії замовника. В процесі здачі робіт конфлікт інтересів дав про себе знати. Служби, відповідальні за прийняття робіт за своїми напрямами не поспішали це робити, посилаючись на поточну завантаженість. Також одне з ключових осіб компанії, за ініціативою якого було розпочато проект, втратила до нього інтерес. Що також сприяло організаційного опору. В кінцевому підсумку термін здачі робіт був перевищений більш ніж на 6 місяців.

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

Четверта помилка – виконавець погодився на вимоги замовника внести ряд умов у договір явно не вигідних для себе, але оскільки терміни знизували і представники замовника не хотіли домовлятися за умовами договору керівництво ІТ компанії прийняло рішення піти по шляху найменшого опору. Нагадаю, це був кінець 2014 р., санкції, відсутність інших замовлень і т. д, картина типова для багатьох невеликих ІТ компаній, які хапаються за будь-яку роботу і керуються принципом «головне почати, а там подивимося». Умови договору були сформульовані таким чином, що за кожний день прострочення виконання робіт виконавець повинен був виплатити велику неустойку. Через деякий час розмір неустойки виріс до такого рівня, що рентабельність проекту стала практично нульовий і неухильно прагнула стати мінусовій. Цьому сприяла слабка організація робіт всередині проекту, і нездатність оперативно впоратися з виниклими проблемами проекту через брак ресурсів, які були розраховані виходячи з прогнозованого за умовами договору обсягу робіт, і не були розраховані на його збільшення. З урахуванням кабальних умов доводилося йти на компроміс із замовником і виконувати всі його побажання. Також ситуація ускладнилася за рахунок того, що для продовження проекту потрібно зовнішнє фінансування, залучення якого було сильно ускладнено.

П'ята помилка – у договорі чітко не визначена процедура прийому виконаних робіт. Згідно з договором, для підтвердження факту виконання робіт достатньо було пред'явити акт здачі-приймання, при наявності заперечень з боку замовника, він повинен був надати виконавцю мотивовану відмову протягом обумовленого в договорі строку. Після завершення кожного етапу проекту виконавець пред'являв замовнику акти здачі-приймання робіт. РП замовника повинен був організувати приймання робіт, задіявши для цього відповідних фахівців. З-за відсутності необхідних повноважень РП замовника не міг і не хотів впливати на терміни приймання робіт. Виконавець також не міг впливати на терміни приймання робіт, оскільки договором не була обумовлена послідовність дій у процесі приймання і була відсутня відповідальність замовника за затримки. Виконавцю доводилося докладати масу зусиль для здачі робіт замовнику.

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

Трохи судової практики:

Пункт 3 статті 75 АПК РФ свідчить, що документи, отримані за допомогою факсимільного, електронного чи іншого зв'язку, у тому числі з використанням інформаційно-телекомунікаційної мережі «Інтернет», а також документи, підписані електронним підписом або іншим аналогом власноручного підпису, допускаються в якості письмових доказів у випадках і в порядку, що встановлені договором.

Постанова Федерального арбітражного суду Московського округу від 17 травня 2013р. у справі N А40-102005/12-57-977 відмовляючи позивачу в задоволенні його вимог, суд вказав на:

• передбачену договором просту письмову форму документообігу між сторонами;
• відсутність умов щодо можливості виконання договору з електронного листування;
• відсутність посилань на електронні адреси, визначені сторонами в якості допустимих для передачі будь-якої інформації;
• неможливість встановити належність адреси відповідачеві та його співробітникам;
• адреса електронної пошти зареєстрований на домені kameya.ru, який є доступним для використання необмеженим колом осіб.
Постановою ФАС далекосхідного округу от16.11.12 №Ф03-5177/2012 був відхилений довід Позивача про передачу спірних претензій відповідачу по електронній пошті. Причинами такого висновку суду послужили як не надання доказів погодження сторонами використання електронних документів в претензійному порядку за спірним договором так і той факт, що передача претензій по електронній пошті не свідчить про їх отримання позивачем.


В ув'язненні
  • Чітко формулюйте предмет договору, щоб виключити двозначне його розуміння;
  • Технічне завдання або документ, що його замінює, формуйте так, щоб у сторін договору було єдине розуміння про те, як повинна функціонувати створюване, як повинен виглядати користувальницький інтерфейс, система звітів, які технології повинні бути використані при створенні ПЗ і т. д.;
  • Вказуйте реально здійсненні строки виконання робіт з урахуванням часу, необхідного на узгодження проектної документації і приймально-здавальні заходи. Передбачайте збільшення термінів виконання робіт, на випадок затримок з боку замовника строків узгодження проектної документації або виконання робіт знаходяться в його зоні відповідальності, а також його відповідальність за подібні дії або бездіяльності;
  • Описуйте порядок здачі робіт, документально фіксуйте сам факт передачі замовнику результату робіт та документації по проекту (проектної, первинної і т. д.).
  • Описуйте порядок комунікацій, яким чином буде вестися листування при виконанні робіт, вказуйте ПІБ уповноважених осіб, їх адреси електронної пошти, телефони. Просіть підтвердження наявності повноважень у довірених осіб (довіреність, наказ про наділення повноваженнями).
  • Крім того, при укладенні договору або при його виконанні рекомендуємо уникати прямих посилань на Гости або інші нормативні документи, що це допоможе уникнути зловживань з боку замовника, якщо створене вами або проектна документація не буде повністю відповідати вимогам Гостів, якщо звичайно це явно не передбачено договором.
  • І остання рекомендація, не піддавайтеся на тиск з боку замовника ні в момент укладення договору, ні в процесі його виконання, не погоджуйтеся на не вигідні для вас умови. Краще відмовтеся від контракту, заощадите нерви і гроші. Працюйте тільки з тими, хто готовий виконувати свої зобов'язання, ну і звичайно самі їх виконуйте.
Сподіваємося, що дана стаття виявиться корисною для читачів і викладені у статті поради допоможуть уникнути негативних наслідків і довгих судових процесів.

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.