Мы разберем детально какие бывают формы ценообразования на создание интернет-проекта.
Разговор о формах оплаты тяжело начинать, на разобрав детально какие бывают формы ценообразования на создание интернет-проекта. В основе любой системы ценообразование лежит стоимость человеко-часа производящего сотрудника, участвующего в проекте.
Сразу это не очень понятно, ведь мы всегда привыкли видеть стоимость сайта в конечной сумме. Проще будет разобраться с помощью аналогий из жизни. Например, адвокаты и юристы, а также автосалоны оценивают свои работы в стоимости «человекочаса». И нам это понятно, потому случаи бывают достаточно разные и вполне логично, что стоимость зависит от того сколько специалист работал над конкретной задачей.
Но для того чтобы покупателю была более понятна эта методика расчета, поставщики применяют более простые для покупателя единицы измерения, например автосервисы на основе статистики устанавливают нормочасы на типовые виды работ и заявляют уже конечную стоимость. При этом в сложных случаях, когда тяжело спрогнозировать объем работ, проводят платную диагностику. Строители, в свою очередь, измеряют стоимость пропорционально метражу объекта, хотя связь между объемом работ непрямая (кстати, не поэтому ли ремонтам и стройкам, свойственно затягиваться?)
Какие же существуют виды оплаты работ в веб-разработке?
Любой проект всегда разрывается между объемом работ, его стоимостью и временем, которое требуется на проект. Вспомните любой ремонт: у нас есть естественное желание сделать как можно больше, дешевле и быстрее. Но, увы, мы понимаем, чем это может закончится — сильно пострадает качество. Подобное применяется в веб-продакшине или производстве программного обеспечения.
Fixed Price (Фиксированная цена)
Вы оговариваете объем работ, сроки и фиксируете стоимость. В течение всего проекта эти параметры не меняются. Это самая распространенная модель на рынке, поскольку она самая привлекательная для заказчика. Однако у этой модели очень много подводных камней, о которых не принято говорить.
В основе бизнеса веб-разработки лежит стоимость «человекочаса» (все расходы это офис и зарплаты зависят времени). На первоначальном этапе крайне тяжело определить работы или проблемы, которые могут возникнуть в процессе. Если возникает не соответствие оценке в сторону увеличение сроков, это означает, что подрядчик должен понести дополнительные расходы на сверхурочные работы, чтобы нагнать сроки. Поскольку все зафиксировано в договоре, будет страдать качество продукта, так как это незаметное уменьшение объема работ.
Чтобы не допускать подобных ситуаций, исполнитель закладывает в стоимость проекта риски и усиливает проектную составляющую своей команды, которая занимается оценкой проектов. Последнее естественным образом ведет к увеличению цены человекочаса или самого проекта в силу стоимость времени системного аналитика.
Плюсы:
- Риски на исполнителе
- Простота бюджетирования и временного планирования для заказчика
Минусы:
- Возможны скрытые дополнительные работы сверх бюджета
- Риск потери качества
- Невозможность использовать подрядчика в роли эксперта из-за конфликта интересов
- Отсутствие гибкости в ходе проекта
- Затраты на создание строго технического задания
- Большее вовлечение заказчика в процесс
Работать по этой схеме следует только при наличии четкого технического задания. При этом, рекомендуем закладывать в бюджет большую сумму на поддержку проекта в первые месяцы после запуска.
Time and Materials (время и материал). Оплата по факту
Это оплата за фактически отработанные исполнителем часы без каких-либо ограничений. В данном типе работы фиксируется объем работ и качество. Переменными значениями здесь остаются бюджет и время. В данном случае, оценка проекта остается, но она не является критичной составляющей.
Этот тип договора подходит когда:
- важна экспертиза исполнителя
- на первом месте стоит качество и результаты продукта
- нет очевидного решения задачи
- у заказчика нет четкого видения конечного продукта
Следует отметить, что у клиента остается возможность ускорить ход проекта путем подключения дополнительных сотрудников. Также нужно учитывать, что если объем вашего проекта не покрывает полностью производящих участников, компания исполнителя будет задействовать его на других проектах, что может еще растянуть сроки проекта.
FFF — Fixed time. Fix budjet, Flex-scope (фиксированные сроки, фиксированный бюджет, гибкие объемы)
Эта схема была предложена известным идеологом веб-разработки компанией 37signals, создателем SaaS сервиса basecam. Эта модель решает 2 известных проблемы интернет компаний:
- долгострои
- перфекционизм
Тем не менее она достаточно устоялась на западном рынке веб-разработки до такой степени, что ее стали использовать в своей работе фрилансеры. В данной модели фиксируются сроки и бюджет, но не фиксируется объем работ.
Например, у вас есть фиксированная сумма денег и 1 месяц времени. Вы составляете оценку проекта и начинаете работать. Если с вашей стороны поступили дополнительные комментарии, или вскрылись проблемы, о которых раньше не было известно, то вы обсуждаете с разработчиком в каком объеме вы запустите проект у установленному сроку. Часть функционала может быть перенесена на следующий этап или упрощена.
Если вы находитесь в стадии поиска сервисов для своего сайта, данная модель стимулирует вас к созданию MVP (minimal viable product — минимально значимый продукт). Создавая только основной функционал, вы смотрите, как пользователь реагирует на него, и принимаете решения продолжать инвестировать или нет. Не подходит, если вы в деталях знаете, что вы хотите, но не вписываетесь в указанный исполнителем бюджет.
Ритейнер (выкуп команды)
Оговоримся сразу, что этот тип подходит когда у вас достаточно долгий цикл разработки проекта. Суть его состоит в том, что вы покупаете конкретную команду, которая будет работать на ваш проект.
Вы знаете ваш месячный бюджет, вы контролируете объем работ в каждой итерации. Самое явное преимущество этой схемы — вы получаете более низкую стоимость человеко-часа, чем при любом другом варианте работы. Вы в праве даже потребовать полный расчет стоимости человеко-часа, включая даже прибыль и налоги.
Эта схема очень хорошо ложится на гибкие agile-методы разработки. В каждом релизе вы определяете, что туда войдет и сами же определяете частоту релизов.
Вывод
Выбирайте наиболее подходящую для вас и ваших задач форму оплаты работ. Этот инструмент может являться дополнительным мотиватором. Но в случая неправильного использования может выступать в обратной роли. Мы рекомендуем отказывать от метода фиксированной стоимости проекта, так как в нем заложен конфликт интересов следствие которых может являться качество работ. Промежуточный этап который может устраивать обе стороны, когда вы потенциально готовы к тому что стоимость поддержки будет несколько выше в первые месяцы после запуска проекта.