Фикс или почасовка: как выбрать модель, чтобы не переплатить

Модель оплаты — это не “удобно бухгалтерии”, а механизм распределения рисков между заказчиком и подрядчиком. Если выбрать неправильно, вы либо переплатите, либо получите формально “сделано”, но не то, что нужно.

Фиксированная цена: когда работает и где ловушки

Когда фикс выгоден заказчику:

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

Типовые ловушки фикса:

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

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

Почасовка: когда честнее и как не потерять контроль

Когда почасовка выгодна:

• требования будут уточняться по ходу (вы это понимаете и принимаете);
• важна гибкость и быстрые итерации;
• проект исследовательский: много неизвестных (особенно по интеграциям).

Риски почасовки:

• бюджет “течет”, если нет рамок, приоритетов и прозрачного трекинга;
• заказчик платит за организационный хаос (неподготовленные доступы, постоянные “передумали”, отсутствие лица, принимающего решения);
• сложно сравнивать предложения без ориентиров.

Чтобы почасовка не стала “черной дырой”, нужны:

• бэклог с приоритетами и понятными задачами;
• недельные/двухнедельные итерации с демо;
• лимит часов/месяц и правило “стоп” (без вашего подтверждения дальше не идем).

Самый практичный вариант: гибрид

Для большинства заказных систем лучше всего работает схема:

• фикс на этап (MVP/релиз 1/релиз 2) с критериями приемки;
• почасовка на изменения (то, что появилось после согласования этапа).

Так вы фиксируете базовый результат и одновременно сохраняете гибкость, не превращая каждое уточнение в конфликт.

Что зафиксировать в договоре/приложениях

• что считается изменением требований и как оно оценивается;
• что считается багом (исправляется без доплат);
• состав работ по этапам и критерии приемки;
• прозрачность: доступ к трекеру, отчет по часам и задачам.

Оптимальная модель — та, где вам легко отвечать на два вопроса в любой момент: “сколько уже потратили” и “что именно стало готово”.