Из чего состоит стоимость разработки MVP приложения

Работая со стартапами, мы часто сталкиваемся с тем, что все хотят мегакрутой технологичный проект, а сколько стоит его разработка — понимания нет.

Стали часто встречаться варианты: в долю (а, значит, делать бесплатно), скидка за долю — студиям разработки абсолютно невыгодно и неинтересно, потому что необходимо содержать сотрудников. Всё это уже выглядит несерьезно, появляется много рисков и ответственности.

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

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

Проблема на рынке стартапов

Очень часто заказчик еще не знает, как будет развиваться его проект (ещё нет полноценной дорожной карты). Из-за этого многие детали очень плохо прописаны, их трудно оценить в рублях.

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

Примечание

Для аутсорсинговых компаний стартап — это набор технологий и прикладных задач. Бывают сложнее, бывают проще, зачастую по своей сути они сводятся либо к интернет-магазину, либо CRM, ERP, агрегаторам, мессенджерам (то есть модульности).

Вся инновационность и сложность разработки будет упираться в вашу дорожную карту, в сценарии использования и автоматизацию бизнес процессов.

На примере одного из стартапов, который метит на международный рынок, покажем типичный запрос на просчёт. Разработка мессенджера (чата).

Первое описание приложения было таким:

Нужен дизайнер и разработчик для разработки MVP мобильного приложения (мессенджер).

«Функционал чата будет аналогичен всем другим существующим приложениям. Единственное отличие от остальных — авторизация будет несколько иной. Еще несколько особенностей: загрузка фото в профиль, SMS-уведомления, интеграция с базой данных…»

Соответственно, мы можем назвать только вилку цен за MVP с минимальной функциональностью — от 350 до 800 тысяч рублей. А это большой разброс цены, поэтому мы предложили обсудить подробнее некоторые моменты, ведь они сильно влияли на стоимость. Вот несколько таких пунктов:

  • Максимальная нагрузка на MVP.
  • Как выглядит администраторская часть сервиса.
  • Сколько дополнительных функций: групповые пересылки сообщений, цитирование, ответы, уведомления о действиях.

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

Итак, из чего складывается разработка MVP приложения:

  • Предварительное техническое задание (спецификация).

  • Прототипирование экранов (эскизы) — корректировка ТЗ.
  • Подробное ТЗ и разбиение на этапы.
  • Дизайн UX/UI.
  • Разработка функциональности приложения.
  • Запуск на тестовом сервере и тестирование.
  • Доработка ошибок, либо логических несоответствий.
  • Полнофункциональный релиз для всей аудитории.
  • Поддержка.

Примечание

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

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

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

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

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

Примечание

Подробнее о стоимости ошибок и пользе написания ТЗ можно почитать в книге Стива Макконнелла «Совершенный код» на странице 27.

Данные говорят, например, о том, что дефект архитектуры, исправление которого при проектировании архитектуры обходится в $1000, может во время тестировании системы вылиться в $15 тысяч

Стив Макконнелл, «Совершенный код»

В среднем стоимость разработки будет варьироваться от 1000 до 3000 рублей в час специалистов — в зависимости от их специализации в рамках одной ИТ студии.

Так будет выглядеть правильная смета на предварительном обсуждении

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

Пример сметы (по функциональности)

Итого:вы получаете ориентировочную стоимость вашего MVP.

Примечание

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

Советы заказчику:

  • Вы можете разослать в разные студии свой запрос для сравнения стоимости работ.
  • Нанять свою команду (но не забывайте, что вам необходимо будет самостоятельно закрывать множество задач, вести проект, искать, контролировать специалистов, описывать задачи, отвечать на вопросы оперативно. Ещё не забывайте про косвенные расходы: оплату офиса, оплату всех налогов и сопутствующих расходов на инфрастрктуру.)
  • Сфокусироваться только на главном и убрать все фичи, которые нередко съедают очень много времени, и сделать только то, что будет приносить пользу сейчас.
  • Подробное описание задач. Хороший пример есть у Ивана Замесина — про плохое описание задач и сколько это стоит в рублях (цитируем): «Я сам часто страдаю тем, что ставлю задачки: "сделать Х". И плачу деньги за последующие итерации. А каждая итерация это минимум четыре переключения контекста (одно переключение контекста — 20 минут), в среднем 10+ переключений контекста. То есть лень тщательно описать задачку с первого раза приводит к тому, что я плачу 10 * 0,3 (минуты в часы) * 1500 рублей в час (стоимость часа разработчика, менеджера) = 4500 рублей. Только на переключениях контекста. А есть ещё погружение в контекст кода, контекст задачи. Десятка минимум улетает в трубу лени».

