Как поступить, если разработка системы была прервана по причинам, связанным с пользователем

Работа по разработке систем, как правило, часто представляет собой долгосрочные проекты. Но что если, уже начав работу над разработкой системы, со стороны пользователя внезапно поступает одностороннее заявление вроде “Эта система больше не нужна, не надо ее создавать”. Что может сделать вендор, который принял эту работу?

В этой статье мы рассмотрим особенности контрактов на разработку систем и обсудим возможные варианты действий в такой ситуации.

Значение рассмотрения прерывания по причинам пользователя

В контракте на разработку системы есть несколько особенностей, которые стоит отметить. Во-первых, срок его выполнения обычно длительный, и вендор, обязанный управлять проектом, несет большую ответственность и имеет большую свободу действий. Общий контекст обязанностей вендора по управлению проектом подробно описан в следующей статье.

Во-вторых, пользователь, даже будучи клиентом, несет широкий спектр обязанностей по сотрудничеству с вендором. Система, которую использует компания, не может быть полностью передана вендору. Внутри компании также есть обязанность сотрудничать, чтобы вендор мог проявить свою профессиональность в работе. Об этом подробно рассказано в следующей статье.

Если кратко подвести итог вышеизложенного, между вендором и пользователем существует отношение “внешнего исполнителя”, разрабатывающего систему, и “клиента”, платящего вознаграждение, а также, в то же время, стороны должны сотрудничать для достижения общей цели проекта. Эта сложность отношений обычно отсутствует у портных, делающих одежду на заказ, и является одной из основных особенностей контрактов на разработку систем. Споры, связанные с разработкой систем, из-за этой сложности отношений, если они запутываются, часто становятся сложными и запутанными в вопросе о том, как следует правильно урегулировать отношения между сторонами с юридической точки зрения.

Рассмотрение вопроса о том, как следует понимать отношения прав и обязанностей сторон, если пользователь внезапно скажет: “В конечном итоге, мне не нужна эта система, больше не нужно продолжать проект”, имеет значение представления практического примера юридического мышления перед сложными контрактными отношениями. Ниже мы рассмотрим вопросы, которые следует рассмотреть в этом случае.

Сначала упорядочим причины, по которым был предложен расторжение договора

С точки зрения поставщика услуг, может возникнуть ситуация, когда “пользователь односторонне заявляет о желании прервать проект”, но это восприятие не всегда может быть общим с пользователем. Например, представим ситуацию, когда был запущен проект по разработке системы управления персоналом для сотрудников, работающих за рубежом, но позже планы на зарубежное расширение были отменены, и разработка такой системы стала ненужной. Действительно, судя только по этому объяснению, это может быть воспринято как одностороннее изменение решения со стороны пользователя.

Однако, что если в процессе принятия такого решения у поставщика услуг были проблемы, такие как задержки на различных этапах проекта, и трудности в развитии самого проекта также стали одной из причин изменения политики компании?

Как уже упоминалось, разработка системы требует тесного сотрудничества и взаимных обязательств как со стороны поставщика услуг, так и со стороны пользователя. Поэтому, даже если пользователь выразил желание прервать проект, и поставщик услуг считает, что это расторжение по собственному желанию пользователя, он должен быть готов к тому, что ему могут указать на его собственные причины для расторжения, и он может быть обвинен в неисполнении обязательств или договоренности о расторжении.

Важно различать, является ли это расторжением по собственному желанию, расторжением на основании неисполнения обязательств или согласованным расторжением. Это зависит от прогресса проекта и предыдущих переговоров, и тенденция к индивидуальному суждению в каждом случае довольно сильна. Поэтому, если поставщик услуг продолжает обработку после того, как он признает, что это расторжение по собственному желанию пользователя, важно оставить четкую запись об этом в протоколах собраний и т.д., чтобы избежать споров по этому вопросу в будущем.

Подтверждение оснований для требования вознаграждения и компенсации ущерба

Учитывая вышеуказанные моменты, если речь идет о расторжении по инициативе пользователя, следующим шагом будет рассмотрение возможности предъявления требований о вознаграждении в соответствии с степенью завершенности работы или требований о компенсации ущерба от поставщика к пользователю.

Статьи, на которые следует ссылаться в таких случаях, отличаются в зависимости от типа контракта. Контракты на разработку систем можно в общих чертах разделить на контракты подряда и контракты на предоставление услуг.

В случае контрактов на предоставление услуг и контрактов подряда, Гражданский кодекс устанавливает следующие положения:

a.) В случае контракта на предоставление услуг
Требование о вознаграждении: Статья 648, пункт 3 Гражданского кодекса Японии
Если исполнение прекращается на полпути по причинам, которые не могут быть приписаны исполнителю, исполнитель может требовать вознаграждение в соответствии с уже выполненной работой.
Требование о компенсации ущерба: Статья 651 Гражданского кодекса Японии
1. Каждая из сторон может в любое время расторгнуть договор.
2. Если одна из сторон расторгает договор в невыгодное для другой стороны время, она должна компенсировать ущерб другой стороне. Однако, это не применяется, если есть уважительная причина.

