В очередной раз хотим затронуть тему, когда компания разработчик ПО выполняет свою работу, но заказчик не хочет ее оплачивать. И судя по количеству публикаций на подобную тему, актуальность данного вопроса для отечественных разработчиков ПО растет.
Описанная ниже ситуация — это ситуация из жизни. В момент написания статьи данная ситуация еще не получила окончательного положительного разрешения для компании разработчика ПО (далее будем называть ее ИТ компания, название компании в данный момент раскрыть не можем), с которым мы работаем вот уже более года по взысканию семизначной суммы задолженности. Возможно, для кого-то данная статья окажется полезной и позволит избежать подобной участи, либо позволит минимизировать возможные потери если ситуация еще не сильно запущена.
Предыстория
В конце 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 был отклонен довод Истца о передаче спорных претензий ответчику по электронной почте. Причинами такого вывода суда послужили как не предоставление доказательств согласования сторонами использования электронных документов в претензионном порядке по спорному договору так и тот факт, что передача претензий по электронной почте не свидетельствует об их получения истцом.
В заключении
- Четко формулируйте предмет договора, чтобы исключить двусмысленное его понимание;
- Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.;
- Указывайте реально осуществимые сроки выполнения работ с учетом времени, необходимого на согласования проектной документации и приемо-сдаточные мероприятия. Предусматривайте увеличение сроков выполнения работ, на случай задержек со стороны заказчика сроков согласования проектной документации или выполнения работ находящихся в его зоне ответственности, а также его ответственность за подобные действия или бездействия;
- Описывайте порядок сдачи работ, документально фиксируйте сам факт передачи заказчику результата работ и документации по проекту (проектной, первичной и т.д.).
- Описывайте порядок коммуникаций, каким образом будет вестись переписка при выполнении работ, указывайте ФИО уполномоченных лиц, их адреса электронной почты, телефоны. Просите подтверждения наличия полномочий у доверенных лиц (доверенность, приказ о наделении полномочиями).
- Кроме того, при заключении договора или при его исполнении рекомендуем избегать прямых ссылок на ГОСТы или иные нормативные документы, это поможет избежать злоупотреблений со стороны заказчика, если созданное вами ПО или проектная документация не будет полностью соответствовать требованиям ГОСТов, если конечно это явно не предусмотрено договором.
- И последняя рекомендация, не поддавайтесь на давление со стороны заказчика ни в момент заключения договора, ни в процессе его исполнения, не соглашайтесь на заведомо не выгодные для вас условия. Лучше откажитесь от контракта, сэкономите нервы и деньги. Работайте только с теми, кто готов выполнять свои обязательства, ну и конечно сами их выполняйте.
Надеемся, что данная статья окажется для читателей полезной и изложенные в статье рекомендации помогут избежать негативных последствий и долгих судебных процессов.
Если есть вопросы задавайте. Если кто-то попал в похожую ситуацию, пишите в комментариях, будем рады помочь, по условиям договоримся.
Автор: itjus
