Как заключать договор на заказную разработку и сопровождение: подряд и оказание услуг по модельному договору IPA

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

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

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

Когда разработку систем отдают внешнему исполнителю, конфликты часто возникают не из-за технологии, а из-за формы договора.

У этой проблемы есть официальный образец: «Модельные сделки и договоры для информационных систем», которые публикует IPA (независимое административное учреждение Японии, Агентство по развитию информационных технологий).

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

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

1. Сразу к сути

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

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

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

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 27, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

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

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

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

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

У этого модельного договора есть такие черты:

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

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

Какую редакцию смотреть

На сайте IPA лежит несколько редакций. Сначала решите, какая ближе к вашей сделке, — тогда не заблудитесь в списке.

Дальнейшее объяснение в этой статье исходит из основной части второй редакции — самой базовой.

3. Суть — многоэтапный договор: зачем дробить договор по этапам

Ядро подхода модельного договора — многоэтапный договор.

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

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

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

Фактическая структура документов: рамочный договор и отдельные договоры

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

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

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

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

Документы, которые входят в основную часть второй редакции, такие.

Зачем дробить? Причина простая: на разных этапах можно обещать разное.

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

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

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

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

4. Оказание услуг и подряд: чем отличаются два типа договора

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

Сначала коротко соберём термины, которые появятся в этой главе.

Дальше сведём разницу подряда и оказания услуг в одну таблицу.

Договор подряда: договор, который обещает завершение

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

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

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

Договор оказания услуг: договор, который обещает работу специалиста

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

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

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

Как выбирать тип по этапам

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

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

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

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

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

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

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

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

На словах это трудно прочувствовать, поэтому ниже примеры границы. Где именно её провести — предмет договора; это лишь «часто встречающаяся договорённость».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Для Agile есть отдельный модельный договор

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

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

У версии для Agile такие черты:

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

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

Итог

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

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

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

Если вы рассматриваете заказную разработку или сопровождение системы

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

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

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

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

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

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

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

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

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

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

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

Договор подряда (請負) — это договор, по которому платят за завершение согласованного результата работ. Исполнитель несёт ответственность за завершение и за несоответствие результата условиям договора. Договор оказания услуг (準委任) — это договор, по которому платят за выполнение работы как специалистом (в варианте с оплатой за результат платят за согласованный результат). Исполнитель несёт обязанность должной заботливости — работать внимательно, как специалист, — но не отвечает за завершение. Этапы, где можно чётко определить, что создаётся, и критерий завершения, подходят для подряда. Этапы, где исполнитель лишь помогает заказчику принять решение, и непрерывная по своей природе работа лучше оформляются как оказание услуг.

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

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

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

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

Можно ли брать модельный договор IPA как есть?

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

Об авторе

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

Го Комура

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

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