Русский
Русский
English
Статистика
Реклама

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

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


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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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


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

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


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


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

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

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

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


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

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

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

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


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

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



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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


P.S. Чтобы быть в курсе новых публикаций, подписывайтесь на меня вFacebook.
Источник: habr.com
К списку статей
Опубликовано: 14.06.2020 12:18:17
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Разработка веб-сайтов

Разработка сайтов

Договор

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

Pmbok

Категории

Последние комментарии

© 2006-2020, personeltest.ru