Fix price или Time & Material: как считать бюджет digital-проекта и кто несёт риск

Когда обсуждение доходит до денег, заказчик почти всегда просит фиксированную цену, а подрядчик почти всегда предлагает почасовую оплату. Обе стороны при этом уверены, что защищают себя от риска. На деле спор идёт не о цене, а о том, кто заплатит за неизвестность — за те требования, которые на старте ещё никто не сформулировал.

Мы в Else Digital работаем и по фиксу, и по Time & Material, и решаем это не идеологически, а по типу задачи. Ниже — как устроены обе модели изнутри, из чего складывается оценка стоимости разработки, где каждая из них ломается и что писать в договоре на разработку, чтобы спор о лишних часах не превратился в конфликт.

Fix price — это фиксированная стоимость за заранее описанный объём работ. Подрядчик берёт требования, оценивает трудозатраты и называет сумму, которая не меняется, пока не меняется объём.

Внутри цифра собирается так: команда декомпозирует задачи, каждая получает оценку в часах, часы умножаются на ставку. Дальше начинается главное — к сумме добавляется резерв на неопределённость. Чем менее детально описан проект, тем больше резерв: на слабо проработанном ТЗ он доходит до 30–50%.

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

Отсюда следует практический вывод: фикс тем выгоднее, чем детальнее проработаны требования. Хорошее техническое задание — не бюрократия, а прямая экономия: оно снимает резерв. Мы обычно предлагаем разбить работу на два договора — сначала аналитика и техническое задание по факту, потом фикс на реализацию по этому ТЗ. Тогда фиксируется не фантазия, а посчитанный объём.

Time & Material — оплата за фактически потраченное время команды по согласованной ставке. Бюджет не фиксируется целиком, фиксируется стоимость часа и состав команды.

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

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

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

Разница между моделями сводится к одному: кто платит, когда реальность расходится с планом.

В Fix price риск на подрядчике. Ошиблись в оценке, недооценили интеграцию, попали в неожиданное поведение чужого API — доделываете за свой счёт. Заказчик спокоен, но за это спокойствие уже заплатил в составе цены.

В Time & Material риск на заказчике. Работа оплачивается по факту, поэтому любая новая идея, переделка и «а давайте попробуем иначе» оплачивается вами. Взамен вы не переплачиваете за резерв и можете менять приоритеты без пересогласования договора.

Есть и третий вариант, о котором редко говорят: риск можно поделить. Например, фикс на ядро продукта и T&M на развитие после запуска. Или фикс с оговорённым коридором изменений: до 10% объёма — внутри цены, свыше — по отдельной оценке. Это не компромисс ради компромисса, а честное разделение неизвестности на предсказуемую и непредсказуемую части.

Фикс перестаёт работать в трёх ситуациях.

Первая: требования сформулированы на уровне «нужен маркетплейс». Оценить это нельзя, можно только придумать цифру. Дальше проект живёт в режиме «это не входило в объём», и обе стороны раздражаются.

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

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

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

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

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

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

Шаг первый — отделить понятное от непонятного. Личный кабинет с типовыми сценариями оценивается нормально. Рекомендательный алгоритм, который вы ещё не проверяли на данных, — нет.

Шаг второй — зафиксировать понятное. На эту часть просите фикс, но только после аналитики и технического задания, иначе платите за резерв.

Шаг третий — непонятное вести по T&M с лимитом часов на спринт и обязательной демонстрацией результата каждые две недели.

Шаг четвёртый — заложить бюджет на изменения. Не «если понадобится», а отдельной строкой: 15–20% от суммы проекта. Изменения будут в любом случае, вопрос лишь в том, признали вы это на старте или будете искать деньги в процессе.

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

Как это выглядит на практике: в HR-портале «Регро Вахта» ядро — приложение, распознавание документов, синхронизация статусов с Битрикс24 — мы делали фиксированным объёмом, а дальше проект живёт в режиме ежемесячных доработок, где новые функции приоритизируются по мере необходимости.

Независимо от модели в договор на разработку стоит внести четыре вещи.

Процедуру изменений: кто инициирует, кто оценивает, в какой срок и в каком виде фиксируется согласие. Без этого любой спор упирается в переписку в мессенджере.

Критерии приёмки: что считается готовым. «Работает» — не критерий, критерий — сценарии, которые проходят на тестовых данных.

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

Условия выхода: что происходит, если сотрудничество прекращается на середине. В T&M — оплата по факту и передача материалов, в фиксе — расчёт по завершённым этапам.

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

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

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

Можно ли получить фикс без технического задания?

Можно, но цифра будет с большим резервом и оговорками. Дешевле сначала оплатить аналитику и техническое задание по факту, а потом зафиксировать стоимость реализации.

Что дешевле в итоге?

При стабильных требованиях дешевле T&M — вы не платите за резерв. При меняющихся требованиях дешевле фикс, но только если изменения удаётся удерживать внутри согласованного объёма.

Как контролировать бюджет в T&M?

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

А если нужна команда, а не проект?

Тогда это не фикс и не T&M, а аутстаффинг: вы берёте специалистов в свою команду и управляете ими сами, оплачивая занятость.

Фикс — это покупка предсказуемости, и она стоит денег: резерв на риск заложен в цену.

T&M — покупка гибкости, но требует вашего участия в темпе спринта.

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

Лучшая практика для сложных проектов — фикс на понятное ядро и T&M на развитие.

Бюджет на изменения закладывается заранее: 15–20% от суммы проекта.

Если нужно посчитать конкретный проект — мы начинаем с аналитики и технического задания, после которого называем фиксированную стоимость разработки веб-сервиса. Если нужна не команда под ключ, а усиление вашей — это аутстаффинг специалистов. Как мы ведём длинные проекты с постоянными доработками, видно в кейсе «Регро Вахта».