Сколько времени занимает разработка MVP? Реальные сроки по типам продуктов

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

Те же категории определяют бюджет. В статье о том, сколько стоит SaaS MVP, есть диапазон цен для каждой.

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

Telegram Mini App обычно попадает в простую или среднюю категорию. Он открывается внутри Telegram, поэтому публиковать его в магазине не нужно, а аккаунт пользователя берётся из самого Telegram.

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

• Оценка. Ваш бриф превращается в предложение с объёмом, сроком и ценой. В Sakura большинство предложений уходит в течение 2–3 рабочих дней после заполненного брифа.
• Дизайн. Сначала пользовательские сценарии, потом экраны из системы повторно используемых компонентов, потом кликабельный прототип.
• Разработка. Фронтенд, бэкенд и интеграции, а каждую неделю рабочая сборка, которую можно прокликать.
• Тестирование. Все сценарии в согласованных браузерах и на устройствах, плюс скорость и базовая доступность.
• Запуск. Развёртывание, аналитика, публикация в магазине, если есть мобильное приложение, и первые исправления после прихода реальных пользователей.

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

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

Решение в том, чтобы проектировать в тех же компонентах, которые будут собирать разработчики. Тогда утверждённый экран почти готов, а вопросы решаются, пока это дёшево.

Например, AutoIntel, B2B-инструмент для немецкого рынка подержанных автомобилей, начинался с дизайна продукта и интерактивного прототипа на примерах объявлений. Клиент провёл свою команду по прототипу и определил, какие поля и фильтры важны, до того как оценивался сбор данных. Такой порядок держит самую дорогую часть разработки сфокусированной на том, что действительно нужно интерфейсу.

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

Некоторые функции выглядят мелкими в брифе, а в разработке добавляют недели. Следите за этими:

• Интеграции. Платежи, сервисы входа, CRM и сторонние API: каждая требует настройки, обработки ошибок и тестов.
• Роли и права. Каждая новая роль умножает число состояний, которые должен обработать каждый экран.
• Нативное мобильное приложение. Это второй фронтенд и модерация в магазине. App Review от Apple проверяет минимум 50% заявок меньше чем за 24 часа и 90% меньше чем за 48 часов, но отказ запускает отсчёт заново.
• Несколько языков. Каждая строка, сообщение об ошибке и подсказка должны существовать на каждом языке, а вёрстка должна вмещать самый длинный вариант.
• Поздние материалы. Тексты, цены, юридические документы и реальные данные, которые приходят в последнюю неделю, блокируют тестирование.
• Медленные решения. Вопрос, который неделю ждёт ответа, задерживает всё, что строится поверх него.

Срок MVP сокращают, делая меньше, а не хуже. Больше всего времени экономят эти решения:

• Урезайте целые сценарии, а не проработку. Переносите второстепенные сценарии в следующий релиз вместо того, чтобы делать каждый наполовину.
• Запускайтесь сначала в вебе. Адаптивное веб-приложение работает на телефоне и компьютере и не проходит модерацию в магазинах.
• Используйте проверенные сервисы. Готовая страница оплаты, существующие сервисы входа и рассылок быстрее и надёжнее собственных версий.
• Решайте быстро. Назначьте одного человека, который может утверждать макеты и отвечать на вопросы в течение дня.
• Тестируйте рано на нескольких пользователях. Исследование Якоба Нильсена показало, что тестирование на 5 пользователях выявляет большинство проблем удобства, поэтому несколько маленьких раундов лучше одного большого.

CarPixly, ИИ-фотостудия для автомобильных объявлений, выпустила Android-версию в виде APK на своей странице загрузки, пока сборка для iOS ещё была в пути. Запуститься там, где можно, и добавлять платформы позже часто оказывается самым быстрым путём к реальным пользователям.

Первые недели идут быстрее, если к старту готовы несколько вещей. Ни одна из них не требует технической подготовки:

• Короткий список ключевых сценариев. Одна-три задачи, которые пользователи должны уметь выполнить при запуске, простыми словами.
• Один человек, принимающий решения. Тот, кто может утверждать макеты и отвечать на вопросы в течение дня.
• Доступы к существующим аккаунтам. Домен, хостинг, аналитика, платёжный провайдер и любые API, которыми вы уже пользуетесь.
• Реальные материалы или дата, когда они будут. Тексты, цены, юридические страницы и примеры данных, которые покажет продукт.
• Ваше ограничение по запуску. Событие, встреча с инвесторами или сезон, из-за которых дата важна.

С этим на руках оценка занимает дни, а не недели, и дизайн может начинаться с настоящих материалов, а не с заглушек.

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

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

Фиксированный объём с порядком изменений держит большую часть этого под контролем. Как именно, рассказываем в статье «Фиксированная цена или почасовая оплата».

Запуск запускает второй отсчёт, а не завершает первый. Первые недели после релиза обычно самые загруженные за весь проект.

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

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

Так мало, как только возможно, но чтобы он всё ещё проверял ваше главное предположение. Смысл MVP, по формулировке Lean Startup, в том, чтобы «начать учиться как можно быстрее».

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

Когда будете готовы спланировать свой, расскажите о продукте. Вы получите предложение с объёмом, сроком и фиксированной ценой, а каждую неделю будете видеть, как продукт собирается.