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

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

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

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

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

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

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

Вот переписанный текст:

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

●     Объем функций.

●     Квалификация команды разработчиков.

●     Качество технического задания (ТЗ).

●     Выбранный стек разработки и другие аспекты.

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

С каждым годом все чаще возникает один из острых вопросов — смогут ли машины заменить человека. Например, нейронные сети справляются с задачей написания кода не хуже начинающих разработчиков*, а иногда и лучше. Тем не менее, вопрос сокращения рутинных операций при написании кода разрабатывался в IT-сфере задолго до появления нейросетей. Различные технологии, включая кодогенераторы, которые заменяют типовые наборы операторов одной строкой кода, были разработаны для нескольких популярных языков и успешно применяются в разработке IT-продукта.

*Начинающий разработчик (джун) — это человек, не обладающий достаточным опытом.

Кейс

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

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

●     Пользователь загружает один CSV-файл с данными размером до 10 МБ.

●     Выбирает параметры.

●     Отправляет файл и параметры на сервис заказчика.

●     Видит на экране два графика и таблицу с данными, которые можно сохранить в формате PDF.

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

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

Схема 1.

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

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

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

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

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

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

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

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

●     Конечных точек на стороне заказчика пока нет, но они появятся в ближайшее время, что может привести к простоям в разработке из-за возможных недоработок системы интеграции.

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

○     Файлы пользователей необходимо хранить в файловом хранилище.

○     Обучающие материалы должны сохраняться в базе данных (БД), хотя в изначальном ТЗ это не предусматривалось.

●     Количество загружаемых файлов — до 40 штук, при этом размер каждого из них может достигать 100 МБ, что существенно увеличивает нагрузку на систему по сравнению с первоначальными требованиями.

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

(Схема 2)

Однако перед нами оставалась ключевая задача: разработать вспомогательное MVP в сжатые сроки — не более одного месяца. Это означало жесткое ограничение:

●     Frontend-разработка зависела от готовности backend, что влияло на общую архитектуру проекта.

●     На backend-разработку было заложено максимум 3 недели (120 часов), что соответствовало первоначальной оценке.

●     Ограничение бюджета не позволяло привлечь больше одного backend-разработчика.

В таких условиях было два возможных решения:

1. Убедить заказчика увеличить сроки или бюджет.
2. Оптимизировать процесс разработки, чтобы уложиться в согласованные рамки.

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

Эффективность этого подхода можно наглядно представить в следующей таблице:

Оценка и перерасчёт времени разработки MVP

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

Сравнение исходного и уточнённого ТЗ:

1. Авторизация и права доступа
2. 
   

○     В исходном ТЗ: стандартная авторизация, разделение прав доступа, подтверждение аккаунта через почту.

○     В уточнённом ТЗ: без изменений.

○     Оценка времени: 20–30 часов (фактически затрачено – 1 час, благодаря кодогенерации).

1. Обработка CSV-файлов
2. 
   

○     Изначально: загрузка одного CSV-файла до 20 МБ на фиксированную конечную точку.

○     В уточнённом ТЗ: загрузка массива файлов (до 40 штук, до 100 МБ каждый), передача результатов между несколькими конечными точками.

○     Оценка времени: увеличена с 10–15 часов до 20–25 часов (фактически затрачено – 20 часов).

1. Парсинг и передача данных
2. 
   

○     Изначально: получение CSV-файла, его парсинг и отправка данных на frontend.

○     В уточнённом ТЗ: разбор zip-архива, парсинг нескольких CSV-файлов, преобразование данных в JSON и передача их на frontend.

○     Оценка времени: увеличена с 20–25 часов до 25–30 часов (фактически – 30 часов).

1. Хранение истории экспериментов
2. 
   

○     Без изменений.

○     Оценка времени: 15–20 часов (фактически – 0,5 часа, за счёт автоматизации).

1. История действий пользователей
2. 
   

○     Без изменений.

○     Оценка времени: 10–15 часов (фактически – 0,5 часа).

1. Хранение файлов
2. 
   

○     Изначально: сохранение CSV и PDF в базе данных.

○     В уточнённом ТЗ: запаковка файлов в zip-архив, хранение их в файловом хранилище, фиксация данных в БД.

○     Оценка времени: увеличена с 15–20 часов до 35–40 часов (фактически – 40 часов).

1. Определение конечных точек для отправки данных
2. 
   

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

○     Оценка времени: 30–40 часов (фактически – 30 часов).

Итоги:

●     Исходная оценка: 90–125 часов.

●     Оценка после уточнений: 155–200 часов.

●     Реально затрачено: 124 часа (включая 2 часа на настройку кодогенерации).

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

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

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

1. Разделение backend и frontend
2. 
   

○     Кодогенератор создал единый проект, содержащий как backend, так и frontend.

○     В итоге пришлось потратить около 30 минут на их разделение и перенос нужных частей в рабочий репозиторий.

1. Сложность чтения кода
2. 
   

○     Автоматически сгенерированный код тесно связан с внутренними компонентами кодогенератора.

○     Это снижает читаемость и может усложнять даже простые операции.

1. Избыточность кода
2. 
   

○     Кодогенератор создаёт универсальный код с дополнительными настройками, системами мониторинга и конфигурациями для деплоя в контейнере.

○     Если эти функции не требуются в MVP, их приходится вручную удалять или мириться с излишними элементами в проекте.

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

Комментарий backend-разработчика

«Для созданной структуры базы данных мы автоматически получили полный набор CRUD-операций и всю цепочку классов, реализующих их. Кроме того, кодогенератор предоставил готовую реализацию авторизации через JWT-токен, включая работу с почтой. Однако в процессе работы возникли сложности:

1. Ограничения на связи между таблицами
2. 
   

○     Кодогенератор не позволил включить таблицу пользователей в бизнес-логику в связке с другими сущностями.

○     Пришлось искать обходные пути, чтобы обеспечить нужные взаимосвязи.

1. Проблемы с онлайн-генерацией кода
2. 
   

○     Автоматическая генерация в репозиторий срабатывала не всегда.

○     Сообщение об успешной генерации появлялось, но кода фактически не было.

○     В результате часть кода пришлось генерировать на локальной машине, используя дополнительные плагины.

Несмотря на эти нюансы, кодогенерация позволила сократить время разработки, особенно на рутинных этапах, таких как настройка CRUD-операций и авторизации.»

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

Финальный вариант MVP благодаря кодогенерации уложился в запланированные сроки и был успешно завершен. Автоматическая генерация типовых компонентов (авторизация, создание БД, основные CRUD-операции) позволила высвободить время на проработку специфической бизнес-логики, которая не была очевидна на старте.

Выводы

1. Кодогенерация ускоряет разработку, но требует квалифицированного подхода. Разработчик должен понимать, как работает сгенерированный код, и уметь его адаптировать.
2. Нельзя использовать кодогенерацию в чистовом репозитории. Оптимальный подход – переносить только необходимые фрагменты кода с четким пониманием их назначения.
3. Кодогенерация полезна и для frontend-разработки, но только в отсутствие макета. Если UI уже определен, доработка сгенерированного кода может занять столько же времени, сколько и написание интерфейса с нуля.
4. ER-диаграмма – основа успешной кодогенерации. Структуру данных нужно продумывать заранее, чтобы избежать серьезных изменений в процессе разработки.

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

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

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

Однако важно учитывать ограничения:

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

●     С точки зрения бизнеса кодогенерация помогает снизить затраты на разработку MVP без потери качества, поскольку использует наработки профессионального сообщества. Это делает её отличным инструментом для быстрого тестирования гипотез.

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

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