Но помимо самой функциональности на итоговую стоимость сильно влияет ещё один фактор, который заказчики часто недооценивают на старте переговоров с подрядчиком, — выбранная модель работы. Разные модели закладывают разное распределение рисков между заказчиком и подрядчиком, и от этого выбора зависит не только цена, но и то, насколько предсказуемым окажется бюджет проекта на всей его протяжённости, а не только в момент подписания договора.
Мы работаем по трём моделям: Fixed Price, Time & Materials и Retainer. У каждой — свои сценарии, где она выгоднее, и свои риски, если применить её не к тому проекту.
Разбираться в этом лучше на старте, а не постфактум: смена модели работы в середине проекта возможна, но обычно означает пересмотр договорённостей и потерю времени на согласование новых условий. Поэтому на брифинге мы отдельно проговариваем не только состав работ, но и то, какая модель подходит именно вашей задаче — и почему.
Fixed Price: когда фиксированная цена выгоднее
Fixed Price фиксирует ТЗ, сроки и стоимость проекта ещё до старта разработки. Это удобно, когда задача чётко описана: MVP с понятным набором функций, отдельный модуль крупной системы, небольшое приложение без сложных интеграций. Заказчик заранее знает итоговую сумму и может планировать бюджет, не опасаясь, что цена изменится в процессе разработки без веской причины.
Обратная сторона фиксированной цены — она требует точного и заранее проработанного ТЗ на входе. Если в процессе разработки заказчик решает добавить функции, которых не было в изначальном техническом задании, это оформляется как отдельное дополнительное соглашение, а не «бесплатно вписывается» в уже согласованный бюджет. Поэтому Fixed Price невыгоден для сторон, если задача на старте описана нечётко, а требования, скорее всего, будут меняться по ходу проекта — в таком случае переплата на постоянных дополнительных соглашениях может оказаться больше, чем при изначально гибкой модели.
Хороший пример проекта под Fixed Price — MVP с быстрым запуском: для METRO C&C первый релиз приложения вышел через месяц после старта работ, а за первый месяц его скачали более 270 000 раз. Понятный, зафиксированный на старте объём задач позволил уложиться в короткий срок без риска, что бюджет «поплывёт» из-за постоянных доработок в процессе.
Fixed Price удобен и заказчику, и команде разработки именно там, где обе стороны заранее понимают, что должно получиться на выходе. Мы всегда предупреждаем, если видим на брифинге риск, что задача описана недостаточно точно для фиксации цены, — в этом случае честнее предложить короткий этап аналитики перед тем, как фиксировать смету, чем зафиксировать цену на нечётких требованиях и потом сталкиваться с постоянными дополнительными соглашениями.
Time & Materials: гибкость за предсказуемость бюджета
Time & Materials фиксирует ставку часа специалиста, а оплачиваются фактически потраченные часы. Эта модель выгодна, когда требования заведомо будут уточняться по ходу разработки — для стартапов, где продукт нащупывает свою аудиторию, или для проектов, где часть решений принимается уже по ходу работы на основе первых данных.
Мы применили такой подход для трёх курортов Северного Кавказа, которые объединили в одном приложении вместо трёх отдельных, добавив прямо в приложение покупку ски-пасса. Задача такого масштаба редко описывается исчерпывающим ТЗ на старте: объединение нескольких курортов в одном продукте порождает вопросы, которые становятся видны только по ходу работы — как совместить разные системы бронирования, как показать пользователю несколько курортов одновременно. Time & Materials позволил дорабатывать решения по ходу проекта, не переписывая договор на каждое уточнение.
Минус модели — заказчику важно доверять подрядчику и следить за расходом часов вместе с ним, а не постфактум: без регулярной отчётности T&M превращается в модель с непредсказуемым итоговым бюджетом. Поэтому мы предоставляем отчётность по затраченным часам на каждом этапе, а не только финальный счёт в конце месяца.
Ещё один плюс T&M для сложных, составных задач — можно начинать работу до того, как продуманы абсолютно все детали. Для объединения нескольких курортов в одно приложение часть архитектурных решений принималась параллельно с разработкой первых экранов — при Fixed Price такой параллельный процесс потребовал бы постоянного пересмотра сметы, а при Time & Materials он органично вписывается в модель оплаты.
Retainer: выделенная команда для постоянного развития
Retainer — модель для систем, которые не заканчиваются одним релизом, а постоянно развиваются: выделенная команда и фиксированный пакет часов в месяц. Она выгоднее двух предыдущих моделей ровно в тот момент, когда у продукта уже есть реальные пользователи и регулярный поток задач на доработку — новые функции, интеграции, изменения по обратной связи.
Здесь заказчик платит не за конкретную задачу, а за доступность команды, которая уже знает контекст продукта и может быстро включаться в новые задачи без долгого погружения с нуля каждый раз, когда появляется новая доработка. Это особенно ценно для крупных систем вроде личного кабинета агента и клиента «Дело Жизни»: 90 % функциональности там настраивается из административной панели без участия программистов, но оставшиеся 10 % — доработки, новые интеграции, нестандартные сценарии — требуют постоянного участия команды разработки уже после запуска, а не разового обращения раз в полгода.
Retainer невыгоден для разовой задачи с понятным объёмом работ — здесь переплата за «доступность команды» превышает выгоду. Поэтому мы обычно предлагаем Retainer уже после того, как первая версия системы запущена по Fixed Price или Time & Materials, а не с самого начала проекта.
Выбор модели оплаты для программного продукта зависит от того, зафиксировано ли ТЗ или система будет развиваться по мере эксплуатации, — и это стоит обсуждать до старта, а не по ходу проекта. Прайса на сайте нет и не будет: стоимость под Fixed Price, Time & Materials или Retainer считаем под конкретную задачу, типовых пакетов не предлагаем. Заполните форму заявки на сайте — в ней есть поле для описания задачи и вложение файла до 50 Мб, — либо пришлите бриф или техническое задание на info@mendev.ru, если оно уже готово. На брифинге разберём вашу задачу, подберём модель оплаты и дадим оценку сроков и стоимости разработки ПО. Такой подход снижает риск вложиться в лишний функционал ещё до того, как система пройдёт проверку реальной эксплуатацией.
