Это снова наш клиент — Денис. Он уже разобрался, от чего зависит стоимость мобильного приложения и почему она может измениться во время разработки. Теперь Денис попросил подробнее объяснить, что такое смета на разработку приложения и зачем ему этот документ.
Денису говорили, что ему необязательно понимать, как считается смета — важно смотреть на конечную цифру. Мы же думаем, что, чем понятнее для клиента процесс формирования сметы, тем очевиднее для него ценообразование на проекте. В статье разберём:
- что такое смета разработки приложения и зачем она нужна;
- как считается смета мобильного приложения в картинках;
- как смета используется на проекте во время разработки;
- как помочь разработчикам сделать смету, которая будет совпадать с конечной стоимостью разработки;
- можно ли делать приложение без сметы.
Что такое смета разработки приложения и зачем она нужна
В строительстве смета — это документ, который показывает, сколько будет стоить дом: сколько нужно кирпичей, цемента, краски, всего-всего — и какая у этих составляющих цена.
В мобильной разработке так же, только вместо стройматериалов — артефакты разразработки и фичи. На каждом этапе свои. Стоимость каждого артефакта и фичи определяется количеством часов, которые специалисты потратили на разработку.
Артефакты мобильной разработки — это файлы, которые создаются в результате работы каждого специалиста на проекте. Базовый набор артефактов для создания приложения: функциональное задание, прототип, дизайн-концепция, технические заметки и готовый дизайн всех экранов
Создание каждого артефакта и фичи из проекта в проект может занимать у разработчика разное количество часов. Почему так? Задачи вроде бы похожи: здесь сделать личный кабинет и здесь, здесь сделать каталог и здесь. На это есть несколько причин:
- каждая фича нужна для разных целей и в каждом приложении она будет выглядеть по-разному;
- у каждой фичи будет свой «объём»: например, фильтрацию в каталоге можно сделать очень простой — цена, пол, размер (если мы говорим об одежде), а можно расширить её: добавить цвет, фасон, материал, рейтинг.
- у каждой фичи может быть разный способ реализации: например, карточка товара может состоять из фото, описания товара и кнопки «В корзину». Но эту же фичу можно реализовать сложнее: вместо одного фото — галерея-слайдер, увеличение изображений, публикация видео, оценка товара и многое другое.
Получается, что на разные задачи требуется разное количество часов. Всё это влияет на стоимость проекта и отражается в смете.
Как считается смета мобильного приложения: показываем в картинках
Когда мы общаемся с клиентом в первый раз, мы узнаём, ради какой цели бизнеса он хочет разработать мобильное приложение: увеличить онлайн-продажи, дать клиентам новую точку касания с бизнесом, повысить лояльность. Если мы понимаем, что мобильное приложение поможет ему, то обсуждаем проект в деталях и составляем смету на разработку приложения.Есть только один способ понять, подходит вашему бизнесу мобильное приложение или нет — обсудить идею проекта с экспертами. Напишите или позвоните нам +7 495 204-35-03 — услышим, поймём, расскажем, как мобильное приложение поможет бизнесу развиваться, и разработаем для ваших клиентов полезный сервис
Какие элементы включает смета на разработку мобильного приложения
1. Этапы и часы — это база всех подобных документов. В левом поле, которое будет отвечать за строки в таблице, мы прописываем этапы разработки: проектирование, дизайн, разработка бэкенда, мобильная разработка, тестирование и релиз.
В поле напротив — часы специалистов.
2. Конкретизация этапов — требования и пожелания клиента по работе мобильного приложения мы переводим на язык разработки: фиксируем их как те самые фичи и артефакты, о которых уже сказали выше. Декомпозируем эту функциональность и подробно расписываем, что сделаем на каждом этапе.
3. Оценка — после этого наши специалисты оценивают, сколько времени им потребуется, чтобы реализовать задуманное на каждом этапе. Напротив артефактов и фич появляется количество часов, необходимое для их разработки.
4. Стоимость проекта — после того, как функциональность оценена в часах, мы перемножаем часы на ставку специалистов и получаем ориентировочную стоимость проекта.
Где найти шаблон сметы на разработку приложения
С готовой сметой идём к клиенту, чтобы сориентировать его по стоимости и срокам разработки. Документ показывает, как мы декомпозировали задачи и во сколько их оценили, — клиент видит, за что будет платить деньги.
Если вы ещё не успели написать нам, но уже хотите посмотреть, как будет выглядеть смета — не беда. Мы подготовили для вас шаблон сметы, в котором примерный набор фич для eCommerce-приложения распределён по этапам разработки. Скачайте или скопируйте наш шаблон и вносите в него изменения, если вам это нужно.
Почему мобильные студии много внимания уделяют составлению сметы
Смета — это ориентир по ценообразованию для тех решений, которые мы зафиксировали на этапе пресейла. Она показывает наш подход к разработке проекта, глубину погружения и вовлечённость экспертов в потребности клиента.
Благодаря правильной и прозрачной смете к компании рождается доверие. Смета позволяет студии продемонстрировать свой подход к разработке — если этот подход близок клиенту, то клиент делает выбор в пользу команды.
Как смета используется на проекте во время разработки
Во время разработки команда будет опираться на смету как на образец того, что должно получиться в итоге. На основе сметы у нас появляется планирование сроков. мы заводим проект в систему, выписываем основные задачи, их примерную оценку и ее отображение в виде реальных трудовых дней. Визуализируем их с помощью диаграммы Ганта.
Получается, что смета показывает, чего мы хотели и помогает об этом помнить. Но не гарантирует, что на выходе приложение будет стоить столько же, сколько на входе. Проект может ждать переоценка.
Почему происходит переоценка проекта
1. Новые требования
Если меняются требования к приложению, то меняется и его стоимость. На этапе оценки мы только предполагаем, как может работать та или иная функция. И оцениваем её исходя из этих предположений. Нюанс в том, что предположение может сбыться, а может — нет.
Чаще всего предположения не сбываются из-за желания заказчика сделать проект лучше: приходит новая идея или появляется более качественное решение. И мы меняем что-то в процессе разработки. Это нормально, но влияет на стоимость.
Недавно к нам пришёл клиент, которому нужен был веб-сервис для оказания услуг клиентам в Москве. Мы сделали смету, подписали договор и приступили к разработке. Спустя два месяца клиент понял, что хочет масштабировать проект: 1) сделать его международным; 2) дать возможность другими компаниям продвигать услуги с помощью этого веб-сервиса.
Мы сделали переоценку проекта. В таком контексте получилось, что не «проект подорожал», а реализация нового веб-сервиса обошлась дороже, чем реализация его первой локальной версии
2. Изменение в способе реализации
На этапе пресейла не всегда понятно, какие решения и в каком объёме будут реализованы. Когда мы начинаем разбираться в проекте, оказывается, что некоторые решения, которые были приняты на пресейле, будут рабочими, но есть варианты получше. Мы предлагаем
их клиенту и обязательно оговариваем, что это повлияет на стоимость. Если клиент соглашается — вносим изменения и детализируем оценку.
Переоценка после аналитики и проектирования
После создания сметы начнётся первый этап разработки вашего приложения — этап аналитики и проектирования. Он помогает представить приложение в виде точной и логичной системы без слепых зон. Мы полностью спроектировали продукт, продумали все решения
вплоть до проработки аналитических систем и уже точно можем сказать, сколько времени нужно разработчикам для претворения задуманного в жизнь.
Пример 1
На пресейле мы с клиентом решили, что будем делать авторизацию в приложении через SMS. Оценили эту фичу в 4 часа работы для аналитика, 4 часа работы для дизайнера и 10 для разработчиков.
После заключения договора клиент решил делать авторизацию по логину и паролю. Для нас такой способ затратнее: нужно руками создать базу и подключить её к проекту, а не использовать то, что планировали изначально. Это повлияло на цену: аналитик и дизайнер так же сделали свою работу за четыре часа, но мобильным разработчикам понадобилось не 10 часов, а 20
Пример 2
У нашего клиента сильный отдел маркетинга. Они хотят отслеживать эффективность приложения и считать метрики. Но во время пресейла их требования к аналитике ещё не сформированы, поэтому мы оцениваем базовый набор метрик. К этапу проектирования клиент даёт нам список из 20 показателей, которые нужно отслеживать. Реализовать это — сложнее и дольше. Мы потратим больше часов, чем планировали изначально, а следовательно — работы будут стоить дороже
Какие документы фиксируют конечную стоимость работ
Как только вы понимаете, что хотите работать с нами, мы подписываем договор на разработку приложения. Конечная стоимость работ будет отображаться в приложениях к нему, или дополнительных соглашениях (ДС).
ДС составляются отдельно для каждого этапа разработки. В них мы пишем задачи на этап, за какой срок у нас получится их сделать, и сколько это будет стоить. Как только клиент подписывает дополнительное соглашение, мы незамедлительно приступаем к разработке.
С началом каждого нового этапа разработки клиента ждёт новое дополнительное соглашение, в котором указана стоимость работ. Мы не подписываем документы на все этапы заранее, потому что из-за изменений на предыдущем этапе цена последующих может измениться.
Как помочь разработчикам сделать смету, которая будет совпадать с конечной стоимостью разработки
Чем лучше клиент знает свой проект в самом начале пути, тем больше шансов, что стоимость приложения будет такой же, как указано в смете. Если будет хоть одно неизвестное, то нужно готовиться к тому, что стоимость приложения изменится в большую или меньшую сторону (но не больше, чем на 15-20%).
Чтобы смета была максимально близкой к финальной стоимости разработки, клиент может:
- подготовить бриф или ТЗ — если есть документы, в которых описана вся функциональность мобильного приложения, все интеграции, то для нас это идеальный вариант — мы сразу увидим, как должно работать приложение, и скажем, сколько это будет стоить;
- активно пользоваться схожими приложениями по функциональности — запоминать свой опыт, выделять что нравится, а что не очень и делиться этим со студией разработки — тогда нам будет очевидно, чего ждет клиент;
- закладывать риски — если на пресейле вы можете рассказать о проекте в общих чертах, то для нас надёжнее будет заложить в оценку риски: это предупредит всех участников процесса, что какие-то детали на проекте могут измениться, но меньше скажется на изменении цены;
- развивать MVP — можно начинать разработку приложения, в котором будут только базовые функции — такой проект быстрее запускается и легче масштабируется — новые функции добавляются постепенно.
Можно ли делать приложение без сметы
И при всём том, что мы сказали выше, есть два случая, когда смета на разработку приложения не нужна — это работа по договору аутстаффинга и по модели ретейнер.
1. Как работать по договору аутстаффинга
Если у вас уже есть приложение с планом развития, с командой менеджеров, но не хватает технических специалистов, которые могут воплотить задумку в жизнь, вам нужны аутстафф-разработчики. Это люди, которые устроены в штате одной компании, но по договору аутстаффинга имеют право временно работать в другой команде. Для этого им лишь нужно знать, какие задачи вы им ставите. Позвоните нам, чтобы нанять помощника для своего проекта +7-495-204-35-03.
2. Что такое ретейнер-модель
Ретейнер-модель — это работа над вашим проектом выделенной командой. Вы выбираете разработчиков, аналитиков, дизайнеров и тестировщиков, которые будут создавать проект с нуля, выкупаете их на несколько месяцев — и всё это время они занимаются работой только над вашим приложением. Это как инхаус-команда разработчиков, только уже собранная, обученная и готовая к действию прямо сейчас. Им не нужна смета, потому что вы формируете для них бэклог задач на месяц вперёд, и они работают над этими задачами. Если справляются с ними быстрей, то переходят к бэклогу на следующий месяц.
Как начать разработку мобильного приложения, если есть только идея
Мобильное приложение — это только витрина. За ней скрываются большие и сложные системы, бэкенд, административные панели, интеграции. Для клиента не знать, как это работает, — нормально. Хорошая студия разработки всегда объяснит и подскажет, как сделать мобильное приложение лучше — удобнее для пользователя и прибыльнее для бизнеса.
Если хотите стать подкованным заказчиком — скачайте нашу книгу по разработке приложений. Она написана простым, понятным языком и точно будет вам полезна. А если вы уже готовы к разработке мобильного сервиса — просто заполните форму, и мы вам перезвоним.