Договор на разработку сайта с точки зрения управления проектами (теория + образец)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Договор должен регламентировать в этом случае оплату доп работы, либо сдачу проекта на демо данных.

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

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