Договор на разработку, формирующий правильное взаимодействие заказчика с исполнителем, закрывающий риски и регламентирующий все этапы работы — довольно непростая вещь. Мы строили свой 2 года, собирая обратную связь от клиентов с одной стороны и проектной команды с другой. Стратосфера — веб-интегратор, специализирующийся на е-коммерс, b2b и цифровой трансформации. Соответственно, вся статья дальше будет написана на примере именно веб-разработки.

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

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

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

Конечно же, все три подхода неверны.

Мы в студии рассматриваем договор на разработку с точки зрения PMBOK.

PMBOK (Project management body of knowledge) — свод знаний по управлению проектами. Он универсален и по сути подходит для чего угодно: от разработки сайта до строительства моста.

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

Управление требованиями

Договор устанавливает то, в каком порядке и какими документами регулируются требования к проекту. Требования могут быть сформированы в виде

• Спецификации
• Архитектуры проекта
• Прототипов
• Технического задания
• Тикетов с дополнительными требованиями, возникающими в процессе

Как правило, на этапе подписания договора есть лишь часть этого — например только спецификация.

Договор устанавливает, что в рамках него проводится аналитика, создается архитектура проекта, затем на ее основании строится прототип, а далее — техническое задание.

С точки зрения законодательства (Ст 703, пункт 3 ГК РФ), все, что не указано прямо в договоре, делается на усмотрение исполнителя.

Соответственно, требования к проекту должны быть обязательно привязаны к договору, зафиксирован порядок их влияния на исполнение работы.

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

Управление коммуникациями

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

Что можно фиксировать

• Тикетную систему (адрес, сервис)
• Постановку задач только в рамках тикета
• Оценку задач только на основе информации, содержащейся в тикете
• Обязательный call и meeting репорт в тикет

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

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

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

Управление ресурсами

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

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

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

Управление рисками

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

Разберем часть этих рисков.

Исполнитель не выделил ресурс вовремя и опоздал с выполнением работы.

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

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

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

Работа потеряла актуальность и проект должен быть свернут

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

Работа выполнена, но заказчик не участвует в сдаче-приемке или не выходит на связь

В этом случае договор регламентирует порядок действий — например, акт отправляется на контактный адрес или посредством ЭДО и отсутствие ответа в положенный срок означает подписание акта.

Проект потерял работоспособность

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

• Контент
• Интеграции
• Вмешательство третьих лиц в код
• Смена доступов к сайту
• Авария на хостинге

Срок работ попадает на государственные выходные

Разумно если не оговорена работа в выходные, фиксировать срок в рабочих днях.

Предоставленные данные некорректны

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

Коротко выводы

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

Наш договор на разработку


P.S. Чтобы быть в курсе новых публикаций, подписывайтесь на меня в Facebook.