Fixed price или Time & Material: как платить за разработку

Модель оплаты подрядчику выбирают на первой встрече, а последствия видны через полгода. Fixed price обещает понятный бюджет, time & material (T&M, «время и материалы») — гибкость и оплату только за реально сделанное. На практике проигрывают обе, если модель не подходит проекту: фикс превращается в споры о том, что входило в ТЗ, а T&M — в счёт, который растёт каждый месяц. Разбираем, кто в какой модели несёт риск, откуда в фиксированной цене берётся запас, как держать под контролем почасовую оплату и как это оформить по ГК РФ.

Fixed price и time & material: суть двух моделей

Fixed price (FP, фиксированная цена) — до старта стороны согласуют объём работ, срок и итоговую сумму. Подрядчик обязуется сдать оговорённый результат за эти деньги, даже если потратит больше часов, чем планировал. Любое изменение объёма оформляется отдельной оценкой и допсоглашением.

Time & material (T&M) — заказчик платит за фактически отработанные часы по согласованной ставке плюс прямые расходы (лицензии, серверы, платные API). Объём работ не фиксируется жёстко: приоритеты можно менять хоть каждую неделю, а итоговая сумма складывается из отчётов.

Между этими полюсами есть гибридные модели, и в заказной разработке они встречаются чаще «чистых»: фикс на этап, T&M с потолком бюджета, ретейнер — ежемесячный пакет часов.

Сравнение FP, T&M и гибридов: кто несёт риск

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

Как на самом деле считают fixed price: буфер на риски

Фиксированная цена — это не «стоимость работ», а стоимость работ плюс страховка подрядчика. Процесс обычно такой:

1. Проект раскладывают на задачи (декомпозиция) и оценивают каждую в часах — часто в виде вилки «оптимистично / реалистично / пессимистично».
2. Добавляют работы, которые не видны в ТЗ: менеджмент, тестирование, код-ревью, развёртывание, исправления после приёмки.
3. Закладывают буфер на неизвестное: ошибки в оценке, недокументированное поведение интеграций, правки в пределах «того же самого».
4. Умножают на ставку — и получают цену в договоре.

Размер буфера зависит от того, насколько проработано задание. Это рыночный ориентир, а не норма: при детальном ТЗ с прототипом закладывают около 15–25%, при описании на пару страниц — 30–50%, а по задачам вида «сделайте как у конкурента» опытные подрядчики либо закладывают больше, либо отказываются от фикса вовсе.

Отсюда главный способ удешевить фикс: снять неопределённость до оценки. Платная аналитика и прототип стоят несколько процентов бюджета, но сужают вилку оценки и уменьшают буфер сильнее, чем стоят сами.

Пример расчёта: один проект в двух моделях

Возьмём условный проект — личный кабинет B2B-клиента: каталог с персональными ценами, заказы и их статусы, обмен с 1С, три роли пользователей. Команда оценила его в 900 часов в базовом сценарии, с вилкой 800–1 150 часов. Ставка для примера — 2 500 ₽/час. Цифры иллюстративные: показывают логику, а не прайс на такие кабинеты.

Что видно из расчёта:

• В нормальном сценарии T&M дешевле фикса на 675 000 ₽ — ровно на размер буфера. Даже в плохом сценарии (1 150 часов) T&M вышел чуть дешевле, потому что буфер был заложен с запасом.
• Фикс выигрывает, только если реальность хуже пессимистичной оценки, — и тогда подрядчик сработает себе в убыток, что для заказчика тоже риск: качество и сроки.
• Гибрид с аналитикой в начале сужает неопределённость, поэтому буфер на остальные этапы можно уменьшить вдвое. Выходит дороже «идеального» T&M, но бюджет известен до старта каждого этапа.

Как контролировать time & material, чтобы бюджет не утекал

Главный страх заказчика в почасовой модели — платить за «работу ради работы». Он снимается не доверием, а инструментами контроля, которые стоит прописать в договоре.

Трекер и отчёты по часам

Все задачи живут в трекере (Яндекс Трекер, Kaiten, YouGile или другой; Jira встречается в основном в ранее купленных серверных версиях — Atlassian в 2022 году прекратила продажи и поддержку в России), у заказчика есть доступ на чтение. Часы списываются на конкретные задачи, а в ежемесячном отчёте видно: задача, исполнитель, время, ссылка на коммит или merge request. Отчёт «разработка — 160 часов» без детализации принимать нельзя.

