Стоимость разработки MVP: как сохранить качество и при этом сэкономить

Задача любого владельца продукта или компании на начальном этапе выхода на рынок — убедиться, что идея для бизнеса жизнеспособна. Это можно сделать с помощью MVP (minimal viable product, минимально-жизнеспособный продукт).

С чего начать разработку IT-системы: гайд по созданию MVP

Узнать подробнее

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

Про MVP и кодогенерацию

Основное назначение MVP (minimal viable product) — как можно быстрее вывести на рынок решение заданного качества с наименьшей стоимостью. Цель разработки MVP — проверить будет ли «работать» бизнес-гипотеза: заинтересует ли продукт аудиторию, получится ли развить продукт на рынке, «закроет» ли он необходимые потребности клиентов и так далее. Попробуем представить в таблице ниже среднюю стоимость на услугу разработки MVP. 

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

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

В разработке MVP будут принимать участие: аналитики, менеджеры проектов,  разработчики (backend, frontend, mobile), UX/UI-дизайнер? специалисты по обеспечению качества. Это примерный перечень членов команды, который может меняться в зависимости от проекта MVP и бюджета.

Dream Team: кто входит в идеальную ИТ-команду

Читать подробнее

На стоимость разработки MVP приложения влияют разные факторы:

1. Объем функций.
2. Квалификация команды разработчиков.
3. Качество технического задания (ТЗ).
4. Выбранный стек разработки и другое 

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

Кейс

К нам обратился заказчик из сферы производства для создания MVP портала управления данными. Пользователи через этот сайт должны иметь возможность загружать свои данные для анализа на сервис заказчика и получать отчеты по результатам обработки. Наиболее релевантный пример подобного портала — Albato. 

Технически на портале, который мы должны были разработать, это происходит так: 

1. пользователь загружает один CSV-файл с данными размером до 10 МБ;
2. выбирает параметры;
3. отправляет файл и параметры на сервис заказчика;
4. видит на экране два графика и таблицу с данными, которые можно сохранить в PDF. 

Если смотреть на процесс глазами backend-разработчика (далее по тексту — бэк), то загруженный CSV-файл отправляется на конечную точку на сервере заказчика (сервис обработки данных) и в ответ присылается CSV-файл, результат которого и надо отразить визуально (на frontend).  

С точки зрения бэка логика работы продукта следующая ↓

Схема 1.

С учетом того, что история пользовательских экспериментов сохраняется в базе данных (далее — БД), разрабатываемый сайт — это не просто маршрутизатор данных, а MVP полноценной системы с хранением, поиском и управлением доступом (пользователь может видеть только свои эксперименты). В случае с маршрутизатором бэкенд-части практически бы не было (простое перенаправление запроса), а этот случай предполагает БД и механизмы контроля доступа. Поэтому при разработке потребовалось оценить, в том числе и бэк-разработку.

Оценка и расчет разработки MVP

Исходная оценка проекта в часах для бэк-разработки получилась около 90-125 часов, включая риски. То есть в оценку MVP заложили потенциальные дополнительные затраты, которые могут возникнуть при появлении различных непрогнозируемых факторов.

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

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

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

• пользователь будет загружать на сайт массивы файлов, которые нужно не просто передать дальше, а еще и обработать; 
• конкретная конечная точка на сервере заказчика, куда отправляются данные, должна определяться заданными параметрами. Планируется развернуть несколько порталов, набор конечных точек для каждого портала может быть разным и будет задаваться на этапе деплоя (развертывания и запуска) приложения на сервер. То есть необходимо разработать алгоритм для реализации этого механизма;
• после обработки массива файлов одним сервисом результаты передаются для обработки другому сервису на стороне заказчика, хотя в изначальном ТЗ подобных цепочек передачи данных не предполагалось;
• конечных точек на стороне заказчика пока нет, но вот-вот будут. То есть возможны простои в разработке из-за недоработок системы для интеграции;
• на главной странице надо разместить обучающие материалы — файлы, которые можно скачать. При этом файлы пользователя необходимо хранить в файловом хранилище, а файлы с обучающим материалом – в БД, о чем в изначальном ТЗ не упоминалось;
• файлов может быть до 40 штук и объём каждого из них может доходить до 100 Мб, то есть требования к нагрузке на систему сильно отличаются от изначального ТЗ.

