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

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

В некоторых из наших проектов мы нашли противоречия и скрытые требования на таком разборе, ещё до разработки.

Чем фиксированная цена отличается от оплаты по часам?

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

В договорах эти модели называют Fixed Price и Time & Material, дословно «время и материалы»: платят за часы команды и прямые расходы. В разговоре их зовут «фикс» и «почасовка». За фиксированной ценой стоит описание того, что будет сделано, и критерии приёмки - признаки, по которым вы проверите, что работа выполнена. Подрядчик называет сумму за весь объём и отвечает за неё, даже если сам ошибся в оценке. В почасовой модели он называет ставку и регулярно отчитывается, сколько времени ушло и на что.

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

Что говорит Гражданский кодекс о твёрдой и приблизительной цене?

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

Разработку на заказ часто оформляют договором подряда: подрядчик выполняет работу и сдаёт результат, заказчик принимает его и платит. Фиксированная цена в законе называется твёрдой, а приблизительная - это оценка, которую можно превысить по правилам, описанным ниже. Цене работы посвящена статья 709 ГК РФ, и до подписания стоит прочитать её пункты 4-6.

1. Пункт 4: «Цена работы (смета) может быть приблизительной или твердой. При отсутствии других указаний в договоре подряда цена работы считается твердой».
2. Пункт 5 касается приблизительной цены. Если понадобились дополнительные работы и цена из-за них существенно растёт, подрядчик обязан своевременно предупредить заказчика. Заказчик вправе не согласиться и отказаться от договора, оплатив выполненную часть. Подрядчик, который вовремя не предупредил, доделывает работу по цене из договора.
3. Пункт 6 касается твёрдой цены. Подрядчик не вправе требовать её увеличения, заказчик - уменьшения, даже если полный объём работ нельзя было предусмотреть при подписании. Требовать повышения подрядчик вправе, только если существенно подорожали материалы и оборудование, которые он предоставляет, или услуги третьих лиц, и этого нельзя было предусмотреть при заключении договора. Если заказчик откажется, подрядчик может потребовать расторжения договора.

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

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

Почему фиксированная цена дорожает?

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

Стив Макконнелл, автор книги об оценке программных проектов, называет неточность ранней оценки конусом неопределённости. В начале разброс широкий, с каждым принятым решением он сужается. На стадии идеи оценка может ошибиться в четыре раза в любую сторону, от четверти настоящей суммы до учетверённой. Подрядчик, который берёт на себя риск твёрдой цены, защищается запасом. Антон Непомнящих, у которого, по его словам, 17 лет опыта в заказной разработке, в статье о почасовой оплате пишет о таких рисках: «их просто „бахают“ буферами в стоимость, что невыгодно для заказчика».

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

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

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

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

Когда оплата по часам выгоднее и как её контролировать?

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

Почасовая модель подходит, если:

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

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

1. Отчёт по итогам каждого короткого этапа: что сделано и что можно проверить руками.
2. Потолок на этап или на месяц. Превысить его можно только с вашего письменного согласия.
3. Короткие этапы и право остановиться после любого из них, оплатив сделанное.
4. Человек с вашей стороны, который отвечает на вопросы команды и решает, что делать дальше.

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

Как понять, что проект готов к фиксированной цене?

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

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

1. У каждого требования есть критерий приёмки. Требование «бот хорошо отвечает» проверить нельзя, и при приёмке о нём начнут спорить. Для ИИ-ассистента карьерных решений мы записали к каждому сценарию эталонный ответ и критерии, которые отсекают плохой, например «ответ не содержит списка „обновите резюме“». Спор о качестве решается сравнением с эталоном, а подрядчик по такому описанию может назвать цену и сдать работу.
2. Противоречия найдены до кода. Документ с требованиями нередко противоречит сам себе, и каждое такое место потом приходится переделывать в коде. В сервисе бронирования парковки окно, в которое сотрудник подтверждает въезд, в одном разделе было задано как 30 минут до начала брони и 30 после, а в таблице параметров - 30 до и 60 после (−30/+30 и −30/+60 минут). Таких мест мы нашли четыре и все вынесли заказчику на решение до разработки.
3. Требования собраны по всему документу. Требования, из-за которых потом дорожает разработка, часто записаны в описаниях процессов, уведомлений и санкций за нарушения. В парковочном проекте около 60 требований мы вытащили из этих описаний, а в разделе «Функциональные требования» стояла меньше половины всех требований.
4. Выбор между несовместимыми пожеланиями сделан до разработки. Сеть офлайн-центров хотела сразу три вещи: один сервер на всю сеть, центры, которые работают без связи друг с другом, и общий баланс клиента по всем точкам. Мы показали, что вместе выполняются только два условия из трёх, и разложили варианты с ценой каждого.
5. Исключения записаны. То, чего в работе нет, должно стоять в документе так же ясно, как то, что есть. В wellness-приложении возврат средств вынесли за пределы первой версии и записали это как принятое решение.
6. Ограничения чужих систем известны до оценки. Если проект опирается на сервис другого поставщика, его возможности выясняют первыми. В проекте паркинга по данным поставщика фактический выезд машины определяется только по косвенному признаку. Мы записали, что этот признак нужно проверить на выборке, прежде чем строить на нём отчёты.

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

