Если Fixed Price, то только такой: особенности и нюансы

На первый взгляд контракт Fixed Price кажется простым и понятным: четкое ТЗ, определенные заранее размеры и сроки оплаты. В то же время заказчики всегда стараются добавить в него какие-то свои положения или наоборот не спешат включать те, которые защищают и IT компании тоже. Собрали для вас определяющие признаки и нюансы контрактов Fixed Price. Зная их, вы сохраните свои деньги, время, энергию, команду и не зафейлите дедлайны.

Определяющие признаки контракта Fixed Price

Считается, что Fixed Price удобен для небольших проектов. Хотя IT компании с настроенными бизнес-процессами и пониманием, как расходуется их время, успешно реализуют и более масштабные проекты по этой модели. В ней, как минимум, рейт выше, чем в той же Time and Material, за счет включения в него рисков, связанных с возможными изменениями, дополнительным временем на согласование задач и т.д.

Итак, если решили работать с заказчиком по контракту Fixed Price, то в нем обязательно должны быть:

• Четкое и подробно сформулировано техническое задание. Обязательно фиксируются все критерии качества, которым должен соответсовать созданный вами продукт. Например: «на стартовой странице должна быть кнопка регистрации синего цвета, ширина — 2 см, длина — 5. Переход на форму регистрации должно происходить не более чем за 2 секунды» и т.д. Никакой неопределенности — за нее вам придется отвечать собственным временем и финансами.

• Срок завершения проекта. Весь период работ может быть разбит на спринты (или майлстоуны) с определенными датами. Для них важно прописывать контрольные точки: определять, что именно по завершению каждого спринта должно быть сделано.

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

• Определено, каким будет этап принятия работ: конечный и по каждому спринту, если они есть. Юридически это могут быть акты приема-передачи или подтверждение принятия работ по имейлу. Для второго случая стоит прямо в договоре указать официальные имейлы сторон. Когда заказчик принимает работу, с его официального ящика на официальную почту разработчика должно поступить электронное письмо с подтверждением, что, условно “работы по спринту 3 приняты”.

• Понятные процедуры устранения недостатков или внесения изменений вне ТЗ. Часто возникают ситуации, когда все задачи по ТЗ выполнены, но продукт не соответствует видению или бизнес-целям заказчика. Тогда он может попросить вас что-то изменить или добавить. Договор Fixed Price однозначно должен фиксировать, что все, что не соответствует ТЗ в готовом продукте, вы переделываете в рамках существующего бюджета, а все, что не было предусмотрено ТЗ — за дополнительную плату.

Мы в Tretten Lawyers уверены, что права разработчика должны быть защищены не меньше, чем права заказчика. Поэтому разрабатываем и помогаем согласовать договоры, которыми довольны все стороны. Хотите поговорить об этом с нашим юристом — переходите по ссылке.

Нюансы договора, на которые стоит обратить внимание до подписания

Перечисленные ниже детали могут «пробраться» и в другие контракты, не только в Fixed Price. Выбрав эту модель для работы с заказчиком, следите за ними особенно внимательно.

1. Фраза в тексте контракта «Конечный продукт должен удовлетворять разумным требованиям к подобным продуктам на рынке». Это опасное для разработчиков положение позволяет заказчику о чем угодно говорить «это не то, не отвечает требованиям, не будем оплачивать». Ведь по сути не существует никаких «разумных требований» — под эти слова можно притянуть что угодно. Увидите эту фразу в договоре — настаивайте на четких формулировках относительно качественных признаков продукта.

2. Положение о том, что право интеллектуальной собственности на продукт в момент его создания переходит к заказчику. Оно защищает интересы заказчика и ограничивает возможности для вас. Мы советуем документально фиксировать прямо противоположное: “право интеллектуальной собственности на продукт переходит к заказчику после окончательных расчетов по настоящему договору”. Так вы оставите себе хотя бы какой-то рычаг влияния на заказчика, если он нарушит договоренности по оплате работы.

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

3. Условие в контракте, по которому вы должны гарантировать абсолютную чистоту прав интеллектуальной собственности. С одной стороны, это требование справедливо — заказчик хочет получить уникальный продукт. Но с другой — чтобы вы могли по-честному это гарантировать, для каждой части кода нужно проводить глобальную экспертизу. А это — привлечение экспертов, немало дополнительного времени и денег. И все равно гарантировать 100% уникальности кода — нереально. В любой момент кто-то может изобрести то же что и вы, и запатентовать его. Мы советуем объяснить это заказчику и настаивать исключить данное положение.

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

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

Предложите заказчику убрать эти требования по договору в целом. Если не удастся, договаривайтесь о максимальном уточнении требований к неконкуренции. Это может быть список прямых конкурентов компании-заказчика, с которыми вы не имеете права работать определенное время. Или, например, не разрабатывать мобильные приложения того же направления, что и для них и т.д. Рассматривайте каждое требование отдельно с точки зрения того, как сильно оно ограничит вас в будущем.

Или привлекайте нас к переговорам с заказчиком — поможем отстоять ваши бизнес-интересы. Детали по ссылке. 

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

• запрет на такие действия (переманивание людей из вашей команды),
• весомые штрафные санкции (50 тыс евро и более) для контрагента, если это произошло.

Эти пункты ожидаемо вызывают недовольство заказчика: почему суммы такие большие? Но если он не планирует хантить ваших людей, то они и никакой угрозы ему не будут нести. Советуем это прямо обсудить. Так вы поймете, насколько добрые намерения у вашего потенциального контрагента.
И последний, ​​но очень важный совет. Не относитесь к контракту как к формальности и внимательно вычитывайте каждое его положение. Контракт с заказчиком — это «правила дорожного движения», которые защитят вас в случае конфликта или других кризисов в отношениях. Нужна помощь в работе с контрактами и договорами — переходите по ссылке, поможем — чтобы ваши дела были в порядке.