Почему мы считаем в нашем примере по time & material, а не fix price

Потому что так выгоднее для стартапа, ведь в fix price обычно студия закладывает большие риски, в связи с этим наценка может стать не очень выгодной (но важно учесть: вам выгодно работать по time & material с теми, у кого есть релевантный опыт работы).

Заключение

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

0
74 комментария
Написать комментарий...
Denis Beskov

А зачем делать MVP приложения, а не продукта/услуги?

Ответить
Развернуть ветку
Дмитрий Яковенко
Автор

Услуги заказывают разные, если заказчик заказывает услугу по формированию продукта и тестированию гипотез для стартапа, в этом случае, мы сначала подсчитываем экономическое обоснование, даже для мелких фич. Пример проекта с экономическим обоснованием здесь https://vc.ru/dev/87003-terminalnaya-set-kompanii-po-vydache-i-vozvratu-zaymov-na-nedvizhimost-i-avto

Ответить
Развернуть ветку
Denis Beskov

я к тому, что большинству заказчиков не надо сразу делать софтверный MVP, достаточно собрать услугу из подручных средств

например, у заказчика возникла идея мобильного сервиса по быстрому поиску няни (a-la Uber для нянь)

чтобы оценить спрос, проверить ценностное предложение, проверить возможность нанести ценность клиенту, выявить подводные камни, достаточно:
- найти 30 нянь на районе через Авито/другие сервисы, провести их фильтрацию на вменяемость
- создать табличку с графиком занятости нянь в Google Doc
- запустить контекстную рекламу
- посидеть на звонках, сводя клиентов и нянь вручную

после этого можно уже даже не MVP делать в коде, а полноценную первую версию

Ответить
Развернуть ветку
Дмитрий Яковенко
Автор

Да, когда появляется идея, нужно идти и продавать, лучше всего сразу вживую, чтобы прочувствовать всю боль продаж))

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

Ответить
Развернуть ветку
Illia Martyn

Зачем заказчику вообще писать софт, пока он не проверил гипотезы спроса и не нашел product market fit?

Кому нужен такой MVP, кроме студии, которая заработает денег на разработке? 
Если план написать софт и дальше привлечь денег на тестирование гипотез, то это так не работает, прямо никогда. 

Ответить
Развернуть ветку
Дмитрий Яковенко
Автор

А вы внимательно прочитали статью? Проверка гипотез и т.д это отдельная тема для отдельной статьи. В рамках этой статьи она не рассматривалась) 

Ответить
Развернуть ветку
Illia Martyn

Не вижу ни одного слова "гипотеза" в статье

Ответить
Развернуть ветку
Darya Babaytseva

потому что это сделано ранее заказчиком, и на основе обратной связи были составлены требования. Здесь речь не о проверке гипотез, студия разработка этого делать и не должна. А речь о создании минимальной жизнеспособной версии на основе проверенных гипотез. Поэтому ни одного слова вы здесь и не увидели о "проверке гипотез студией разработки". Т.к. это заказ. Осознанный заказчиком выбор на основе его данных.

Ответить
Развернуть ветку
Denis Beskov

MVP делается для проверки гипотез. Если гипотезы проверены, то не надо minimum viable, можно уже нормальную первую версию делать

Ответить
Развернуть ветку
Darya Babaytseva

хорошо, пусть будет минимальная первая версия. Суть от этого у текста не изменилась)

Ответить
Развернуть ветку
Артем Летюшев

Эм, загуглите пожалуйста mvp и посмотрите что это. Здесь речь о минимальном жизнеспособном продукте, а не проверке гипотез.

Ответить
Развернуть ветку
71 комментарий
Раскрывать всегда