Что нужно обязательно прописать в контракте на Fix Price?

Ключевые элементы контракта на Fixed Price для IT-проекта

Работа по модели Fixed Price (фиксированная цена) требует максимально детализированного и однозначного контракта, чтобы защитить интересы как заказчика, так и исполнителя. Основная задача — минимизировать риски размытия требований и возникновения споров о «хотелках». Вот обязательные пункты, которые я всегда включаю в договор, основываясь на своём опыте.

1. Детальное описание предмета договора и объёма работ (Scope of Work, SOW)

Это ядро контракта. Раздел должен быть настолько подробным, чтобы исключить двойные толкования.

• Техническое задание (ТЗ): ТЗ является неотъемлемым приложением к договору. В самом договоре должна быть явная ссылка на это.
• Исключения (Exclusions): Четкий список того, что НЕ входит в проект. Например: «Не включает интеграцию с CRM-системой X, хостинг на мощностях заказчика, создание контента».
• Список и версии технологий: Указание стека технологий, языков программирования, фреймворков и их конкретных версий.
• Критерии приемки (Acceptance Criteria): Формализованные условия, при которых работа считается принятой.

### Пример структуры приложения "Техническое задание":
1.  **Цели и бизнес-требования.**
2.  **Функциональные требования (User Stories с критериями приемки).**
3.  **Нефункциональные требования:**
    *   Производительность (время отклика < 2 сек. при N пользователей).
    *   Совместимость (браузеры, мобильные ОС).
    *   Безопасность (SSL, хеширование паролей).
4.  **Дизайн-макеты и гайдлайны** (приложение Figma, ссылка на облако).
5.  **Описание API** (форматы запросов/ответов, endpoints).

2. Четкий план проекта и этапы (Milestones)

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

• График платежей: Прямая привязка выплат к завершению и подписанию акта сдачи-приемки по каждому этапу. Например: 20% аванс, 30% после сдачи бэкенда, 50% после полной приемки.
• Даты завершения этапов: Календарные даты или периоды (рабочие дни).
• Процедура сдачи-приемки: Сроки и порядок тестирования заказчиком, формат обратной связи, процедура устранения дефектов.

3. Порядок внесения изменений (Change Control Process)

Самый критичный раздел. Он регулирует неизбежные изменения в проекте.

• Формальный запрос на изменение (Change Request, CR): Обязательное условие. Любое устное пожелание не является основанием для работы.
• Оценка воздействия: В CR исполнитель обязан предоставить оценку изменений по срокам и бюджету.
• Процедура согласования: Изменения вступают в силу только после подписания допсоглашения к договору обеими сторонами.

4. Гарантийные обязательства и ответственность

• Срок гарантии: Период (например, 3-6 месяцев после сдачи), в течение которого исполнитель бесплатно исправляет критичные баги, обнаруженные в сданном в соответствии с ТЗ продукте.
• Ограничение гарантии: Гарантия не распространяется на проблемы, вызванные изменениями со стороны заказчика, использованием неоговоренного ПО или некорректной эксплуатацией.
• Штрафные санкции: Прописываются за просрочку ключевых этапов (например, 0.1% от стоимости этапа за день просрочки, но не более 10%). Важно: Санкции должны быть двусторонними (например, для заказчика — за задержку оплаты или предоставления данных).

5. Прочие обязательные пункты

• Конфиденциальность (NDA): Уже может быть отдельным соглашением, но часто включается и в контракт.
• Права на интеллектуальную собственность (IP Rights): Четкое указание, что права на исходный код и продукт переходят к заказчику после полной оплаты по договору. До этого момента код остается у исполнителя (или на условном эскроу).
• Условия расторжения: Порядок и последствия досрочного прекращения договора по инициативе любой из сторон, включая расчеты за выполненную работу.
• Разрешение споров: Предпочтительный метод (переговоры, медиация) и подсудность (например, арбитражный суд по месту нахождения исполнителя).

Блок управления рисками в виде списка:

• Форс-мажор: Современная трактовка, включающая пандемии, кибератаки на инфраструктуру.
• Обмен информацией и доступ: Указание ответственных лиц с обеих сторон (Project Manager, Product Owner), их права на принятие решений, сроки реакции на запросы. Обязанность заказчика предоставить доступ к необходимым системам/API.
• Статус-отчеты: Регулярность и формат отчетности (еженедельные встречи, отчет в Jira/Confluence).

Итог: Контракт на Fixed Price — это не просто документ о цене и сроках. Это детальная инструкция по управлению проектом и инструмент управления ожиданиями. Его цель — перевести все неопределенности в плоскость формальных процедур, чтобы обе стороны могли сосредоточиться на результате, а не на конфликтах. Чем более проработан контракт на старте, тем выше шансы на успешное и спокойное завершение проекта.