Бесконечные раунды правок, задержка материалов и доступов, отсутствие оплаты инвойсов. С такими сценариями сталкиваются IT-компании, когда разрабатывают сайты для заказчиков. Избежать их можно с помощью договора на разработку сайту, который написан с точки зрения управления проектами. А именно учитывает условия заказчика и проектной команды - исполнителей.
IT-юристы Stalirov&Co рассказали как составить договор на разработку сайта с юридическим лицом и учесть возможные риски.
5 целей составления документа
- Установить перечень работ: UX/UI дизайн, Front- & back-end разработка, тестирование, бизнес-аналитика, менеджерирование.
- Зафиксировать сроки проекта и дедлайны отдельных спринтов.
- Ограничить количество правок и определить оплату за дополнительные таски.
- Внедрить алгоритм принятия результатов, график оплаты инвойсов и установить санкции за задержку платежей.
- Распределить функции в команде и описать процесс коммуникации.
От того, насколько качественно составлен договор, зависит насколько легко пройдет проект и насколько дружественной будет работа сторон.
Какие пункты включить в договор?
Разберем каждый пункт отдельно.
Предмет договора
В этот разделе должен быть перечень услуг, которые компания предоставляет заказчику: прототипирование и разработка дизайна, проектирование административной панели, верстка, тестирование и другие виды услуг.
Порядок выполнения работ
Ваша задача описать алгоритм сотрудничества. Например, сперва проводится аналитика, создается архитектура проекта, затем разрабатывается прототип, а после утверждается технические задания под каждый спринт.
Отдельные пункты договора стоит посвятить вопросам апрува ТЗ. На стороне заказчика должен быть ответственный сотрудник, который будет вовремя согласовывать новые ТЗ или вносить изменения в текущие.
Советуем определить ответственного и за предоставление материалов. Типичная проблема IT-компаний — задержки в предоставлении информации, контента и доступов. В договоре должен быть пункт, который определит, что делать в таком случае. Например, задача сдается на демо данных.
Коммуникация
Чтобы избежать хаотичных коммуникаций, нужно определить средства и время взаимодействия. Например, для обмена информацией заказчик и подрядчики могут использовать электронную почту, Skype, ZOOM, Slack, Discord; таск-трекеры: Jira, Trello; мессенджеры: WhatsApp, Viber, Telegram и другие инструменты. Коммуникация проводится только в рабочие часы.
Принятие и передача результатов, дебаг
Так же как и с апрувом ТЗ и предоставлением материалов, на стороне заказчика должен быть ответственный за принятие работ. Советуем установить срок, в течение которого представитель заказчика должен дать фидбек: принять работу или запросить правки.
Важно разграничить, что считается ошибкой, и должно быть устранено разработчиком, а что новым таском, по которому будет выставлена дополнительная оплата. Чтобы избежать бесконечного потока итерация, зафиксируйте правило присылать правки единым файлом. Так проще распределить функции в команде и определить дедлайны.
Зафиксируйте как будет происходить передача результатов: доступ через защищенные URL-адреса, размещение в репозитории заказчика с доступом по приглашению.
Выставление инвойса и оплата
Договор должен включат пункт с моделью оплаты (Fixed price или Time&Material) и видом расчетов (предоплата, частичная оплата, постоплата).
Классический вариант — комбинация Time&Material и частичной оплаты. Так IT-компания не рискует работать в минус, как в случае с постоплатой, когда заказчик отказывается оплачивать разработку продукта по заверению всего проекта. А заказчик может приостановить разработку, внести изменения в прототип или бюджет каждого нового спринта.
Дополнительно можно договориться с заказчиком о буфере риска изменения оценки работ. К примеру, стоимость работы команды по первому спринту 5 000$. Но оценка может быть изменена +-20%.
Зафиксируйте в течении какого срока инвойс должен быть оплачен и что будет в случае просрочки. Например, за каждый месяц просрочки применяется коэффициент увеличения +2%.
Такие пункты в договоре гарантируют прозрачность и предсказуемость проекта.
Автор статьи: Валерий Сталиров, CEO компании IT-юристов Stalirov&Co.