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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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


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

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

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

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

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


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

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

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

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


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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Средняя зарплата в IT

120 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 9 370 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 11

    +1
    Отлично всё расписано! И спасибо за образец!
      0
      Спасибо!)
      +2
      Мне кажется, не хватает:
      1. Передачи всех материалов (исходники + графика) на физическом носителе. Обычно бухгалтерия и юристы предпочитают, особенно в вопросах последующего доказательства исключительных прав, чтобы была твердая копия
      2. Суд в Краснодаре или по месту исполнителя. Я бы не согласился :)
      3. Нет пункта, что все проблемы с предъявлением претензий третих лиц — на Исполнителе.
      4. Использование материалов в портфолио должно быть только с разрешения Заказчика.

      Это при чтении договора по диагонали. Впрочем, договор составлен с точки зрения исполнителя, а не заказчика, поэтому это объяснимо.
        0
        Вы в целом правы.
        1. Передачу на носителе мы не включали потому, что сайт это интеграционный проект, где важен сервер, настройки, доступы. Копия исходника сайта, это не сайт в том смысле, в котором он заказан.
        2. Да, мне больше нравится «по месту нахождения ответчика». Это стимулирует договариваться, а не судиться.
        3. Это да.
        4. Такое разрешение надо сразу писать в договор (если он не под NDA). Договор без права делать кейс должен стоить дороже.

          +1
          По п.4 не согласен. Я, как заказчик, могу быть доволен или не доволен. Если доволен — то с радостью рекомендую подрядчика (нормальных — очень мало, к сожалению, кого искренне хотелось бы рекомендовать). Если не доволен, то буду против размещения в портфолио студии этого проекта. Потому что, условно проект мне ничего не дал, я как заказчик деньги потерял, а кто-то положит в портфолио и будет на этом новых клиентов привлекать, то есть зарабатывать. Узнаю я о своем довольстве/недовольстве только после окончания работ, поэтому включить сразу такой пункт в договор не готов. Но это сугубо мое мнение.

          Мне действительно было интересно посмотреть шаблон договора. Он весьма неплох на фоне других, которые я видел. Но без указанных выше пунктов я бы не стал Вашим клиентом :)
            0
            С другой стороны смысл выкладывать работу заказчика, который недоволен? Ему же позвонят и он все расскажет… Так что в целом норм :-)

            Про место нахождения ответчика согласились бы?
              +1
              Неа :) Был опыт, к сожалению неприятный. Поэтому я очень щепетильно сейчас на такие вещи смотрю.
        +3
        Пост довольно слабо раскрывает тему и во многом противоречит сам себе.
        Вы начинаете с того, что
        мы в студии рассматриваем договор на разработку с точки зрения PMBOK
        а должны, по идее, в первую очередь рассматривать его с точки зрения Гражданского кодекса РФ. Что вы в дальнейшем по тексту и делаете. А вот про PMBoK вообще не вспоминаете.

        С точки зрения PMBOK, договор это документ, который авторизовывает проект, выделяет на него ресурсы, назначает ответственных, определяет правила управления требованиями, рисками, коммуникациями
        PMBoK говорит о договорах только в самом конце — в предпоследней 12 главе. Договоры рассматриваются там как часть процесса управления закупками. А то, что вы написали, это страница 81: «Устав проекта — это документ, выпущенный инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Он документально оформляет высокоуровневую информацию, относящуюся к проекту, продукту, услуге или результату, для получения которых предназначен данный проект». Честно говоря, никогда не понимал, почему люди придают такое значение это крайне ритуальной фразе.
        Но для контекста статьи гораздо важнее утверждение со страницы 77: «Устав проекта устанавливает партнерство между исполняющей организацией и организацией-заказчиком. Для внешних проектов предпочтительным способом заключения соглашения является формальный договор». И вот в этой формулировке заключается разница между нашим обычным пониманием договоров подряда и купли-продажи по ГК (то, за что вы критикуете юристов) и тем, что под уставом проекта понимает PMBoK (стр. 81). В чём-то эти документы пересекаются по содержанию, а в чём-то нет. Частично вы затронули эти моменты в статье, но далеко не полностью.

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

        Куча конфликтов возникает потому, что заказчик руководствуется обычной для себя практикой контрактования по ГК и стремится заключить договор с фиксированной ценой. Хотя содержание проекта при этом определено слабо, требования носят весьма общий характер. И потом начинается натягивание совы на глобус.
          0
          Очень хорошо расписали.
          Вот это особенно близко
          Куча конфликтов возникает потому, что заказчик руководствуется обычной для себя практикой контрактования по ГК и стремится заключить договор с фиксированной ценой. Хотя содержание проекта при этом определено слабо, требования носят весьма общий характер. И потом начинается натягивание совы на глобус.


          Тут я хотел показать, что формально авторизовать проект можно только договором между двумя сторонами (PMBOK не говорит про это, но договор по сути становится уставом проекта, тк сам устав не может регулироваться кодексом), который будет опираться на ГК РФ и выстраивать работу в проекте в соответствии с нормальными практиками.
          +2
          Почитал текст вашего договора. Мне не понравилось.

          1.8. Хостинг — сервер, на котором будет размещен сайт Заказчика, предоставляемый сторонней компанией.
          Казнить нельзя помиловать. В этой фразе сайт заказчика предоставляется сторонней компанией. Чуть лучше так: Хостинг — сервер, предоставляемый сторонней компанией, на котором будет размещен сайт Заказчика.
          Там дальше по договору не понятно когда хостинг должен возникнуть. Кому заказчик оплачивает услуги хостинга? Чья ответственность — обеспечение услуги хостинга?

          Раздел 2 конечно вкусовщина, но вы туда намешали и предмет договора (deliverables, поставляемые результаты) и условия приёмки и оплаты.

          3.2.2 Второй платеж в размере Z () рублей, НДС не предусмотрен, производится в течении 3 (Трех) банковских дней со дня подписания Акта выполненных работ по разработке концепции дизайна сайта и технического задания, на основании счета, выставленного Исполнителем.
          «Концепция дизайна сайта» — что это? У вас этого нет ни в терминах и определениях, ни в предмете договора. Далее возникает утверждение, что это Прототип. К чему такая путаница?

          4.1.2. При подписании акта выполненных работ передать Заказчику все необходимое для дальнейшей самостоятельной работы Заказчика с Интернет-магазином (сайтом), включая логины и пароли доступа хостинга и системы администрирования.
          В разделе 3 у вас перечислено 3 вида актов выполненных работ. И не упоминается ни один акт который просто назывался бы «акт выполненных работ». Он упоминается в п. 4.1.10, но при этом пока не очевидно в какой момент времени он должен возникнуть. И судя по разделу 3 вы получаете полную оплату до возникновения акта выполненных работ — неплохо придумали )

          4.1.3. Своевременно предоставлять Заказчику доступ к результатам работ.
          Своевременно — это когда?

          4.1.5. Обеспечить качество выполняемых работ.
          Классический опасный момент, когда вы имеете в виду под качеством одно, а заказчик может иметь в виду другое. При этом в Терминах и определениях вы не упоминаете значения слова Качество. Например:
          В стандарте ГОСТ 15467-79: совокупность свойств продукции, обусловливающих её пригодность удовлетворять определённые потребности в соответствии с её назначением.
          В стандарте ИСО 8402—86: «Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя».
          В стандарте ГОСТ Р ИСО 9000-2015: «Качество — степень соответствия совокупности присущих характеристик объекта требованиям».

          Обычно в ИТ используется третье значение. И для некоторых это является неприятным сюрпризом.

          4.1.15. Исполнитель не несет ответственности за любые недостатки в работе сайта Заказчика, вызванные причинами, которые находятся вне зоны его контроля (качество каналов доступа в Интернет, качество услуг хостинга, работы, выполняемые на стороне 1С, действия персонала Заказчика, алгоритмы работы поисковых систем, неправомерные действия третьих лиц и т. п.).
          Вы имели в виду некие работы на стороне компании 1С (точнее — конкретного юридического лица)? Какое отношение работы на стороне этого юридического лица имеют к результатам договора? В текущих формулировках договора это ограничение ответственности не понятно. Ну и опять же вкусовщина, но ограничения ответственности сторон обычно выносят в отдельный раздел, который, к тому же, у вас в договоре есть ниже. Дальше у вас тоже интересно. Раздел-то у нас про «Исполнитель обязан», но п. 4.1.17: если надо — получить ещё 30 рабочих дней.

          4.2.5. С предварительным уведомлением Заказчика приостановить выполнение работ в случае несоблюдение порядка и сроков оплаты, предусмотренных п. 3.1 настоящего Договора.
          п. 3.1: «Стоимость работ составляет X () рублей, НДС не предусмотрен». В п. 3.1 ничего нет ни про порядок, ни про сроки оплаты.

          4.3.6. В случае отказа от принятия работ в течение 3 (трех) рабочих дней с момента получения информации о выполнении промежуточных этапов работы предоставить в электронной письменной форме мотивированное обоснование с перечнем недостатков, подлежащих устранению.
          Казнить нельзя помиловать. В 3 дня надо отказаться от приёма работ? Или если отказался от приёма работ, то есть 3 дня на написание отказа?

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

          п. 4.3.10 — вы используете аббревиатуру «ТЗ» — что она означает? Где это сказано?

          Дальшей, извините, надоело смотреть )

            0
            Вы имели в виду некие работы на стороне компании 1С

            Это все же натяжка. Компания 1С называется чуть иначе (как минимум, есть форма собственности, ИНН, ОГРН). И учитывая, что ее нет среди подписавших договор, очевидным становится 1С как наименование программного продукта.

            В остальном спасибо.

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

            Самое читаемое