Fixed Price или Time & Materials: по какой модели оплаты работать над MVP

У студий мобильной разработки бывают клиенты, которые наполняют понятие MVP своими смыслами и ожиданиями, не совпадающими со взглядами и возможностями студий. Не в последнюю очередь эти ожидания касаются того, как и в каком объёме нужно будет заплатить за создание приложения. Несколько неверных выводов и ошибок — и пострадают обе стороны. В этой статье хочется кратко пояснить, что такое MVP, по каким моделям можно оплачивать работу команды и в каких условиях подходит та или иная модель.

Что такое MVP

Минимальному жизнеспособному продукту (он же Minimum Viable Product, или MVP) википедия даёт такое определение: это продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. MVP помогает за относительно небольшие деньги понять: либо ваше приложение приживётся на рынке и его стоит развивать, либо вам лучше отказаться от него в пользу чего-то более полезного. Поэтому MVP подходит стартаперам.

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

Что такое Fixed Price и Time & Materials

Разработку мобильного приложения клиент студии может оплачивать по двум моделям.

Fixed Price

С такой моделью в техническом задании на проект указываются конкретные условия для выполнения задачи, команда оценивает, сколько времени задача займёт, и клиент оплачивает только это время. Отношения между клиентом и командой при такой модели очень формализованы и не допускают ни шага в сторону от того, что указано в документах, поэтому стоимость и называется фиксированной (англ. fixed).

Time & Materials

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

Какую модель выбрать?

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

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

Если клиента и команду устраивают эти рамки, то Fixed Price — подходящая модель.

В условиях, когда в любой момент может понадобиться упростить функциональность, изменить её или весь продукт вплоть до бизнес-модели, студия, скорее всего, предложит клиенту работать по Time & Materials. Клиенту нужно быть готовым к тому, что на фоне нефиксированных требований бюджет может растягиваться во все стороны.

Альтернативой обеим моделям является модель Retainer. Она подходит таким клиентам, которые готовы выкупить команду на долгий срок и оплатить все человеко-часы каждого её члена, лишь бы получить желаемый результат. Проекты, как правило, большие, серьёзные, дорогие и трудоёмкие.

Как превратить Time & Materials в Fixed Price

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

1. разработка разделена на этапы, и всё самое важное реализуется на первом. Нужно, чтобы он не занимал больше 2–3 месяцев;
2. на первом этапе провести техническое проектирование;
3. быть готовым к тому, что после этого этапа понадобятся новые фичи, а вместе с ними и техническая аналитика. Это отразится на стоимости следующих этапов.

Создавая MVP по Fixed Price, Лайв Тайпинг делит риски со своими клиентами. Мы забираем на себя риски, связанные с техническим проектированием, аналитикой и разработкой, а клиенты — риски, связанные с бизнес-аналитикой. Иначе говоря, если мы подобрали неправильную технологию или разработчик подумал, что выполнит задачу быстрее, чем оказалось на самом деле — отвечаем мы; если за прошедшее время рынок с его лидерами, принципами существования и трендами поменялся настолько, что продукт со своей функциональностью оказался неуместным — отвечает клиент. Именно поэтому нужно отказаться от Fixed Price или делить проект на маленькие этапы: если рынок все-таки поменяется, не придётся создавать ненужную функциональность только потому, что мы об этом договорились и зафиксировали в документах.

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

Что будет, если пренебречь профессиональным техническим проектированием? Расскажем на примере одного из наших проектов. В приложение клиента нужно было интегрировать чат-сервис. Клиент исследовал возможные технические решения сам (читай: взял проектирование на себя), а нам дал на выбор несколько сервисов, чтобы мы решили, какой больше подходит. Мы выбрали сервис, А, потому что он подходил проекту по набору методов API, а с точки зрения разработки и интеграции был лучше, чем сервис Б. Мы не проектировали работу сервиса с нашей инфраструктурой и кроме названных формальных критериев больше ничего не проверяли: ни стабильность работы, ни скорость отклика, ничего — это исследовательские задачи, которые не предполагались в рамках задачи «интегрировать чат». Чат в итоге отзывался медленнее, чем мог, если бы было время на проверку. На этом проекте было ещё очень много сложностей, но спасти команду и закончить этап помогла стратегия, о которой я рассказываю в своей статье для Хабра.

Итак, большие проекты всегда нужно делить на этапы, первым из которых должно быть техническое проектирование. Это даёт клиенту возможность оплачивать работу студии по Fixed Price.

Заключение

Решение, какую модель оплаты выбрать, зависит и от ваших финансовых возможностей, и от срочности, и от развитости самого рынка, на который вы нацелены. Готовы сотрудничать в рамках техзадания и нормально воспринимать отказ студии делать то, что в него не попало? Ваша модель — Fixed Price. Чувствуете, что требования к продукту будут меняться? Выбирайте Time & Materials. Требования будут меняться, но Time & Materials не для вас? Делите разработку на этапы и не пренебрегайте проектированием.

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