О ценообразовании почти никто не рассказывает, но именно оно тихо ломает больше всего проектов у фрилансеров и небольших студий. Вот как мы смотрим на три распространённые модели и что делаем сами.
Почасовая оплата наказывает за скорость
Почасовая оплата кажется безопасной в начале: вы получаете деньги за каждый час и не рискуете занизить цену. Но у неё странный побочный эффект: чем лучше и быстрее вы работаете, тем меньше зарабатываете на проекте, потому что для того же результата нужно меньше часов. К тому же клиент начинает смотреть на часы, а не доверять результату.
Фиксированная оплата заставляет реально оценивать объём
Фиксированная цена переносит риск, но требует дисциплины: объём проекта нужно по-настоящему определить до выставления цены, потому что любой пробел в нём вычитается из вашей маржи. Если сделать это хорошо, это самая здоровая модель для обеих сторон: клиент заранее знает точную стоимость, а вас поощряют за эффективность, а не наказывают за неё.
Оплата по ценности сначала требует репутации
Ценообразование на основе созданной ценности, например процента от прироста выручки, звучит привлекательно, но убедительно применять его трудно, пока нет подтверждённых похожих результатов. К нему стоит прийти, когда у вас есть реальные кейсы с реальными цифрами, а не начинать с него в самом первом проекте.
Всегда оценивайте неизвестное отдельно
Какую бы модель вы ни выбрали, отделяйте известный объём от неопределённого: редизайн обычно хорошо определяется, а «разберёмся с интеграцией, когда увидим их API» — нет. Известную часть оценивайте фиксированной ценой, а неопределённую оформляйте как заказ на изменение или как ограниченный пакет часов, чтобы ни одна сторона не несла риск неизвестного в одиночку.
Что мы делаем на самом деле
Большинство наших проектов идут по фиксированной цене, с чётко определённым заранее объёмом после настоящего разговора о том, что действительно нужно, и с заказами на изменения для всего, что выходит за его рамки. Эта модель позволила почти не спорить о цене в проектах, которые мы вели.
Универсально «правильной» модели нет, но какую бы вы ни выбрали, ошибкой обычно оказывается проект, объём которого так и не был нормально определён.