Три основные модели в ценообразовании: Fixed-Price, Time & Materials, и Milestone

В 21 веке вопрос о деньгах и прибыли стал интимным. Разговор о том, как строится стоимость товара/услуги в кругах бизнесменов не так часто и поднимается, а кому приятно выдавать собственные секреты?

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

Договор с фиксированной стоимостью часа (а именно в часах идет оценка проекта) всегда содержит точную смету работ, которая появилась после детального анализа объема работ и рисков по проекту. Качественная оценка объема работ зависит от описания требований к будущему продукту (в нашем случае мобильному приложению, примеры далее будут связаны с ними). В качестве таких требований выступает техническое задание, которое и оценивают разработчики.

Строгие сроки. Когда заказчик понимает, какие функции ему нужны в приложении, разработчики могут прийти к четкому плану и определенным срокам.

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

Модель с фиксированной ценой лучше всего подходит для небольших проектов с ограниченными возможностями и четкими требованиями. Это также хорошо для MVP и проектов с ограниченным бюджетом и определенными сроками.

"Аппетит приходит во время еды", а именно доработки. Все доработки, которые не оценивались с самого начала, должны попадать под дополнительное соглашение и оплачиваться отдельно. Жесткие условия.

Любые доплаты воспринимаются заказчиком плохо, если не сказать критично. Хочется за те же деньги сделать все-все. Были случаи, когда по причинам доработок останавливались проекты.

Риски недопонимания. Всегда существует риск, что недопонимание может привести к доставке продукта, который не совсем соответствует тому, на что рассчитывал клиент.

Масштабируемость таких проектов минимальна, с большой долей вероятности проект не получит продолжения.

Изменения на рынке. Внести правки в будущую мобилку не удастся просто так, а учесть все изменения и необходимость всех функций в том виде, в котором они описаны в ТЗ, нельзя.

Долгое планирование. Долго, очень долго тянутся договора с фиксированной ценой. Сначала напиши ТЗ, разработай дизайн, оцени ТЗ и дизайн, согласуй и только после этого начинай разработку.

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

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

Гибкие требования. Работа делится на короткие спринты и ведет к MVP. Все функции проверяются должным образом и могут быть добавлены или удалены в любой момент.

Почасовые ставки. Клиенты платят установленную почасовую ставку, которая была обговорена с самого начала. Оплата происходит по факту выполненных работ (в некоторых случаях с частичным авансом, так называемые гарантированные часы).

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

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

Неопределенные сроки. Любые изменения в проекте могут отложить окончательный выпуск и срок может быть большим.

Неопределенный бюджет. Цена является приблизительной, поэтому клиент не знает в самом начале проекта, сколько денег он потратит в итоге за весь проект.

Ресурсозатратность. Заказчик сам должен управлять временем и своими желаниями, больше "хочу" - дороже проект.

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

Эта модель хорошо работает для проектов с меняющимися требованиями и подходит для долгосрочных проектов. Крупных и современных клиентов. Такой тип договора применяется когда нет заданного объема работ и когда требуется большая гибкость.

ВАЖНО! Клиент должен быть готов действительно участвовать в проекте, так как его одобрение и видение являются самой важной частью развития проекта.

Модель ценообразованием Milestone подразумевает оплату по конкретным этапам, каждый этап фиксируется через ТЗ. Так же обязательно фиксируется сроки разработки. Как правило заключается отдельный договор на каждый этап разработки мобильного приложения и релиз каждого этапа является практически самостоятельным продуктом.

Оплата по достижению. Заказчик оплачивает только фактическую функциональность, предоставленную ему по предварительно согласованному ТЗ.

Контроль. Клиент проверяет до начала и после этапа верность указанных функций.

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

Нет фиксированной цены по этапам. Разные этапы с разной функциональностью оплачиваются по-разному. Стоимость всего этапа известна до начала работ.

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

Сроки. Поскольку планирование и выполнение проекта является итеративным, сроки на каждый этап не одинаковые, что не всегда позитивно сказывается на планировании сроков.

Нехватка доверия. Мало заказчиков, которые хотят работать по этой модели доверяют разработчику, предпочитая завершенные этапы (договор, акт).

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

Выбор конечно за вами!