Разработка MVP для CRM или ERP системы

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

Зачем это нужно? Вот несколько причин:

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

Разберем пример из нашей практики.

К нам обратился клиент, компания “Все окна”. Совместно мы подготовили техническое задание на CRM систему. На основании задания мы сформировали смету на весь проект, она выглядит вот так:

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

Смета на MVP выглядела вот так:

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

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

Оставшиеся работы, которые необходимо выполнить после разработки MVP вошли в следующую смету:

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

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

Если создавать продукт без MVP, вы рискуете столкнуться с рядом проблем:

Проблема №1: Затягивание сроков разработки
Чем сложнее ваш проект, тем больше времени вам потребуется на составление технического задания (ТЗ). Если вы ожидаете, что команда разработает весь функционал сразу, это может затянуть сроки до неоправданных масштабов.

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

Проблема №2: Недостаток нужного функционала
Когда заказчики и конечные пользователи не совпадают, риск того, что конечный продукт окажется «не полезным», возрастает. Пользователю могут не хватать функций, которые, как кажется, были очевидны для заказчика.

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

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