Модель оплаты распределяет риск, а не отменяет его
При Fixed Price подрядчик обещает согласованный результат за фиксированную сумму. Чтобы принять риск неизвестности, он либо требует подробного задания, либо добавляет резерв и жёстко ограничивает изменения. При Time & Material заказчик оплачивает фактическое время команды и получает возможность менять приоритеты, но принимает большую часть бюджетного риска.
Ни одна модель не является признаком честности сама по себе. Непрозрачный T&M может бесконечно расходовать часы, а нереалистичный фикс приводит к спорам о каждой детали. Управляемость создают требования, отчётность, лимиты и регулярная демонстрация результата.
Когда фиксированная цена работает
- Цель и границы первого релиза согласованы.
- Известны шаблоны, компоненты, состояния и объём контента.
- Документация интеграций проверена, есть тестовые доступы.
- Критерии приёмки наблюдаемы и понятны обеим сторонам.
- Вероятность изменений невысока, а согласующие назначены.
Примером является лендинг по утверждённому прототипу: восемь блоков, одна форма, известные поля CRM, готовый бренд-гайд и контент. Подрядчик может оценить дизайн, разработку, QA и запуск с небольшим диапазоном неизвестности.
Когда T&M является более честным выбором
Почасовая модель оправдана, когда команда исследует новый продукт, строит личный кабинет, работает с непроверенным API или развивает действующую систему по данным пользователей. Здесь изменение решения является частью работы, а не нарушением первоначального плана.
Хороший T&M не начинается без прогноза. Заказчик получает ставки ролей, ориентир часов, лимит периода, бэклог, состав ближайшей итерации и правило остановки. Факт сравнивается с прогнозом каждую неделю или спринт, а не после исчерпания бюджета.
Матрица выбора модели
| Условие | Fixed Price | Time & Material |
|---|---|---|
| Требования стабильны | Подходит | Возможен, но гибкость может не использоваться |
| Непроверенная интеграция | Только после обследования или с большим резервом | Подходит с лимитом |
| Нужно менять приоритеты | Потребуются change requests | Подходит |
| Бюджет строго ограничен | Подходит при сокращаемом scope | Подходит с жёстким лимитом и остановкой |
| Критерии результата неизвестны | Риск конфликта | Сначала discovery |
| Нужна точная дата | Возможна при стабильных входных данных | Фиксируется команда и прогноз, scope управляется |
Как выглядит гибридная схема для корпоративного сайта
Этап исследования оценивается по T&M с лимитом 120 часов. За это время команда уточняет аудитории, карту сайта, контентную модель, интеграции, риски и критерии первого релиза. На выходе заказчик получает артефакты, а не только отчёт времени.
После утверждения прототипов дизайн и разработка 10–12 шаблонов фиксируются по цене. Интеграция с непроверенной учётной системой остаётся T&M в отдельном лимите до успешного тестового обмена. Новые идеи попадают в бэклог и либо заменяют равный объём, либо оцениваются отдельной очередью.
- Discovery: до 120 часов, контроль каждые 40 часов.
- Прототипы и дизайн: фикс после утверждения реестра шаблонов.
- Разработка: фикс по критериям плюс отдельный лимит интеграции.
- Контент: цена за согласованный объём или T&M при неизвестном качестве.
- Развитие после запуска: ежемесячный T&M-бэклог с верхним лимитом.
Как контролировать Time & Material
Заказчику не нужно проверять каждую минуту. Ему нужна связь между потраченным временем и результатом. В отчёте показываются задачи, роли, план, факт, остаток прогноза, блокеры и решения. Демонстрация работающего результата проводится регулярно.
- Ставки и минимальная единица учёта известны заранее.
- На неделю или спринт согласован измеримый результат.
- Есть месячный лимит и уведомление, например при расходовании 70%.
- Нельзя начать крупную задачу без оценки и приоритета.
- Заказчик может остановить работу и получить текущие исходники.
- Повторные исправления дефекта не маскируются как развитие.
Полезная метрика точности: отношение факта к прогнозу по завершённым задачам. Один выход за диапазон исследуется по причине, а не компенсируется скрытым урезанием QA.
Как управлять изменениями при фиксированной цене
Базовый scope становится приложением к договору. Когда появляется новая функция, команда оценивает влияние на дизайн, код, данные, QA, SEO и срок. Заказчик выбирает: заменить задачу сопоставимого объёма, увеличить бюджет, перенести идею или отказаться.
Например, после утверждения каталога появляется сравнение товаров. Это не «ещё одна кнопка»: нужны правила выбора, хранение списка, страница сравнения, мобильный режим, пустые состояния и события аналитики. Change request делает последствия видимыми до разработки.
Модельный финансовый сценарий
Компания резервирует 1 100 000 ₽. Discovery проводится по T&M с лимитом 150 000 ₽. По итогам фиксированная часть дизайна и разработки оценена в 820 000 ₽, а интеграционный лимит в 100 000 ₽. Остаётся 30 000 ₽ управленческого резерва на названные риски.
Если обследование закрывает интеграционный риск и фактическая работа стоит 70 000 ₽, остаток не обязан расходоваться. Его можно сохранить или направить на следующий приоритет отдельным решением. Такой подход отличает лимит от авансового обещания потратить всё.
Что должно быть в договоре при любой модели
- Состав результата и критерии приёмки.
- Роли, ставки или фиксированные суммы этапов.
- Порядок отчётности, демонстраций и согласований.
- Процедура изменения требований.
- Правила работы с дефектами и повторной работой.
- Лимиты, уведомления и условия остановки.
- Передача исходников, доступов и промежуточных материалов.
Выбор модели делается после оценки неопределённости. Если подрядчик настаивает на одном формате для любых проектов, попросите объяснить, кто и как оплачивает риск. Ответ покажет больше, чем название договора.