Как формируется стоимость разработки мобильного приложения?

Сколько стоит сделать приложение? Можно собрать самому на конструкторе за Х тысяч рублей. Можно заказать фрилансеру за ХХ тысяч. Совсем хорошо заказать у студии за ХХХ тысяч. Или у крупной студии за Х миллионов. Вопрос ценообразования в мобильной разработке сродни гаданию на кофейной гуще (кстати, вы слышали про многомиллионный турецкий стартап?) — вы видите смутные очертания продукта и пытаетесь понять, сколько он вам будет стоить.

Однако можно и вполне реально оценить, сколько будет стоить разработка. Цена приложения по большей части зависит от:

• Необходимого функционала (front и back end), ЦА и самой идеи
• От стоимости часа работы вашего подрядчика
• От количества платформ, на которых должно работать приложение
• От наличия или отсутствия дизайна

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

Допустим вы понимаете, что и для кого вы делаете, можно переходить ко второму этапу — оценке стоимости работы над приложением. В совсем общем виде в работе над приложением вам нужен:

• Аналитик*, который пишет документацию на проект.
• Проджект менеджер, который управляет процессами и ведет общение с заказчиком (даже если он внутренний).
• Один или несколько разработчиков, которые пишут код.
• Дизайнеры, разрабатывающие интерфейс и определяющие UX
• Тестировщики*, которые находят ошибки в работе разработчиков и дизайнеров.

* Аналитики и тестировщики не всегда бывают “выделенными”, иногда их роли выполняют другие работающие над проектом — например, тестирование проводят сами разработчики.

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

Практически любое приложение состоит из во многом идентичных блоков — для магазина, например, это список товаров, корзина, личный кабинет и т.п. Музыкальный плеер (кто сказал Spotify?) — плейлистов, подборок, самого потокового плеера.

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

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

Примерно оценив весь проект в часах разных специалистов и, соответственно, деньгах, у вас и у партнера, который реализует проект, возникнет развилка в принятии решения. Это вариант оплаты — вы можете платить целиком за весь проект (фикс) либо по модели T&M (Time and Materials), когда оплата происходит за рабочий процесс. И в том и в другом варианте есть свои преимущества и недостатки и вам, как заказчику, нужно понимать преимущества и недостатки каждой модели.

Заключается договор на реализацию приложения согласно техническому заданию, за указанную цену, в указанные сроки, с фиксированным объемом работ.

Плюсы:

• Законченный проект, который реализуется от и до согласно прописанному техническому заданию. Хорошо подходит для небольших проектов.
• Фиксированный бюджет, превышение которого вряд ли возможно.
• Управление проектом на стороне разработчика — технические знания если и нужны, то на уровне составления ТЗ.

Минусы:

• Сложно внести изменения в проект в ходе работы над ним.
• Поэтому очень важно как можно тщательнее подойти к составлению ТЗ и прописать в нем все нюансы и вопросы реализации проекта.
• Стоимость может быть больше, чем в T&M варианте, так как разработчик закладывает в нее все риски и неопределенность.

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

Плюсы:

• Та самая гибкая разработка — требования и функционал можно менять прямо в процессе разработки. Хорошо подходит для больших сложных проектов.
• Прозрачная разработка — вы видите все процессы, трудозатраты, получаете промежуточные результаты и можете (например, с помощью сторонней помощи или своих разработчиков) контролировать их качество.
• Экономия бюджета — понимаемость и прозрачность каждого этапа дает возможность аутсорсеру не закладывать все риски в бюджет проекта.
• Возможность аудита кода и архитектуры в процессе работы над проектом. Если качество не устраивает, то относительно безболезненно можно передать проект другой команде.

Минусы:

• Бюджет не определен — сколько понадобиться “времени и материалов” на весь проект на момент его начала всегда сказать трудно. Да, по факту сделать такой же проект на фиксе наверняка будет дороже, но что будет значить “такой же” в начале понять достаточно сложно.
• В T&M парадигме не стоит отходить от первоначальных рамок проекта, так как может очень сильно измениться время и стоимость разработки.
• Нужна более сильная (по сравнению с фиксом) вовлеченность в проект. Заказчику нужно вести постоянные коммуникации с исполнителем.
• Возможно столкнуться с завышением трудозатрат и, соответственно, цены каждой итерации.

Стоимость создания приложения понять достаточно просто — умножить количество часов на стоимость часа. Однако на любую из переменных в этом уравнении может влиять множество факторов.

Например, на количество часов может влиять:

• Сложный дизайн и большое количество сложных анимаций.
• Интеграция с нестандартными системами на стороне заказчика.
• Отсутствие точного понимания функционала и, как следствие, постоянное переписывание и/или дописывание кода.

• Разработка кроссплатформенных решений

На стоимость часа:

• Использование “сложных” технологий и фреймворков, знакомых лишь дорогостоящим специалистам.
• Местонахождение компании — аутсорсера и его “понты” (рейтинг, позиционирование, “светлый просторный офис, печеньки для разработчиков” и т.п.).

• Длительность проекта.

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

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

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