Закон, связанный с 'срывом' проектов по разработке систем

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

Почему проекты “срываются”

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

• Сроки уже определены, но спецификации и требования остаются неясными, и время просто проходит
• Члены команды слишком заняты внутренней политикой и часто отказываются от проекта из-за стресса, связанного с межличностными отношениями
• Уровень управления, включая PM, страдает от недостатка навыков переговоров, и от них не требуется адекватного отчета, связи и консультаций с членами команды

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

Тип возгорания 1: Когда проект застревает на полпути

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

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

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

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

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

Также, “застой” часто происходит на этапе приемки. Подробнее о приемке можно прочитать в следующей статье.

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

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

Тип воспламенения 2: Отмена по собственному усмотрению пользователя

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

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

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

・В случае договора подряда: статья 641 Гражданского кодекса Японии (Japanese Civil Code)
Статья 641 Гражданского кодекса Японии
→ Заказчик может в любое время расторгнуть договор, уплатив убытки, если подрядчик не завершил работу.
・В случае договора поручения: статья 648, пункт 3 Гражданского кодекса Японии (в зависимости от обстоятельств, возможно требование компенсации убытков на основании статьи 651)
Статья 648 Гражданского кодекса Японии
→ Если исполнение прекращается на полпути по причинам, которые не могут быть приписаны исполнителю, исполнитель может требовать оплату в соответствии с степенью выполнения работы.
Статья 651 Гражданского кодекса Японии
→1. Поручение может быть расторгнуто в любое время любой из сторон.
→2. Если одна из сторон расторгает поручение в невыгодное для другой стороны время, она должна возместить убытки другой стороне. Однако, это не применяется, если есть уважительная причина.

Тип 3 воспламенения: когда недостатки в поставленной системе обнаруживаются позже

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

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

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

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

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

В этом случае следует рассмотреть следующие моменты:

Таким образом, можно сделать следующую классификацию.

Заключение

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

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