Когда и зачем включать условия SCRUM в договор.

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

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

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

Так как мы рассматриваем случай создания работающего приложения IT компанией или ИП с сотрудниками/привлеченными специалистами, будем руководствоваться статьей Гражданского кодекса 1296 «Произведения, созданные по заказу». В этом случае предметом договора будет конечный результат - созданное произведение, условная программа ЭВМ. Что, собственно и нужно Заказчику.

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

Теперь обратим внимание на SRUM Guide с точки зрения договора разработки приложения и материальных интересов Исполнителя и Заказчика. Источник: Руководство по Scrum с официального сайта.

Product Backlog — это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта. Это единственный источник работы, выполняемой Scrum Team. Product Owner несет ответственность за максимизацию ценности продукта, получаемого в результате работы Scrum Team.
…

Product Owner также несет ответственность за эффективное управление Product Backlog, в том числе он:

• разрабатывает и точно коммуницирует Product Goal;
• создает и четко объясняет элементы Product Backlog;
• упорядочивает элементы Product Backlog; а также,
• обеспечивает прозрачность, доступность и понимание Product Backlog.

А вот какое пояснение дает официальный сайт scrum.org на тему Product Owner:

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

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

Рассмотрим несколько вариантов:

1. Product owner сотрудник Исполнителя или нанятый им специалист. То есть вообще вся Scrum team находится под контролем Исполнителя. И вполне возможно, что в таком случае применение SRUM внутреннее дело и инициатива Исполнителя. Тогда возникает разумный вопрос, зачем вообще сообщать Заказчику о работе команды в соответствии с правилами Scrum. Product owner для Заказчика выглядит просто как ответственное за коммуникации лицо Исполнителя. И в этом случае на этом можно ставить точку.

2. Все тоже самое, как и в первом варианте, но Заказчик и Исполнитель согласовали, что и Product owner коммуницирует с Заказчиком в рамках и с применением Scrum, и сами стороны договора также взаимодействуют в рамках Scrum. Это самый плохой и чаще всего применяемый вариант. По сути, Исполнитель декларирует статус Product owner как лица, ответственного за проект и берет на себя ответственность не только за разработку приложения, но и за работу Product owner. То есть одновременно Заказчику оказывается и услуга условно консультации и ведения проекта Product owner, и выполняется разработка приложения. И в таком случае, в отличие от первого варианта, Product owner фактически обслуживает проект как отдельное лицо, имеет право давать некие значимые указания, но при этом за его действия несет ответственность только Исполнитель. Если Product owner «накосячил» или, в крайнем случае, исчез, то все убытки лягут на плечи Исполнителя и ничего с этим он поделать не сможет. Это неотвратимый тупик в отношениях сторон и, если так выразиться, жестоко по отношению к Исполнителю. Это одна из многих причин, почему Scrum критикуют. Как вариант такое взаимодействие можно трансформировать в кейс, когда Заказчик нанимает независимого Product owner по отдельному договору со всей присущей такой работе ответственностью. Или хотя бы заключить отдельное соглашение на предоставление услуги Product owner Заказчику.

3. Product owner – сотрудник, представитель Заказчика. В таком случае начинается самое интересное. Для лучшего понимания предлагаю называть характер отношений Сторон своими именами. А именно: Исполнитель, под управлением Заказчика, обязуется под свою ответственность (ответственность Исполнителя) достичь определенных, согласуемых в процессе исполнения договора целей. Странно, да. При том конечный результат может быть и не достигнут или достигнут в другие сроки или вообще результат может быть другой. В таком случае, если мы и применяем конструкцию ст. 1296 ГК РФ «Произведения, созданные по заказу», то должны в договоре очень четко и подробно оговорить ограничение ответственности Исполнителя в зависимости от действий/бездействий представителя Заказчика в лице Product Owner. Так же, кроме ограничения ответственности необходимо указать и другие немаловажные юридические скучности, которыми не стоит раздувать эту статью. А иначе можно получить такой тупик в отношениях Сторон, из которого выбраться Исполнитель сможет, только приняв всю ответственность за действия Product owner на себя, либо перейти в стадию судебного разбирательства с очень и очень большими судебными издержками.

  Совет

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