Как правильно оформить договор на разработку по заказу и на сопровождение — выбор между договором доверительного поручения и договором подряда по «Модельному договору» IPA

«Заключили договор подряда с фиксированной ценой, но разработка началась до того, как устоялись требования, и в итоге спорили о том, что считать завершением».

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

«Запросили смету, а нам сказали: „определение требований - это доверительное поручение“, но непонятно, почему тип договора меняется от этапа к этапу».

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

На самом деле у этой проблемы есть официальный «образец» - это «Модельный договор и сделка для информационных систем», публикуемый IPA (независимым административным агентством содействия обработке информации).

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

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

1. Сначала вывод

Сначала соберём подход, который излагает «Модельный договор и сделка» IPA в отношении договоров на разработку систем и на эксплуатацию/сопровождение.

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

Одним словом, принцип такой: «не обещать ответственность за завершение того, что ещё не решено, но обещать её для того, что уже решено» - и в зависимости от этапа выбирается своя форма договора.

2. Что такое «Модельный договор и сделка для информационных систем» от IPA

«Модельный договор и сделка для информационных систем» - это официальный документ, объединяющий образец договора на аутсорсинг разработки систем и пояснения к нему.

Изначально его в 2007 году опубликовало Министерство экономики, торговли и промышленности Японии (METI) как первую версию, охватывающую разработку по заказу (включая частично планирование) и сопровождение/эксплуатацию. Поводом послужило то, что расхождения в понимании условий договора между компанией-пользователем (заказчиком) и ИТ-поставщиком (исполнителем) часто приводили к конфликтам.

Впоследствии доработку взяла на себя IPA, и 22 декабря 2020 года была опубликована вторая версия, приведённая в соответствие с изменённым Гражданским кодексом, вступившим в силу в апреле 2020 года. Во второй версии, в частности, уточнены ответственность за несоответствие результата условиям договора (о ней ниже) и статус доверительного поручения с оплатой по результату.

Стоит обратить внимание на область применения. Первая и вторая версии изначально создавались с расчётом на сравнительно крупномасштабную заказную разработку (по каскадной модели) - например, базовых систем предприятий - и на сделки между компаниями, у которых есть собственные ИТ-подразделения и юридическая служба. Для сделок меньшего масштаба или для случаев использования готовых пакетов и SaaS отдельно подготовлена дополнительная версия модельного договора, охватывающая «использование пакетов, SaaS/ASP, эксплуатацию и сопровождение». Правильный подход - определить, какая из версий ближе к вашей сделке, и использовать её не как готовый текст условий, а как основу для собственного мышления. Материал, который представлен в этой статье, тоже относится именно к такой «основе мышления», полезной независимо от масштаба.

У этого модельного договора есть следующие особенности:

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

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

3. Суть - в «многоступенчатом договоре»: зачем разделять договор по этапам

Суть подхода «Модельного договора и сделки» - это многоступенчатый договор.

Разработка систем в общих чертах проходит через следующие этапы.

Планирование и определение требований (решаем, что создавать)
        ↓
Проектирование, разработка, тестирование (создаём решённое)
        ↓
Приёмка и поддержка внедрения (переводим созданное в рабочий процесс)
        ↓
Эксплуатация и сопровождение (поддерживаем работу)

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

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

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

• исполнитель называет более высокую сумму, закладывая в неё неопределённые риски;
• исполнитель, взявшийся за низкую цену, впоследствии заявляет: «это вне рамок договора», - и возникает конфликт с заказчиком.

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

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

4. Доверительное поручение и подряд - разница между двумя типами договора

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

Договор подряда - договор, обещающий завершение

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

Если поставленный результат не соответствует условиям договора, исполнитель несёт ответственность за несоответствие условиям договора. Это понятие было переформулировано из прежней «ответственности за скрытые недостатки» в рамках изменений Гражданского кодекса, вступивших в силу в 2020 году: заказчик может потребовать устранения недостатков, а при определённых условиях - например, если устранение было запрошено в установленный срок, но не выполнено, - также может потребовать снижения оплаты. Однако если несоответствие возникло из-за самих спецификаций или указаний, предоставленных заказчиком, эти требования, как правило, недоступны - за исключением случаев, когда исполнитель заметил проблему, но не сообщил о ней. Вторая версия модельного договора отражает это изменение.

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

