Как разбить оплату IT-проекта на этапы
Практика3 минРедакция Innovialabs
Коротко
Надежная схема — небольшая предоплата на старт, затем платежи за каждый этап после приемки конкретного результата по заранее согласованным критериям. Так ни заказчик, ни исполнитель не несут риск всего проекта сразу.
Короткий ответ
Оплату IT-проекта лучше делить так, чтобы каждый платеж соответствовал проверяемому результату. Типичная схема:
- Предоплата — чтобы исполнитель зарезервировал команду и начал работу.
- Платежи по этапам — после приемки дизайна, отдельных модулей, тестовой версии.
- Финальный платеж — после запуска и периода исправления ошибок.
Конкретные доли зависят от размера проекта, длительности и доверия между сторонами, поэтому их согласуют в договоре.
Три основные модели оплаты
| Модель | Как работает | Кому выгоднее | Риск |
|---|---|---|---|
| Полная предоплата | Оплата до начала работ | Исполнителю | Заказчик рискует всей суммой |
| Оплата по этапам | Платеж после каждого этапа | Обеим сторонам | Распределен по проекту |
| Оплата по факту | Вся сумма после сдачи проекта | Заказчику | Исполнитель финансирует проект сам |
Для проектов длиннее пары недель чаще всего выбирают оплату по этапам: она снижает риск для обеих сторон и держит проект в ритме.
Отдельный вариант — оплата за время (time & materials): заказчик платит за фактически потраченные часы, например раз в месяц или раз в спринт. Подходит, когда объем сложно определить заранее. Тогда этапы — это отчетные периоды, а контроль идет через отчеты и демо.
Как привязать платежи к результатам
Главное правило: этап должен заканчиваться чем-то, что можно посмотреть и проверить, а не «выполнено 50% работ».
Хорошие результаты этапа:
- утвержденные макеты ключевых экранов;
- работающая функция в тестовой среде: регистрация, каталог, оплата;
- тестовая версия приложения, установленная на ваш телефон;
- перенесенные данные, проверенные на выборке;
- запуск в продакшн.
Для каждого этапа в договоре или приложении к нему пропишите:
- что сдается — список результатов;
- критерии приемки — по каким признакам результат считается готовым;
- срок проверки — сколько дней у заказчика на приемку;
- что происходит при замечаниях — сроки их исправления;
- сумму платежа.
Пример структуры этапов
Условный пример для веб-сервиса средней сложности:
| Этап | Результат | Платеж |
|---|---|---|
| Старт | Подписан договор, согласовано ТЗ | Предоплата |
| Дизайн | Утверждены макеты ключевых экранов | Платеж 2 |
| Разработка, часть 1 | Основные функции работают в тестовой среде | Платеж 3 |
| Разработка, часть 2 | Все функции, интеграции, админка | Платеж 4 |
| Запуск | Сервис опубликован, период исправления ошибок пройден | Финальный платеж |
Количество этапов подбирают под проект: слишком мелкие этапы создают лишнюю бюрократию, слишком крупные возвращают риск.
Баланс рисков
Риски заказчика: заплатить и не получить результат, получить не то, что ожидал.
Риски исполнителя: выполнить работу и долго ждать оплату, бесконечные правки без оплаты.
Что помогает обеим сторонам:
- Срок приемки. Если заказчик не прислал замечаний в оговоренный срок, этап считается принятым. Это защищает исполнителя от зависания.
- Ограничение правок. Число итераций правок на этапе фиксируется; новые пожелания оформляются как изменение объема.
- Порядок изменения объема. Новые задачи оцениваются отдельно и добавляются в план с отдельной оплатой.
- Передача результатов. Исходный код и права передаются по мере оплаты этапов или после финального платежа — это стоит прописать явно.
- Гарантийный период. После запуска исполнитель бесплатно исправляет ошибки в рамках согласованного функционала в течение оговоренного срока.
Частые ошибки
- Этапы без критериев приемки — непонятно, за что платить.
- Финальный платеж слишком маленький — у исполнителя нет стимула закрыть хвосты.
- Нет срока на проверку — приемка затягивается на недели.
- Правки и новые пожелания смешаны в одном списке.
- Устные договоренности об этапах без записи в договоре.