Фиксированная цена или оплата по часам: как платить за разработку

Заказчик рассылает одно и то же техническое задание пяти подрядчикам и получает пять оценок: 600 тысяч, 1,2 миллиона, 1,5 миллиона, 2,8 миллиона и «оплата по часам, ориентировочно 1,4 миллиона». Первая мысль — кто-то из них жадничает или ничего не понимает. Обычно дело в другом: подрядчики по-разному поняли объём, заложили разные риски и предлагают разные модели оплаты. Чтобы сравнивать предложения, нужно понимать, как устроена каждая модель и кто в ней за что платит.

Фиксированная цена

Подрядчик называет сумму и срок за заранее описанный объём. Заказчику это кажется самым безопасным вариантом: бюджет известен, риски на исполнителе.

На деле риски никуда не исчезают, они просто закладываются в цену. Опытный подрядчик, оценивая проект по фиксу, добавляет к своей оценке запас на неопределённость — иногда 30%, иногда 50% и больше, если задание размытое. Неопытный не добавляет, а потом либо работает в убыток и теряет мотивацию, либо начинает спорить о каждой правке.

Фикс хорошо работает, когда:

• объём понятен и описан до уровня экранов и сценариев;
• проект небольшой — до двух-трёх месяцев работы;
• требования не будут меняться по ходу, а если будут — вы готовы оформлять изменения отдельно.

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

Time & material

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

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

Time & material хорошо работает, когда:

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

Гибридные схемы

На практике чаще всего работают комбинации.

1. Фикс на исследование, затем фикс или T&M на разработку. Первый этап — 2–4 недели на интервью, прототип и детальную оценку — оплачивается фиксированно. После него неопределённость резко падает, и оценка разработки становится точной.
2. Фикс по этапам. Проект делится на этапы по 4–8 недель, каждый оценивается отдельно и оплачивается после приёмки. Риски ограничены одним этапом.
3. T&M с потолком. Оплата по часам, но с верхней границей бюджета на этап. Если потолок приближается, стороны садятся и решают, что вырезать.
4. Выделенная команда. Вы оплачиваете команду на месяц вперёд и сами управляете её задачами. Подходит для продуктов, которые развиваются годами.

Почему оценки расходятся в разы

Когда предложения отличаются в три-четыре раза, причина почти всегда в одном из пунктов ниже.

Самое дешёвое предложение часто оказывается дешёвым потому, что в нём чего-то нет. Сравнивать нужно не итоговые суммы, а состав работ. Подробнее о том, как выбирать исполнителя, мы писали в материале о выборе подрядчика.

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

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

Вариант по фиксу. Подрядчик закладывает резерв на неопределённость 30% и называет цену за 780 часов. По ходу проекта заказчик просит добавить уведомления в мессенджер и выгрузку актов. Эти задачи оформляются как изменения: ещё 90 часов с отдельным согласованием. Итог — 870 часов и три недели переписки о том, что входило в исходный объём.

Вариант по часам с потолком. Подрядчик работает по ставке, бюджет этапа ограничен 700 часами. Через месяц выясняется, что история заказов нужна в упрощённом виде, а уведомления в мессенджер — важнее, чем казалось. Приоритеты меняются на очередном планировании без отдельных согласований. Итог — 680 часов, уведомления в первой версии, выгрузка актов перенесена на второй этап.

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

Как читать оценку подрядчика

Хорошая оценка — это не одна цифра, а разбивка, по которой можно задавать вопросы. Обратите внимание на несколько вещей.

• Разбивка по функциям, а не по ролям. «Авторизация — 40 часов, история заказов — 80 часов» полезнее, чем «бэкенд — 300 часов».
• Отдельные строки для тестирования, развёртывания и управления проектом. Если их нет, они либо спрятаны в других строках, либо не запланированы.
• Диапазон, а не точка. Честная оценка на раннем этапе звучит как «400–550 часов» с объяснением, что влияет на разброс.
• Допущения. Список того, что подрядчик считает само собой разумеющимся: «дизайн предоставляет заказчик», «интеграция с 1С через готовый модуль». Именно в допущениях чаще всего прячутся будущие споры.

Как контролировать бюджет при любой модели

• Еженедельные демонстрации. Не отчёты в документе, а работающие функции на тестовом стенде.
• Бэклог с приоритетами. Список задач, отсортированный по важности. Если бюджет заканчивается, внизу остаются задачи, без которых можно жить.
• Отчёт по часам по задачам. Не «40 часов на разработку», а распределение по конкретным функциям. Так видно, где оценка разошлась с реальностью.
• Определение готовности. Что значит «задача сделана»: код написан, протестирован, задеплоен на стенд, принят заказчиком.
• Точки решения. Заранее договоритесь, на каких этапах вы пересматриваете план и бюджет.

Как оформить договор

Независимо от модели в договоре стоит закрепить несколько вещей.

1. Состав работ или порядок его определения (для T&M — через бэклог и согласование спринтов).
2. Ставки по ролям и порядок их изменения.
3. Порядок приёмки: кто принимает, в какой срок, что происходит, если замечаний нет.
4. Процедуру изменений для фиксированной части.
5. Права на результат: код, дизайн, документация.
6. Гарантийный срок и что в него входит.
7. Порядок передачи проекта, если сотрудничество прекращается.

Вопросы, которые стоит закрыть до старта, мы собрали в статье про техническое задание: хорошее задание делает точнее любую модель оплаты.

Что выбрать

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

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