Что делать, если после приемки обнаружены неполадки в системе?

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

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

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

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

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

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

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

Так что же делать, если такие проблемы действительно возникают? Давайте разберемся в соответствии с юридическим порядком.

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

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

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

В договоре подряда “завершение работы” является условием исполнения обязательства. Что конкретно означает “завершение работы” объясняется подробно в следующей статье.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Здесь объясняется, что в контексте разработки систем “завершение работы” в договоре подряда, согласно прошлым судебным решениям, означает завершение всех этапов разработки. И проблемы, такие как баги и неполадки, возникающие после завершения всех этапов разработки, становятся вопросом ответственности за дефекты в договоре подряда.

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

Путь преследования ответственности на основе обязательств по гарантии от дефектов

Итак, каким образом и в каком порядке следует рассматривать вопросы, если вы хотите требовать от поставщика действий на основе обязательств по гарантии от дефектов? Давайте рассмотрим это ниже.

Сначала проверьте степень серьезности и глубины багов или неполадок

Если баги или неполадки обнаруживаются после факта, и они являются “дефектами” в юридическом смысле, и вы требуете каких-либо гарантий, то серьезность багов или неполадок становится проблемой. Вопрос о юридических дефектах в первую очередь разделяется на три паттерна:

1. Даже если это можно назвать багом или неполадкой, это лишь незначительная проблема, которую нельзя назвать “дефектом” в юридическом смысле
2. Это соответствует “дефекту” в юридическом смысле, но достижение цели контракта все еще возможно
3. Это соответствует “дефекту” в юридическом смысле, и достижение цели контракта также невозможно

Что разделяет возможность преследования ответственности на основе обязательств по гарантии от дефектов, это граница между 1 и 2, а что разделяет возможность расторжения контракта на основе обязательств по гарантии от дефектов, это граница между 2 и 3.

Статья 634

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

2. Заказчик может требовать компенсации ущерба вместо устранения дефектов или вместе с ним. В этом случае применяются положения статьи 533

Статья 635

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

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

https://monolith.law/corporate/defect-warranty-liability[ja]

Затем определите, что следует требовать от поставщика

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

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

Другие важные моменты

Будьте внимательны к способу проведения юридических действий, таких как расторжение договора

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

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Желательно решать проблемы через переговоры, а не споры

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

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Следует различать баги и неполадки, а также недостаток функций

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

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

Заключение

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