7 пунктов, которые должны быть в IT-договоре

Когда проект превращается в спор, все открывают договор. И обычно именно в этот момент выясняется, что нужного пункта в нём нет.

IT-договор — не сложный документ. Но в нём есть семь пунктов, без которых любые переговоры упираются во фразу «мы это понимали иначе».

Ниже эти семь. К каждому — зачем он нужен и что происходит, если его нет.

1. Объём работ письменным приложением

Если в договоре написано «разработка программного обеспечения», это не значит ничего. Объём работ должен быть отдельным приложением, и в договоре должно быть указано, что оно является его неотъемлемой частью.

Что в приложении: перечень модулей, экраны, интеграции с названиями, роли пользователей и то, что в объём не входит.

Если пункта нет: каждое новое требование превращается в спор «это же входило». Это причина номер один при затягивании проектов.

2. Порядок изменений

Даже если объём зафиксирован в начале, жизнь меняется. Важно, как именно оформляется изменение.

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

Если пункта нет: устные просьбы накапливаются. В конце исполнитель говорит «этого не было в объёме», вы говорите «я же просил». И оба правы.

3. Критерии приёмки

Самый забываемый пункт и самый проблемный.

В нём должно быть написано: как исполнитель сообщает о сдаче работы, за сколько дней вы отвечаете и что происходит, если вы не отвечаете в этот срок.

Рабочая формула: заказчик в течение 5 рабочих дней принимает работу либо направляет обоснованные письменные возражения. Если ответа нет, работа считается принятой.

Если пункта нет: проект месяцами стоит в состоянии «мы смотрим». Исполнитель не получает оплату, вы не пользуетесь системой. Проигрывают оба.

4. Права на код и данные

Одна фраза, но без неё вы оказываетесь привязаны.

Должно быть написано: после полной оплаты исходный код, документация и база данных переходят к заказчику.

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

Если пункта нет: вы не сможете сменить команду. За каждым мелким изменением придётся возвращаться в одно место по той цене, которую там назовут.

5. Гарантийный период

Срок и его границы должны быть определены чётко.

Что гарантия покрывает: работу, не соответствующую требованиям из объёма работ, то есть технические дефекты. Что не покрывает: запросы на новые функции, сбои из-за изменений, внесённых вами или третьими лицами, перебои сторонних сервисов.

Рабочие сроки: на небольшом проекте месяц, на среднем два, на системе предприятия три.

Если пункта нет: каждая ошибка превращается в переговоры «это по гарантии или новая работа».

6. Ограничение ответственности

Этот пункт защищает исполнителя, и поэтому многие заказчики против него. Но он нужен и вам.

Стандартная формула: ответственность исполнителя ограничивается фактически оплаченной по договору суммой. Косвенный ущерб и упущенная выгода не покрываются.

Почему это нужно и вам: неограниченную ответственность не примет ни одна здоровая команда. А те, кто примет, либо заложат это в цену, либо просто не обратят внимания — оба варианта вам невыгодны.

Вместо этого обратите внимание на пункт о пенях: за каждый день просрочки 0,1% от стоимости договора, но не более 10% суммарно. Это работающий механизм.

7. Условия расторжения

Об этом никто не любит думать, но пункт нужен.

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

Если пункта нет: расставание уходит в суд. Обе стороны теряют время и деньги, а система остаётся в половинчатом состоянии.

Семь пунктов одним взглядом

Обязанности заказчика — восьмой пункт

Этот пункт запрашивает исполнитель, и он справедлив.

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

Если это не выполняется, срок сдвигается соразмерно и это не считается виной исполнителя.

Пункт выглядит направленным против вас, но на деле ускоряет проект — потому что определяет внутреннюю ответственность.

Проверка перед подписанием

• Объём работ оформлен отдельным приложением и назван неотъемлемой частью
• Порядок изменений описан: письменный запрос, срок оценки, согласование
• Есть критерии приёмки и срок для ответа
• Прописан переход прав на код и базу данных после оплаты
• Определён гарантийный период и его границы
• Механизм пеней установлен для обеих сторон
• Есть порядок расторжения и способ расчёта
• Ваши обязанности тоже прописаны

Шесть из восьми — договор рабочий. Меньше четырёх — не подписывайте.

Нужен ли юрист

Да, но один раз.

Хорошая практика такая: один раз составляется шаблон с юристом, дальше он используется годами. В каждом проекте меняются только приложение с объёмом работ и сумма.

Написанное в этой статье не является юридической консультацией — это места, где на практике чаще всего возникают споры. Юрист приведёт их в соответствие с законодательством Узбекистана.

Итог

Договор — не признак недоверия. Он фиксирует, чего ждёт каждая сторона, и именно это предотвращает споры.

Практические шаги:

1. Выпишите семь пунктов и проверяйте по ним каждый договор
2. Не подписывайте договор без объёма работ — это главная ошибка
3. Обязательно добейтесь включения критериев приёмки, их часто нет
4. Закройте вопрос прав на код одной фразой
5. Один раз составьте шаблон с юристом и переиспользуйте его