Оценка до старта задачи и лимиты

Даже в T&M крупную задачу сначала оценивают, и заказчик её согласовывает. Полезное условие для договора: если задача превышает оценку больше чем на заданный порог (часто берут 20–30%, но это ориентир, а не норма), исполнитель останавливается и сообщает до того, как продолжить. Плюс месячный лимит часов, который нельзя превысить без письменного согласования.

Демо по спринтам

Раз в одну-две недели команда показывает сделанное на тестовом сервере, а не в презентации. Это лучший способ понять, что часы превращаются в работающий функционал, и вовремя развернуть проект, если он идёт не туда.

Точки выхода

Ценность T&M в том, что вы можете остановиться после любого спринта и не потерять оплаченное: код в вашем репозитории, документация актуальна. Проверьте, что так и есть: репозиторий на вашем аккаунте, доступы персональные. Если нужен разработчик в вашу команду, а не проект целиком, это отдельный формат — аутстаффинг с почасовой оплатой и отчётом по задачам; чем он отличается от аутсорса, разобрано в статье про аутсорс и аутстафф.

Оплата по вехам и предоплата

Даже фиксированную цену почти никогда не платят одной суммой. Типовые схемы:

• Аванс + остаток после сдачи. Самая рискованная для заказчика схема на крупных проектах: крупная сумма уходит до того, как вы увидели результат.
• Оплата по вехам. Проект делят на этапы с измеримым результатом (прототип, дизайн, модуль каталога, интеграция), на каждый — аванс (на рынке часто 30–50% стоимости этапа, но это предмет договорённости) и доплата после приёмки. Заказчик одновременно рискует только суммой одного этапа.
• Постоплата по актам в T&M. Раз в две недели или раз в месяц — акт с отчётом по часам и счёт. Иногда подрядчик просит предоплату за первый месяц как гарантию.
• Ретейнер. Фиксированная сумма в месяц за пакет часов, например 40 часов по 2 500 ₽ = 100 000 ₽. Заранее договоритесь, что происходит с неиспользованными часами: сгорают, переносятся на следующий месяц или частично возвращаются.

Юридически: договор подряда или оказания услуг

В Гражданском кодексе нет терминов «fixed price» и «time & material», но обе модели ложатся на существующие договоры. Выбор главы определяет, как принимать работу и что будет при расторжении.

Несколько практических моментов:

• При твёрдой смете подрядчик не может потребовать доплаты, даже если потратил больше (исключение — существенный и непредвиденный рост стоимости материалов и услуг третьих лиц). При приблизительной он обязан вовремя предупредить о существенном превышении, а заказчик вправе не согласиться и отказаться от договора, оплатив выполненную часть (ст. 709). Если вид сметы в договоре не указан, цена считается твёрдой — но лучше прописать это прямо.
• В договоре услуг результата «по ГК» нет, поэтому качество защищается условиями договора: требования к коду, критерии готовности задачи, право не принимать часы по задачам, сделанным с дефектами.
• В обеих моделях отдельно пропишите исключительное право на код. По ст. 1296 ГК РФ право на программу, созданную по заказу, по умолчанию принадлежит заказчику, но на умолчание лучше не полагаться: укажите момент перехода права (по оплате этапа или периода и подписанию акта) и статус сторонних библиотек и готовых модулей подрядчика.
• Гарантийный срок на исправление ошибок после сдачи — тоже договорное условие, в стандартные формулировки его не всегда включают.

Статьи ГК задают рамку, а спорные ситуации решают конкретные пункты договора: порядок приёмки, сроки на замечания, что считается изменением объёма. Поэтому договор стоит показать юристу.

Когда выбирать fixed price, а когда T&M

Fixed price подходит, если

• есть детальное ТЗ или прототип, и вы готовы не менять его в процессе;
• проект типовой: лендинг, корпоративный сайт, магазин на коробочной CMS;
• бюджет утверждён заранее, и превышение для вас неприемлемо — например, это грант или бюджет, утверждённый на год;
• вы не готовы выделить человека, который каждую неделю будет смотреть демо и расставлять приоритеты.

Time & material подходит, если

