При работе над проектами автоматизации на базе 1С:Предприятие одной из самых сложных задач является выбор правильной юридической и финансовой модели взаимодействия. Большинство ИТ-компаний (франчайзи) предпочитают «рамочные» договоры с почасовой оплатой (Time & Materials), однако для заказчика зачастую прозрачнее и безопаснее выглядит модель Fixed Price (фиксированная цена). В этой статье мы разберем, как составить грамотную «рыбу» договора, которая защитит интересы обеих сторон и позволит избежать бесконечных споров на этапе приемки работ.
Первое, с чем нам необходимо определиться — это квалификация договора согласно Гражданскому кодексу РФ. Зачастую стороны по ошибке используют типовой договор оказания услуг. Рассмотрим, почему для фиксированной цены это может быть ошибкой:
1С с фиксированной стоимостью. В подряде результат должен соответствовать критериям, описанным в Техническом задании.Проанализируем ситуацию: если мы хотим получить конкретный функционал за конкретные деньги, мы должны прописывать в предмете договора «выполнение работ по разработке/модернизации системы», а не просто «консультационные услуги».
Разберем по шагам, как правильно оформить Приложение №1 (ТЗ), чтобы оно не стало причиной конфликтов. Как отмечают эксперты, фраза «сделать как в старой программе» или «настроить учет» — это прямой путь в суд. Посмотрим, что должно содержать качественное ТЗ:
1С v8.3 (Управляемые формы)), требования к серверному оборудованию.Важно помнить: для проектов с фиксированной ценой ТЗ должно быть максимально детализированным. Если в ТЗ не указано, что кнопка должна быть красной, исполнитель имеет право сделать ее синей, и формально он будет прав.
Одной из главных проблем модели Fixed Price является так называемое «раздувание границ проекта». Выясним причину: в процессе разработки заказчик понимает, что ему нужны дополнительные поля или отчеты. Чтобы проект не превратился в «кабалу» для внедренца и не сорвал сроки для заказчика, внедрим в договор регламент изменений:
Рассмотрим пример формулировки: «Любые отклонения от утвержденного ТЗ фиксируются сторонами в письменном виде через Протокол изменений. Исполнитель оценивает влияние изменения на стоимость и сроки, а заказчик подтверждает готовность к оплате доп. работ».
Это дисциплинирует заказчика и не позволяет «навешивать» на программиста задачи, которые не входили в первоначальную смету.
Зачастую внедренцы сталкиваются с тем, что работа выполнена, но заказчик «не находит времени» подписать акт, затягивая оплату. Разберем, как защититься от этого. Включим в договор пункт об автоматическом признании работ выполненными:
Важный момент: «Заказчик обязан в течение 5 (пяти) рабочих дней с момента получения Акта сдачи-приемки и результата работ подписать его либо направить мотивированный письменный отказ. В случае, если в указанный срок отказ не получен, работы считаются принятыми в полном объеме и подлежат оплате».
Такой пункт резко повышает мотивацию заказчика вовремя тестировать систему.
Поскольку программист 1С работает с «ядром» бизнеса, вопрос защиты данных стоит крайне остро. Проанализируем необходимые пункты:
Выясним, как отличить «ошибку» от «нового пожелания». В грамотном договоре должен быть прописан гарантийный срок (обычно от 1 до 6 месяцев). В течение этого срока исполнитель бесплатно устраняет несоответствия кода принятому ТЗ. Если же заказчик хочет изменить логику, которая была описана в ТЗ и уже реализована — это платная доработка.
Для модели с фиксированной ценой мы рекомендуем использовать систему Milestones (вех/этапов). Рассмотрим оптимальную схему:
Такая структура распределяет риски: исполнитель уверен в оплате, а заказчик не платит всю сумму за «кота в мешке».
Если вам навязывают типовую «рамочную» форму на обслуживание, попробуйте следующее: вместо создания нового огромного документа, предложите оформить конкретную работу как Дополнительное соглашение к их договору, но с жестко прописанным результатом и фиксированной ценой за весь объем (а не за часы). В этом случае предмет договора в Доп. соглашении будет выглядеть примерно так:
Предмет Соглашения:
Исполнитель обязуется выполнить работы по разработке
подсистемы «Учет ГСМ» согласно Техническому заданию (Приложение №1),
а Заказчик обязуется принять и оплатить результат в размере 100 000 руб.
Срок выполнения: 20 рабочих дней.
Подводя итог, отметим: красивый и грамотный договор — это не тот, где много юридических терминов, а тот, где четко прописано, кто, что, когда и за сколько должен сделать. Использование модели подряда с детальным ТЗ и механизмом контроля изменений позволит вам успешно завершить проект внедрения 1С без лишних нервов и судебных разбирательств.