Как правильно составить договор на разработку ПО в зависимости от методологии разработки

Привет, я Сергей Монаков – инхаус юрист в IT/IP. В этой статье я расскажу об основных подходах к составлению договоров ГПХ на разработку ПО в зависимости от применяемой методологии разработки и требований к проекту.

В it практике устоялись две основных методологии разработки: каскадная модель (waterfall), и гибкая методология разработки (agile). Вкратце расскажу про каждую из них с позиции юриста-договорника.

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

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

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

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

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

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

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

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

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

Здесь мы можем выделить основные принципы договора по Fixed price при применяемой каскадной модели

При использовании гибкой методологии разработки стороны в договоре применяют подход Time&Material (время и материалы). Суть такого подхода заключается в том, что стоимость разработки калькулируется на основании затраченного времени проектной командой исполнителя, а не на фиксированный результат работ, как в случае с каскадной моделью.

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

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

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

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

Здесь мы можем выделить основные принципы договора по T&M при гибкой методологии разработки

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

Минусы подхода Fixed price довольно очевидны. Он предполагает полную нормированность и бюрократизацию всех процессов проекта и плохо адаптивен под какие-либо изменения, которые довольно часто возникают при разработке цифровых решений. Кроме того, при данном подходе тестирование и эксплуатация проекта происходит на последних этапах его реализации, до этого времени возможные ошибки и проблемы не могут быть выявлены. Ликвидация таких проблем потребует дополнительного проектного бюджета.

Минусы подхода T&M заключаются в неопределенности конечного результата и итоговой стоимости проекта и в потенциальном наличии непонимания и опасений у заказчика в части оплаты (заказчик может опасаться, что он платит не за результат, а за процесс работы).

Существуют несколько решений закрытия потенциальных возражений заказчика при заключении договора на разработку по T&M.

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

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

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

Оба договорных подхода (Fixed price и T&M) не универсальны и рассчитаны на выполнение конкретной задачи. Однако при должном понимании всех исходных принципов и задач проекта, высокого профессионализма и надлежащей добросовестности представителей сторон каждый подход гарантированно даст желаемый результат :)