• продукт будет меняться по обратной связи от пользователей — MVP, стартап, новый сервис;
• работа идёт с чужим легаси-кодом, объём которого не оценить без погружения (почему такой код дорожает, разобрано в статье про технический долг);
• это постоянный поток задач по работающему проекту, а не проект с концом;
• у вас есть продакт-менеджер или вовлечённый владелец, готовый управлять бэклогом.

Гибрид — чаще всего разумный компромисс

Для заказной разработки уровня личного кабинета, портала или сервиса обычно работает связка: сначала оплачиваемая по факту или небольшим фиксом аналитика и прототип, потом фикс по этапам на то, что уже описано, и T&M или ретейнер на развитие после запуска. Так, при разработке веб-приложений стоимость называют после аналитики и прототипа, фиксируют в договоре и платят по вехам — за принятые этапы, которые видны на тестовом сервере; новые задачи, появившиеся по ходу, оценивают отдельно и заранее.

Какие модели применяем в АП-ИМ

Мы используем обе модели, и выбор зависит от задачи, а не от того, что нам удобнее:

• Проекты с понятным результатом (веб-приложение, портал, крупная доработка) — фиксированная смета после аналитики, оплата по вехам за принятые этапы, код и доступы передаём заказчику.
• Поток задач по работающему сайту — единичные правки оцениваем фиксом, а при большом потоке удобнее почасовая модель: ставка 2 500 ₽/час. Как это устроено на практике, описано на странице доработки сайта.
• Разработчик в команду заказчика — та же ставка 2 500 ₽/час, частичная загрузка от 20 часов в месяц, ежемесячный отчёт по часам с привязкой к задачам и коммитам.

Итоговая стоимость в любом случае зависит от объёма логики, интеграций и состояния существующего кода — поэтому сначала разбор задачи, потом цифра.

Типичные ошибки при выборе модели оплаты

1. Выбирать фикс ради «гарантии бюджета» без ТЗ. Без описания результата фиксированная цена либо завышена буфером, либо приведёт к спорам о том, что в неё входило.
2. Сравнивать фикс одного подрядчика с часами другого. Сравнивайте оценки в часах по одинаковой декомпозиции, иначе вы сравниваете размер буферов, а не стоимость работы.
3. Соглашаться на T&M без трекера и отчётов. Почасовая модель без прозрачности — это доверие вслепую.
4. Не прописать процедуру изменений. В fixed price нужен формальный порядок: запрос → оценка → согласование → допсоглашение. Иначе мелкие «а можно ещё» съедают буфер, а потом появляются счета.
5. Платить большую предоплату за весь проект. Риск заказчика должен быть ограничен одним этапом.
6. Забыть о жизни после запуска. Поддержку и развитие удобнее вести по T&M или ретейнеру, а уровень сервиса — время реакции, приоритеты ошибок — зафиксировать в SLA.

Чек-лист перед подписанием договора

• Модель выбрана под степень неопределённости проекта, а не «как привыкли».
• Есть оценка в часах по блокам работ, видно размер буфера в фиксе.
• Для fixed price указано, твёрдая смета или приблизительная.
• Оплата разбита на вехи с проверяемым результатом, аванс — не больше одного этапа.
• Для T&M прописаны ставка, месячный лимит часов и порог превышения оценки, после которого нужно согласование.
• У вас есть доступ к трекеру, отчёты по часам привязаны к задачам и коммитам.
• Демо на тестовом сервере — не реже раза в две недели.
• Описан порядок изменений объёма: запрос, оценка, согласование, допсоглашение.
• Прописаны переход исключительных прав на код и передача доступов.
• Есть гарантийный срок на исправление ошибок и условия поддержки после запуска.

Вывод

Fixed price и time & material не лучше и не хуже друг друга: это два способа распределить риск неопределённости. В фиксе вы платите за спокойствие буфером (ориентировочно 15–50% в зависимости от проработки ТЗ) и теряете гибкость, в T&M платите только за сделанное, но берёте на себя контроль и риск перерасхода. Для большинства заказных проектов разумнее гибрид: сначала снять неопределённость аналитикой, затем фиксировать цену по этапам и перейти на почасовую модель, когда продукт живёт и развивается. Выбор модели оплаты — такое же управленческое решение, как выбор подрядчика, и принимать его стоит до того, как обсуждать итоговую сумму.