Фиксированная цена или почасовая оплата: как агентства на самом деле считают смету

При почасовой оплате, которую ещё называют time and materials, вы платите за время, потраченное командой. Итоговая стоимость зависит от того, сколько на самом деле займёт работа.

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

В любом программном проекте есть неизвестные. Интеграция ведёт себя не так, как написано в документации, или макет оказывается сложнее в разработке, чем казалось. Модель оплаты решает, кто платит за эти сюрпризы.

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

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

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

• Исследование. Выяснить, что нужно пользователям, или проверить, работает ли технический подход.
• Техническая неопределённость. Например, стартапу нужно проверить, справится ли сторонний API с его данными, прежде чем строить на нём продукт.
• Постоянная работа без конца. Поддержка, небольшие доработки и долгосрочное сопровождение.
• Команда, которой руководите вы. Когда внешние разработчики входят в вашу команду и вы ставите им приоритеты, оплата за время естественна.

Почасовая оплата требует и кое-чего от вас: времени и технической подготовки, чтобы каждую неделю проверять часы и пересматривать приоритеты. Без этого гибкость превращается в дрейф: работа идёт, часы списываются, а продукт не становится ближе к запуску.

Фиксированная цена подходит, когда вы знаете, что нужно для запуска, и можете это описать хотя бы в общих чертах. Сюда попадает большинство MVP и понятных редизайнов.

• У вас бюджет, который нельзя превысить. Это верно для большинства основателей на стадии pre-seed и тех, кто развивается на свои деньги.
• Вы хотите сравнивать агентства по одному объёму работ, а не по часовым ставкам, за которыми прячутся разные оценки.
• Вы не хотите поверх управления компанией ещё и разбирать табели агентства.

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

AutoIntel, B2B-инструмент для немецкого рынка подержанных автомобилей, показывает, почему такой порядок работает. Интерактивный прототип позволил клиенту решить, какие поля и фильтры важны, до того как оценивался сбор данных под них.

Да, если договор фиксирует правильные вещи. Мартин Фаулер в заметке о договорах с фиксированной ценой пишет, что проблема не в фиксированной цене, а в фиксированном объёме, который делает вид, будто ничего не изменится.

Манифест Agile выражает ту же мысль одной строкой: «сотрудничество с заказчиком важнее согласования условий контракта». На практике это значит фиксированные бюджет и срок, понятный порядок приоритетов функций и процедура замены одной функции на другую.

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

Объём работ меняется всегда. Хороший договор с фиксированной ценой отличается от плохого тем, что происходит в этот момент.

В хорошем договоре есть письменный порядок изменений:

• Новый запрос описывается в одном-двух предложениях.
• Агентство оценивает его стоимость и влияние на срок.
• Вы его утверждаете, меняете на что-то равное по объёму или переносите на следующий этап.
• Только после этого кто-то начинает над ним работать.

Плохой договор либо отклоняет любые изменения, либо тихо их поглощает, пока не начинает страдать качество. Оба варианта заканчиваются плохо, просто в разное время.

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

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

Фиксированная цена хороша ровно настолько, насколько хорош документ за ней. Перед подписанием проверьте, что договор или приложение с объёмом работ покрывает эти пункты:

• Входящие пользовательские сценарии, описанные как результат, который можно проверить.
• Список исключений, чтобы не спорить о том, что «само собой подразумевалось».
• Этапы, что вы увидите на каждом и какой платёж к нему привязан.
• Порядок изменений: как запросы описываются, оцениваются и утверждаются.
• Кому принадлежат код, макеты и аккаунты после оплаты.
• Что будет после запуска: гарантийный период для исправления ошибок и как оплачивается дальнейшая работа.

Если чего-то не хватает, попросите добавить. Серьёзное агентство не будет против, потому что та же ясность защищает и его.

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

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

Этапы дают и естественные точки выхода. Если сотрудничество не складывается, можно остановиться между этапами, а не потерять всё, что заплачено вперёд.

Многие проекты используют смесь, а не одну чистую модель. Чаще всего встречаются три сочетания:

• Фиксированный этап исследования, потом фиксированная разработка. Сначала дизайн и прототип, потом цена разработки на основе того, что показал прототип.
• Фиксированная разработка, потом почасовая или ежемесячная поддержка. У запуска понятный объём, у того, что после него, нет.
• Ежемесячный объём, согласованный заранее. Поддержка и доработки планируются по месяцам, и бюджет остаётся предсказуемым без конечной даты.

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

После брифа мы называем фиксированные объём, срок и цену. Большинство предложений уходит в течение 2–3 рабочих дней после заполненного брифа.

Оплата делится на этапы: аванс для старта, остальное по мере сдачи. Мы никогда не берём 100% до начала работы, а наша стандартная схема позволяет остановиться между этапами, не оплачивая работу, которая ещё не начата.

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

Если вы ещё прикидываете бюджет, в статье о том, сколько стоит SaaS MVP, есть типичные диапазоны. Когда на руках будут предложения, сравнить их поможет статья о том, как читать коммерческое предложение на разработку.

Быстрая проверка:

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

Готовы получить фиксированную смету? Расскажите о своём продукте. Сначала мы зададим несколько вопросов, потом пришлём предложение с объёмом, сроком и ценой.