Agile и право: как заключить юридически грамотный договор
Автор статьи
Введение
Современный бизнес требует от сотрудников постоянного саморазвития и освоения новых навыков. Важно не только углублять знания в своей области, но и расширять их в смежных сферах.
Например, методология Agile, широко применяемая в ИТ для управления проектами, часто неизвестна сотрудникам финансовых, правовых, маркетинговых департаментов. Это снижает эффективность взаимодействия между подразделениями и приводит к ошибкам: неправильному расчету рентабельности, неисполнимым обязательствам по договору, безуспешной стратегии продвижения.
Сегодня методология Agile выходит за рамки ИТ и становится полезной для всех подразделений. В том числе знание Agile может помочь юридическому отделу лучше понимать процессы разработки и составлять договоры, учитывающие больше нюансов проекта, избегая рисков и недоразумений.
Рассказываем о правовых тонкостях Agile, которые помогут заключить юридически грамотный договор.
Подходы к разработке ПО
Agile удобна для управления разработкой программного обеспечения и значительно улучшает гибкость и адаптивность бизнеса в целом.
Agile — это больше, чем инструмент для управления проектами, это способ мышления, который помогает всем подразделениям компании находить общий язык и эффективнее решать задачи.

Введение Agile в процесс разработки продукта подразумевает глубокое понимание динамики процесса юристом так же, как и необходимость адаптировать его инструменты под постоянные изменения.
Те договоры, которые способны гибко учитывать корректировки и новые требования, становятся основой успешного взаимодействия между разработчиками и заказчиками.
Создание программного обеспечения включает в себя множество нюансов как в юридических, так и в технических смыслах.
Из статьи 1261 Гражданского кодекса РФ, следует, что авторские права на ПО охраняются так же, как и авторские права на произведения литературы. По определению программа состоит из четырех элементов:
- Исходный код (в законе используется «исходный текст»)
- Объектный код
- Подготовительные материалы
- Порождаемые программой аудиовизуальные отображения
Само определение такого объекта интеллектуальной собственности, как программа для ЭВМ, уже говорит о ее специфичности, не говоря об изначальной специфике интеллектуальных прав в целом.
Поэтому договоры, касающиеся прав на программные продукты, имеют своеобразные конструкции, свойственные только этим объектам интеллектуальных прав.
Создавая программное обеспечение, бизнес выбирает между двумя основными подходами:
-
Разработка по трудовому договору
Программу создают сотрудники компании и она будет квалифицироваться как служебное произведение в соответствии со статьей 1295 Гражданского кодекса РФ при условии соблюдений определенных законом требований.
-
Создание на заказ
Произведение создается посредством авторского заказа (статья 1288 Гражданского кодекса РФ) или в соответствии с нормами статьи 1296 Гражданского кодекса РФ «Произведения, созданные по заказу».
В условиях современных бизнес-реалий, где кастомизация и инновации играют ключевую роль, второй подход становится особенно востребованным. Рынок разработки ПО активно растет, однако процесс создания продуктов требует особого внимания к юридическим аспектам, особенно в отношении согласования условий договора и взаимодействия сторон по вопросам функциональности, сроков и бюджета.
Цена конечного продукта может меняться на протяжении всего процесса, и, если программа задержится с выходом в релиз, она может потерять свою актуальность и конкурентоспособность.

Часто проблемы разработки проявляются в превышении сроков и перерасходе бюджета, а также в несоответствии полученного продукта ожиданиям заказчика. Ключевыми шагами к минимизации рисков являются:
Выбор методологи процесса
↓
Согласование основных условий и способов взаимодействия между заказчиком и исполнителем
↓
Определение сроков и способов оплаты
↓
Составление текста договора
И здесь на сцену выходит Agile — методология, которая предлагает гибкость и адаптивность, необходимые для успешного создания программного обеспечения.
Agile в юридических реалиях
Agile – это эффективные методы ведения проектов, суть которых заключается в гибком подходе к изменениям, возникающим в процессе долгосрочного создания программного продукта.
Ценность планирования невозможно переоценить, но при этом «планы» не равно «планирование». Эта разница создает сложности в юридическом оформлении процесса разработки.
Планы – это четкие формулировки и статика, которые легко ложатся в конструкцию любого договора, а вот планирование – процесс динамичный, подлежащий корректировкам. Для компаний планирование жизненно необходимо.

Agile позволяет приближаться к ответу на вопрос «Что мы создаем?» и к продукту, соответствующему ожиданиям. Методология подразумевает, что продукт совершенствуется и предоставляется заказчику с каждой новой итерацией через пользовательские истории.
Этот процесс повторяется множество раз, что представляется проблемой для юриста. Когда результат подлежит постоянному изменению, затруднительно прописать его критерии в тексте документов.
Юрист должен понимать, что в рамках Agile создается минимально жизнеспособный продукт, который постоянно корректируется через спринты, где в оговоренные сроки выявляются и реализуются необходимые изменения.
Для успешного составления договора необходимо четко отразить в соглашении:
-
Роли всех участников, включая «владельца продукта», который согласует и визирует предложенные улучшения;
-
Платформу, которая выбрана для целей взаимодействия;
-
Основные условия и способы взаимодействия между заказчиком и исполнителем;
-
Структуру взаимодействия по созданию продукта и ответственных лиц;
-
Процедуры утверждения изменений и их влияние на бюджет и сроки.
Говорить о каком-либо эталонном виде договора не приходится, так как процесс гибкий и на самом старте имеет ряд неопределенностей. Это создает вызов для юристов, требующий креативного подхода и тесной коммуникации с командой разработки.
Рекомендации для составления договора
Важным шагом является создание глоссария, который поможет закрепить термины и определения, используемые в соглашении, что предотвратит неправильную трактовку.
Пример части глоссария:
- Спринт
Итерация, в ходе которой добавляется функциональность программного обеспечения. Обычно длится от 1 до 4 недель. - Project backlog (бэклог)
Список функциональных и нефункциональных требований, который формируется в процессе создания продукта. Также называется пользовательскими историями (user stories) или элементами бэклога (backlog items). - MVP (минимально жизнеспособный продукт)
«Сырой» продукт, обладающий минимальными свойствами, необходимыми для начала работы с программным обеспечением. - Владелец продукта
Лицо, ответственное за согласование финальных и промежуточных продуктов, улучшений и изменений.
Важно интегрировать информацию о спринтах в договор, включая их продолжительность и способы фиксации достигнутых функций. Необходимо четко отразить в документе информацию о владельце продукта, который контролирует изменения, требования к продукту и бюджет. Это, в свою очередь, требует точного определения его полномочий.
В договоре следует подробно описать структуру взаимодействия по созданию продукта и указать ответственных лиц. Необходимо определить, как будут утверждаться изменения по требованиям к продукту и его цене.
В процессе создания программы предлагаются такие идеи, которые не попадают в финальный продукт. Чтобы избежать недопонимая и ошибочного включения неутвержденной функциональности, важно знать, кто и в какие сроки утверждает изменения.
При составлении договора на разработку программного обеспечения юрист должен учитывать интересы бизнеса, и поэтому должен знать специфику современных методик, таких как Agile.
Важно четко фиксировать ключевые понятия, роли участников и детали процесса, чтобы минимизировать риски и избежать неопределенности. Особое внимание следует уделять динамическому характеру разработки, когда требования и итоговый продукт могут меняться в процессе.
Успешный договор отражает гибкость подхода и обеспечивает ясные механизмы взаимодействия между командой и заказчиком, что в конечном счете приводит к согласию по всем аспектам сделки.