После уточнений требований с точки зрения бэка логика работы продукта получалась следующая:

Схема 2.

Такие (казалось бы, незначительные) детали играли важную в роль оценке времени на разработку MVP. Подобные нюансы могут как увеличить, так и сократить часы, которые затрачивает специалист. В итоге рабочей командой была сделана новая оценка (также с рисками): время разработки выросло до 155-200 часов.

Однако по-прежнему стояла задача разработать лишь вспомогательное MVP, то есть на весь проект целесообразно было потратить не больше месяца. И тут стояло ограничение: некоторые функции frontend могли быть реализованы только после бэкенда. То есть на общую архитектуру проекта и backend-разработку заложено максимум 3 недели или 120 часов, которые были согласованы при первоначальной оценке. Кроме того, из-за ограничения по бюджету на разработку MVP для разработки бэка могли привлечь только одного специалиста.  

В таких ситуациях есть два варианта решения:

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

Наша команда решила пойти по второму пути и для backend-разработки использовать технологию кодогенерации, покрыв ею типовые моменты в реализации MVP продукта. 
Это можно проиллюстрировать следующей таблицей:

Подводные камни кодогенерации

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

1. Код для backend и frontend сгенерировался в одном проекте, то есть пришлось потратить около получаса на то, чтобы их разделить и вытащить только нужное в рабочий репозиторий. 
2. Многое завязано на внутренних компонентах кодогенератора, что не добавляет читаемости коду и иногда усложняет даже элементарные моменты.

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

Комментарий backend-разработчика: «Для разработанной структуры БД мы получили весь набор CRUD-операций и всю цепочку реализующих его классов. Реализация авторизации через JWT-токен шла «из коробки», включая работу с почтой. Но и тут столкнулись со сложностями:
1. кодогенератор не позволил включить таблицу пользователей в бизнес-функции в связке с другими сущностями, пришлось искать обходной путь.
2. онлайн-кодогенерация в репозиторий не всегда срабатывала. Сообщение об успешной генерации кода было, а самого кода не было. То есть часть кода пришлось генерировать на локальной машине, используя дополнительные плагины»

Тем не менее в нашем случае кодогенерация существенно ускорила разработку MVP в части авторизации, создания БД и основных CRUD-операций, поэтому время, которое пришлось потратить на решение проблем, оказалось незначительным.

Итоги разработки MVP с помощью кодогенерации

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

• Кодогенерация позволяет ускорить разработку приложений. Но чтобы использовать технологии, необходимо быть квалифицированным разработчиком и понимать, как они работают. 
• Для MVP не рекомендуется использовать кодогенерацию в чистовом репозитории. Сгенерированное решение должно переноситься «по кускам» с пониманием, зачем тот или иной фрагмент помещается в проект.
• Кодогенерация подходит не только для backend-, но и для frontend-разработки. Но только если нет макета пользовательского интерфейса. Иначе адаптация под макет «съест» весь возможный выигрыш при разработке MVP.
• Диаграмма взаимосвязей сущностей предметной области (ER-диаграмма) является отправной точкой для работы кодогенерации. А значит, её надо хорошо продумать, чтобы она была неизменяема.

Выводы по ускорению разработки MVP

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

Разработка на Flutter: MVP аграрного маркетплейса

Читать подробнее

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

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

Хотите получить консультацию по вашем MVP? Связаться с нами, чтобы обсудить подробнее об услуге или можно по телефону по телефону 8-800-200-99-24, по электронной почте или в telegram.