Договор доверительного поручения - договор, обещающий работу специалиста

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

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

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

Выбор типа по этапам

«Модельный договор и сделка» в общих чертах предполагает следующее разграничение.

Здесь важно понимать: это не сводится к простому «подряд выгоднее заказчику, доверительное поручение выгоднее исполнителю».

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

5. Что нужно закрепить в договоре на эксплуатацию и сопровождение

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

«Эксплуатация и сопровождение» как единая фраза на деле объединяет работы разной природы.

• Мониторинг работоспособности, резервное копирование, регулярное обслуживание
• Обработка обращений по вопросам эксплуатации
• Первичное расследование и восстановление при возникновении сбоя
• Исправление дефектов
• Отслеживание обновлений ОС и промежуточного ПО
• Доработки вроде добавления функций или изменения экранов

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

При заключении договора рекомендуем письменно зафиксировать как минимум следующие пункты:

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

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

6. У заказчика тоже есть обязанности - обязанность содействия и обязанность управления проектом

Это несколько выходит за рамки темы договоров, но это важная идея, которую неоднократно подчёркивают и пояснения к «Модельному договору и сделке», и судебная практика: разработка систем - это совместная работа заказчика и поставщика, и обязанности есть у обеих сторон.

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

Иными словами, если заказчик под предлогом «мы не разбираемся в технической стороне» перекладывает всё на поставщика - так называемый полный сброс задачи, - требования не устаиваются, а в случае провала проекта под вопрос может попасть и собственная обязанность содействия заказчика.

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

7. Изменения спецификации оформляются через «процедуру управления изменениями»

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

• Заказчик думал: «это должно было быть небольшое изменение»
• Исполнитель думает: «мы это сделали, но объём работ вырос, и мы хотим выставить дополнительный счёт»

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

«Модельный договор и сделка» устанавливает процедуру управления изменениями. В общих чертах последовательность такая.

Предложение изменения (от любой из сторон)
        ↓
Письменное представление содержания, области влияния, стоимости и влияния на срок (предложение об изменении)
        ↓
Обсуждение сторонами
        ↓
При согласии - фиксация в письменном виде и внесение изменения / при отсутствии согласия - работа продолжается по прежнему плану

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

8. Для гибкой разработки существует отдельный модельный договор

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

Для гибкой (agile) разработки, где требования пересматриваются по мере создания продукта, 31 марта 2020 года был опубликован отдельный модельный договор - «Модельный договор и сделка для информационных систем» (версия для гибкой разработки).

У версии для гибкой разработки следующие особенности:

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

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

Итог

Соберём подход к договорам на разработку по заказу и на эксплуатацию/сопровождение, который можно вынести из «Модельного договора и сделки для информационных систем» IPA.

• Не сводить весь процесс разработки в один договор, а разделять его по этапам (многоступенчатый договор)
• Планирование и определение требований, где решается, «что создавать», - доверительное поручение; разработка от внутреннего проектирования и далее, где то, что создаётся, уже зафиксировано, - по умолчанию подряд (внешнее проектирование может идти любым путём)
• Подряд несёт ответственность за завершение и за несоответствие условиям договора, доверительное поручение - обязанность заботливого и добросовестного исполнения: природа ответственности исполнителя различается
• Эксплуатация и сопровождение по умолчанию оформляются доверительным поручением, а граница между фиксированным объёмом и отдельными сметами документируется при заключении договора
• У заказчика тоже есть обязанность содействия, и полный сброс задачи на поставщика обрекает проект на провал
• Изменения спецификации проводятся через процедуру управления изменениями и согласуются вместе с влиянием на стоимость и срок
• Для гибкой разработки существует отдельный модельный договор, построенный на доверительном поручении

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

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

Чтобы правильно выбрать форму договора, для начала нужно определить, «что создаётся», «в каком объёме передаётся на аутсорсинг» и «как распределяются роли между заказчиком и исполнителем».

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

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

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

В чём разница между договором подряда и договором доверительного поручения?

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

Почему для этапа определения требований рекомендуется договор доверительного поручения?

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

Что лучше для договора на эксплуатацию и сопровождение - подряд или доверительное поручение?

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

Можно ли использовать «Модельный договор» IPA как есть?

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

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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