b.) В случае контракта подряда
Требование о компенсации ущерба: Статья 641 Гражданского кодекса Японии
Пока подрядчик не завершит работу, заказчик может в любое время расторгнуть договор, компенсируя ущерб.

Кроме того, предполагается, что диапазон компенсации ущерба на основании статьи 641 Гражданского кодекса Японии включает не только уже понесенные расходы, но и “прибыль, которую можно было бы получить, если бы договор не был расторгнут”. Это отражает мысль о том, что нет смысла в том, чтобы закон заставлял завершить работу, которая стала ненужной для заказчика, и что в таких случаях более разумно гарантировать прибыль подрядчика, выплачивая ему эквивалентное вознаграждение.

Однако, стоит отметить, что в отношении компенсации ущерба на основании статьи 641 Гражданского кодекса Японии, в индивидуальных контрактах между поставщиком и пользователем часто бывают случаи, когда компенсация ущерба исключается из договора. В таких случаях, индивидуальные договоренности между сторонами (т.е. контракт) имеют преимущество, и положения Гражданского кодекса не применяются, поэтому необходима осторожность.

Дальнейшее доказательство объема работ и ущерба

В случае расторжения контракта по инициативе пользователя, наиболее распространенными условиями контракта являются возможность предъявления требования о плате за выполненный объем работ (то есть завершенную часть) и требования о компенсации ущерба. Поэтому обычно со стороны поставщика требуется представление доказательств объема работ и ущерба для предъявления требования о компенсации ущерба.

Однако, доказательство выполненного объема работ, то есть процента завершенности, может оказаться очень трудоемкой задачей. Потому что, особенно когда есть несколько субподрядчиков, количество интервью для проверки прогресса, которые необходимо провести, может быть значительным. Кроме того, создание документов для подтверждения результатов интервью и документирование самого содержания интервью может занять много времени. Если даже после всего этого доказательства оказываются недостаточными, вся затраченная работа может оказаться напрасной, что также является одной из проблем.

Учитывая все эти факторы, возможными мерами могут быть, например, указание в контракте с самого начала, что в случае расторжения контракта в середине срока, расчет будет производиться пропорционально количеству дней до момента расторжения, или другие усилия для упрощения расчетов. Кроме того, учитывая трудоемкость доказательства выполненного объема работ, можно рассмотреть отказ от требования о плате за выполненный объем работ и вместо этого предъявить требование о плате за “затраты, понесенные на разработку уже выполненной части”. Если это внутренние затраты на разработку, они могут быть легко рассчитаны по простой формуле “количество часов x ставка”. Особенно в проектах с низкой рентабельностью, приоритетом может быть требование платы на основе затрат, а не выполненного объема работ, что может облегчить взыскание долгов и компенсацию убытков, что, в свою очередь, может стать более реалистичной мерой обеспечения прав.

Что следует рассмотреть с точки зрения пользователя?

Кстати, с точки зрения пользователя, который хочет расторгнуть договор по своей инициативе, также есть вопросы, которые следует рассмотреть заранее. Это подразумевает под собой подтверждение приблизительной суммы возмещения ущерба, которую следует заплатить поставщику. Здесь мы говорим о “приблизительной” сумме, чтобы иметь общее представление о том, как будет развиваться последующее обсуждение (поскольку выражение намерения расторгнуть договор будет контрпродуктивным, если оно будет задержано, точная сумма не так важна).

Если подтвержденная приблизительная сумма кажется несправедливо высокой, следует запросить объяснение. Однако, если вы попытаетесь вести жесткие переговоры, чтобы снизить сумму платежа, это может привести к бессмысленным судебным искам и дальнейшему усложнению ситуации. Если переговоры между двумя сторонами становятся сложными, можно обратиться за советом к адвокату.

В этой статье мы рассматривали вопрос на основе предположения, что договор о разработке системы был заключен. Однако, на практике в области разработки систем часто возникают споры о том, был ли договор заключен действительно. Мы подробно обсуждаем этот вопрос в следующей статье.

https://monolith.law/corporate/system-development-contract[ja]

Заключение

В этой статье мы рассмотрели процесс решения проблемы, связанной с приостановкой проекта по причинам, исходящим от пользователя. Однако, главный момент этой статьи заключается в необходимости рассмотрения вопросов: “Действительно ли можно говорить о том, что это было по собственному усмотрению пользователя?” и “Не было ли каких-либо просчетов со стороны поставщика?”

Особенностью проекта по разработке системы является то, что как поставщик, так и пользователь несут большие обязательства. Учитывая это, необходимо тщательно рассмотреть, действительно ли возможно одностороннее возложение ответственности на другую сторону. Если этого не сделать, можно лишь усугубить ситуацию, что следует иметь в виду.