Договор на разработку, формирующий правильное взаимодействие заказчика с исполнителем, закрывающий риски и регламентирующий все этапы работы — довольно непростая вещь. Мы строили свой 2 года, собирая обратную связь от клиентов с одной стороны и проектной команды с другой. Стратосфера — веб-интегратор, специализирующийся на е-коммерс, b2b и цифровой трансформации. Соответственно, вся статья дальше будет написана на примере именно веб-разработки.
Малый бизнес часто относится к договору, как к «бумажке» и формальности. От продавца прицепов в регионе вполне можно услышать, что «да что мне ваш договор, главное что я слово сказал».
Большой бизнес наоборот, понимает значение договора, но проверяет его силами штатных юристов, как правило, не разбирающихся в разработке. Для них разработка выглядит примерно как «взять сайт со склада и отгрузить покупателю». Они не понимают сути и триггерятся на знакомые слова вроде «срок», «штраф» итд.
Отдельная категория — те, кто пытается вставить в договор пункты, по которым ты изначально виноват, чтобы потом ими как-либо манипулировать.
Конечно же, все три подхода неверны.
Мы в студии рассматриваем договор на разработку с точки зрения PMBOK.
PMBOK (Project management body of knowledge) — свод знаний по управлению проектами. Он универсален и по сути подходит для чего угодно: от разработки сайта до строительства моста.
С точки зрения PMBOK, договор это документ, который авторизовывает проект, выделяет на него ресурсы, назначает ответственных, определяет правила управления требованиями, рисками, коммуникациями.
Договор устанавливает то, в каком порядке и какими документами регулируются требования к проекту. Требования могут быть сформированы в виде
Как правило, на этапе подписания договора есть лишь часть этого — например только спецификация.
Договор устанавливает, что в рамках него проводится аналитика, создается архитектура проекта, затем на ее основании строится прототип, а далее — техническое задание.
С точки зрения законодательства (Ст 703, пункт 3 ГК РФ), все, что не указано прямо в договоре, делается на усмотрение исполнителя.
Соответственно, требования к проекту должны быть обязательно привязаны к договору, зафиксирован порядок их влияния на исполнение работы.
Правки — отдельная часть требований. С точки зрения подрядной работы, правка это приведение работы в соответствие с ранее согласованными требованиями. Но в дизайне как правило, правки предполагают, что работы выполнена по требованиям, но после выполнения они расширились / изменились (тут перекрасьте, тут поменяйте, а человечка на иллюстрации сделайте менее бородатым). Это — сложившаяся практика и в договоре нужно обязательно фиксировать, сколько итераций таких правок допустимо.
Договор должен регламентировать коммуникации сторон, максимально защищая обе стороны от хаотичных коммуникаций и не зафиксированных обязательств. Например, было бы неразумно собирать всю команду каждый день на совещание, если время на него не зафиксировано и не учтено в оплату.
Важно ограничить количество коммуникаций, чтобы проект не начал потреблять больше ресурсов, чем на него отведено.
Здесь же важно связать коммуникации с требованиями. В какой момент поставленный Тикет становится задачей, которая должна быть выполнена, как это влияет на сроки и стоимость, в каком виде согласовывается.
Договор также фиксирует порядок согласования результатов работы. Например, мы просим подписывать макеты и прототипы, потому что бывают случаи, когда менеджер заказчика согласовал с нами один вариант дизайна, а со своим руководителем — другой.
На проект выделяются ресурсы. В случае с разработкой программного продукта это обычно — время специалиста.
Значит, договор должен фиксировать, сколько времени и каких специалистов будет выделено, как оно фиксируется и что будет при превышении ресурса, в зависимости от причин этого превышения.
Например, слития исполнитель не уложился в определенные трудозатраты по причине неверной оценки, задача доделывается за его счет. А если по причине некорректных данных от заказчика, то за счет заказчика.
В проекте по разработке например, интернет-магазина есть набор рисков, которые обязательно должен фиксировать договор.
Исполнитель не выделил ресурс вовремя и опоздал с выполнением работы.
Это — один из самых простых и понятных рисков. При этом договор определяет, есть ли штрафы и в какой момент они наступают. Также он определяет, при каком опоздании по срокам работа становится неактуальна и уже не оплачивается.
Заказчик не предоставил вовремя нужные для работы материалы
Доступы к сервисам для интеграций, файлы выгрузки из корпоративной ERP итд. При этом «сгорает» время простаивающих сотрудников исполнителя и он несет убытки. Договор определяет порядок действий в этом случае. Например, может взиматься штраф за просрочку, либо задача сдается на демо данных, либо задача исключается из договора и делается отдельно, а проект сдается без нее.
Работа потеряла актуальность и проект должен быть свернут
При этом договор должен регламентировать условия расхождения сторон — доделывают ли они текущий этап и в каком объеме, как и в каком порядке это оплачивается.
Работа выполнена, но заказчик не участвует в сдаче-приемке или не выходит на связь
В этом случае договор регламентирует порядок действий — например, акт отправляется на контактный адрес или посредством ЭДО и отсутствие ответа в положенный срок означает подписание акта.
Проект потерял работоспособность
Договор регламентирует, в каких случаях это — ответственность заказчика, а в каких — исполнителя. Например, ответственностью Исполнителя может не быть
Срок работ попадает на государственные выходные
Разумно если не оговорена работа в выходные, фиксировать срок в рабочих днях.
Предоставленные данные некорректны
Например, Заказчиком предоставлены файлы выгрузки из ERP, Исполнителем они интегрированы в сайт, а Заказчик после этого поменял формат выгружаемых данных.
Договор должен регламентировать в этом случае оплату доп работы, либо сдачу проекта на дело данных.
Коротко выводы
Договор это базовый документ, авторизовывающий проект. Он фиксирует все взаимодействия сторон: от требований до рисков. От того, насколько он хорошо составлен, зависит то, насколько легко пройдет проект и насколько дружественной будет работа заказчика и исполнителя.
Наш договор на разработку
P.S. Чтобы быть в курсе новых публикаций, подписывайтесь на меня в Facebook.
Малый бизнес часто относится к договору, как к «бумажке» и формальности. От продавца прицепов в регионе вполне можно услышать, что «да что мне ваш договор, главное что я слово сказал».
Большой бизнес наоборот, понимает значение договора, но проверяет его силами штатных юристов, как правило, не разбирающихся в разработке. Для них разработка выглядит примерно как «взять сайт со склада и отгрузить покупателю». Они не понимают сути и триггерятся на знакомые слова вроде «срок», «штраф» итд.
Отдельная категория — те, кто пытается вставить в договор пункты, по которым ты изначально виноват, чтобы потом ими как-либо манипулировать.
Конечно же, все три подхода неверны.
Мы в студии рассматриваем договор на разработку с точки зрения PMBOK.
PMBOK (Project management body of knowledge) — свод знаний по управлению проектами. Он универсален и по сути подходит для чего угодно: от разработки сайта до строительства моста.
С точки зрения PMBOK, договор это документ, который авторизовывает проект, выделяет на него ресурсы, назначает ответственных, определяет правила управления требованиями, рисками, коммуникациями.
Управление требованиями
Договор устанавливает то, в каком порядке и какими документами регулируются требования к проекту. Требования могут быть сформированы в виде
- Спецификации
- Архитектуры проекта
- Прототипов
- Технического задания
- Тикетов с дополнительными требованиями, возникающими в процессе
Как правило, на этапе подписания договора есть лишь часть этого — например только спецификация.
Договор устанавливает, что в рамках него проводится аналитика, создается архитектура проекта, затем на ее основании строится прототип, а далее — техническое задание.
С точки зрения законодательства (Ст 703, пункт 3 ГК РФ), все, что не указано прямо в договоре, делается на усмотрение исполнителя.
Соответственно, требования к проекту должны быть обязательно привязаны к договору, зафиксирован порядок их влияния на исполнение работы.
Правки — отдельная часть требований. С точки зрения подрядной работы, правка это приведение работы в соответствие с ранее согласованными требованиями. Но в дизайне как правило, правки предполагают, что работы выполнена по требованиям, но после выполнения они расширились / изменились (тут перекрасьте, тут поменяйте, а человечка на иллюстрации сделайте менее бородатым). Это — сложившаяся практика и в договоре нужно обязательно фиксировать, сколько итераций таких правок допустимо.
Управление коммуникациями
Договор должен регламентировать коммуникации сторон, максимально защищая обе стороны от хаотичных коммуникаций и не зафиксированных обязательств. Например, было бы неразумно собирать всю команду каждый день на совещание, если время на него не зафиксировано и не учтено в оплату.
Что можно фиксировать
- Тикетную систему (адрес, сервис)
- Постановку задач только в рамках тикета
- Оценку задач только на основе информации, содержащейся в тикете
- Обязательный call и meeting репорт в тикет
Важно ограничить количество коммуникаций, чтобы проект не начал потреблять больше ресурсов, чем на него отведено.
Здесь же важно связать коммуникации с требованиями. В какой момент поставленный Тикет становится задачей, которая должна быть выполнена, как это влияет на сроки и стоимость, в каком виде согласовывается.
Договор также фиксирует порядок согласования результатов работы. Например, мы просим подписывать макеты и прототипы, потому что бывают случаи, когда менеджер заказчика согласовал с нами один вариант дизайна, а со своим руководителем — другой.
Управление ресурсами
На проект выделяются ресурсы. В случае с разработкой программного продукта это обычно — время специалиста.
Значит, договор должен фиксировать, сколько времени и каких специалистов будет выделено, как оно фиксируется и что будет при превышении ресурса, в зависимости от причин этого превышения.
Например, слития исполнитель не уложился в определенные трудозатраты по причине неверной оценки, задача доделывается за его счет. А если по причине некорректных данных от заказчика, то за счет заказчика.
Управление рисками
В проекте по разработке например, интернет-магазина есть набор рисков, которые обязательно должен фиксировать договор.
Разберем часть этих рисков.
Исполнитель не выделил ресурс вовремя и опоздал с выполнением работы.
Это — один из самых простых и понятных рисков. При этом договор определяет, есть ли штрафы и в какой момент они наступают. Также он определяет, при каком опоздании по срокам работа становится неактуальна и уже не оплачивается.
Заказчик не предоставил вовремя нужные для работы материалы
Доступы к сервисам для интеграций, файлы выгрузки из корпоративной ERP итд. При этом «сгорает» время простаивающих сотрудников исполнителя и он несет убытки. Договор определяет порядок действий в этом случае. Например, может взиматься штраф за просрочку, либо задача сдается на демо данных, либо задача исключается из договора и делается отдельно, а проект сдается без нее.
Работа потеряла актуальность и проект должен быть свернут
При этом договор должен регламентировать условия расхождения сторон — доделывают ли они текущий этап и в каком объеме, как и в каком порядке это оплачивается.
Работа выполнена, но заказчик не участвует в сдаче-приемке или не выходит на связь
В этом случае договор регламентирует порядок действий — например, акт отправляется на контактный адрес или посредством ЭДО и отсутствие ответа в положенный срок означает подписание акта.
Проект потерял работоспособность
Договор регламентирует, в каких случаях это — ответственность заказчика, а в каких — исполнителя. Например, ответственностью Исполнителя может не быть
- Контент
- Интеграции
- Вмешательство третьих лиц в код
- Смена доступов к сайту
- Авария на хостинге
Срок работ попадает на государственные выходные
Разумно если не оговорена работа в выходные, фиксировать срок в рабочих днях.
Предоставленные данные некорректны
Например, Заказчиком предоставлены файлы выгрузки из ERP, Исполнителем они интегрированы в сайт, а Заказчик после этого поменял формат выгружаемых данных.
Договор должен регламентировать в этом случае оплату доп работы, либо сдачу проекта на дело данных.
Коротко выводы
Договор это базовый документ, авторизовывающий проект. Он фиксирует все взаимодействия сторон: от требований до рисков. От того, насколько он хорошо составлен, зависит то, насколько легко пройдет проект и насколько дружественной будет работа заказчика и исполнителя.Наш договор на разработку
P.S. Чтобы быть в курсе новых публикаций, подписывайтесь на меня в Facebook.
