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

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

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

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

Обязанности вендора в управлении проектом

Давайте сначала рассмотрим обязанности вендора в управлении проектом.

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

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

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

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

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

Обязанность пользователя сотрудничать

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

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

Обязанности пользователя по сотрудничеству включают следующее:

① Пользователь должен активно проводить анализ рисков, адекватно координировать внутренние мнения и передавать свои требования вендору после унификации своих взглядов.

② Проверка результатов.

③ Ответ на запросы о сотрудничестве от вендора.

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

Управление проектом не является простой задачей

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

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

Что может произойти в случае нарушения обязательств по управлению проектом

Итак, что конкретно может произойти в случае нарушения обязательств по управлению проектом?

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

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

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

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

Судебные прецеденты, демонстрирующие обязанности по управлению проектами

Существуют типичные судебные прецеденты, которые объясняют обязанности по управлению проектами.

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

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

Решение Токийского окружного суда от 10 марта 2004 года (год Хэйсей 16)

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

Давайте переформулируем содержание вышеуказанного решения суда более простым языком и организуем его в виде списка. Таким образом, “обязанности по управлению проектами” включают:

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

Кроме того, в отношении вышеуказанных трех пунктов,

• Необходимо также прилагать усилия к коммуникации, например, просить о необходимой поддержке со стороны пользователя, а не просто полагаться на усилия поставщика

Можно сказать, что это обобщенное название для вышеуказанных пунктов.

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

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

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

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

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

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

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

Решение Верховного суда Токио от 26 сентября 2013 года (Heisei 25)

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

Чем больше сделка, тем дольше обычно процесс “сближения” до достижения цели – контракта. Даже в этом процессе, идея о том, что нужно быть честным по отношению к другой стороне, должна быть хорошо понятна, по крайней мере, с моральной точки зрения. Говоря простым языком, такие вещи не ограничиваются просто эмоциональными моральными чувствами, они имеют значение и с юридической точки зрения. (Цитата из статьи ниже. Подчеркивание добавлено автором.)

Статья 1, пункт 2 Гражданского кодекса Японии
Упражнение прав и исполнение обязанностей должны осуществляться добросовестно и честно.

Ключевое слово в тексте решения, которое кратко описывает содержание выше, – это “принцип добросовестности”.

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

Вывод: при проблемах, связанных с нарушением обязательств по управлению проектами, обратитесь к адвокату

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

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

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

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