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

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

Это отличается от обычных отношений между заказчиком и исполнителем. Например, если вы заказываете пошив индивидуального костюма в ателье, то как заказчик (пользователь), вы не несете особого «обязательства». «Обязательство» лежит исключительно на исполнителе заказа, то есть на ателье (вендоре). Именно из-за необходимости большого количества людей и времени для IT-системы, пользователю также необходимо «сотрудничать» с вендором.

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

Собственная система не означает, что все можно отдать на откуп

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

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

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

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

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

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

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

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

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

Давайте попробуем перевести вышеуказанный текст решения на IT-термины разработки систем.

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

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

Как интерпретируются запросы на изменение спецификаций после завершения проекта?

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

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

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

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

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

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

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

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

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

Если дополнительная работа была запрошена после уточнения спецификаций производственного или тестового процесса

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

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

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

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

Связанная статья: Как вести протоколы совещаний при разработке систем с юридической точки зрения[ja]

Вывод: важно помнить, что формирование требований – это процесс со стороны пользователя

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

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