Что делать, если объём ещё не ясен?

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

• Этап разбора требований, потом фиксированная цена. Сначала короткий этап: требования, критерии приёмки, противоречия, ограничения. На рынке его оплачивают по-разному: отдельной суммой или по времени. Цену на разработку называют по его итогам.
• Фиксированная цена на этап. Проект делят на этапы, каждый оценивают и оплачивают отдельно. Риск ограничен одним этапом, и после любого из них можно сменить подрядчика.
• Фиксированный бюджет и срок, изменяемый состав работ. Мартин Фаулер описывает это так: есть сумма и дата запуска, и вы вместе с подрядчиком выбираете лучший набор функций, который в них помещается. Джефф Сазерленд, один из создателей Scrum (способа вести разработку короткими циклами), добавил правило обмена: новую функцию можно взять, если убрать другую такого же объёма.
• Оплата по часам с потолком. Вы платите по факту, но не больше оговорённой суммы на этап. Схема работает, когда состав работ можно подстроить под сумму.
• Целевая стоимость с делением экономии. Стороны договариваются о целевой сумме и о том, как делят перерасход и экономию. В российском договоре опора для такой схемы - пункт 2 статьи 710 ГК РФ.

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

Что спросить у подрядчика и что записать в договоре?

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

1. Какая цена: твёрдая или приблизительная. Укажите это в договоре прямо. Без такого указания закон считает цену твёрдой, и лучше, чтобы обе стороны понимали это одинаково.
2. Что входит в работу и что нет. Исключения записывают в договор или приложение к нему отдельным списком.
3. Как оформляется изменение. Запишите, кто предлагает изменение, кто его оценивает и подписывает и за какой срок. Устная договорённость о «маленькой правке» - частая причина споров о доплатах.
4. Как принимается результат. По каким критериям, в какой срок и что происходит с замечаниями.
5. Как вы платите. Оплату этапами по готовым результатам проще контролировать: деньги уходят за то, что уже можно проверить.
6. Что вы получите при выходе из договора. Закон разрешает заказчику отказаться, оплатив выполненное и возместив подрядчику убытки в пределах, которые задаёт статья 717. Договоритесь, что останется у вас на руках: код, доступы, документация.
7. Кому принадлежат права на код. По статье 1296 ГК РФ исключительное право на программу, созданную по заказу, принадлежит заказчику, если договор не предусматривает иного. Исключительное право - это право использовать программу и распоряжаться ею. Проверьте, что в договоре нет оговорки в пользу подрядчика и что исходный код передают вам.
8. Для оплаты по часам - отчётность и потолок. Как часто приходит отчёт, что в нём, какой потолок и кто может его поднять.
9. Кто с вашей стороны принимает решения. Впишите в договор, кто это и за какой срок он отвечает на вопросы команды. Пока ответа нет, сроки сдвигаются.

Источники

• Гражданский кодекс РФ, часть 2, статья 709 «Цена работы», КонсультантПлюс
• ГК РФ, статья 710 «Экономия подрядчика», КонсультантПлюс
• ГК РФ, статья 717 «Отказ заказчика от исполнения договора подряда», КонсультантПлюс
• ГК РФ, часть 4, статья 1296 «Произведения, созданные по заказу», КонсультантПлюс
• Энциклопедия судебной практики по статье 709 ГК РФ, ГАРАНТ
• Lee Brannan, Wei Lee. Contracts - from the vendor and the buyer point of views, PMI Global Congress 2007
• Martin Fowler. FixedPrice и FixedScopeMirage
• Jeff Sutherland. Agile Contracts: Money for Nothing and Your Change for Free
• Tom Arbogast, Craig Larman, Bas Vodde. Agile Contracts Primer
• Steve McConnell. The Cone of Uncertainty, Construx
• FAR 16.601 Time-and-materials contracts
• Peter Stevens. Time and Materials with Fixed Scope and a Cost Ceiling, архивная копия
• Антон Непомнящих. Почасовая оплата, Хабр

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