Долгий запуск — опасность для любого проекта. Особенно в IT: eсли мы долгое время не получаем обратной связи от рынка и конечных пользователей — высокий риск сделать никому не нужный продукт.

Такая история произошла с моим знакомым, который имел вполне успешный бизнес в офлайне. Наблюдая за успехами таких сервисов, как avito и carprice, он решил запустить аналогичный онлайн-сервис по продаже недвижимости, в которой у него был 10-летний опыт.

Идея монетизации — оплата за размещенное объявление об объекте и помесячная подписка на расширенные инструменты для продажи недвижимости.

Для этого заказал разработку функционального онлайн-сервиса с внутренней CRM-системой, мессенджерами и сложной системой аналитики за 1.5 млн. рублей и 5 месяцев работы, снял офис, нанял менеджеров и запустил рекламу.

Примерно за полгода затраты превысили 2,5 млн. рублей и, судя по динамике, это было только начало.

Как вы думаете, сколько он заработал на проекте за это время?

Порядка 90 тысяч рублей. Идея оказалась провальной в моменте монетизации. Люди просто отказывались платить за размещение. Экономика проекта не сходилась. Я еще не упоминаю о том, что цена на размещение за все время снижалась 4 раза. Так как ее тоже никто не тестировал.

В итоге, после года такого “бизнеса по-русски”, мой знакомый закрыл проект с колоссальными убытками и еще долгое время долги тянули основной бизнес.

А какое могло быть решение?

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

В этом и есть идея MVP.

MVP(minimum viable product) — это продукт в своей минимальной разработке, который позволяет протестировать спрос, понять что нужно покупателям и не создавать то, что им неинтересно и за что они не готовы платить.

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

Хак номер 1: Недели, а не месяцы

Фундамент быстрой разработки — строгое ограничение проекта во времени.

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

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

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

Масштаб проекта

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

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

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

Наглядная иллюстрация.

Слева — подход, по которому продукт полностью создается в том виде, в котором был запланирован. Реализация сразу в масштабном, или идеальном, виде.

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

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

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

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

Упрощение продукта

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

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

Сложнее продукт → Дольше разработка → Больше времени занимают итерации тестирования и багфиксинга → Запуск отдаляется

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

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

Бизнес-задачи и разработка

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

Сквозь кровь, слезы и пот мы в EZTec сформировали подход, который позволяет получить 90% информации, необходимой для решения любой it-задачи.

Компоненты подхода:

  • User story — показывает, чего вы ожидаете от команды разработки

  • Use cases — показывают сценарии использования фичи

  • Wireframes — средство визуализации своей идеи

Рассмотрим User story и Use cases.

User story

Текст самой US должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которые пользователь получит после того как история случится.

Пример

Как, <роль>, я <что-то хочу получить>, <с такой-то целью>.

Важно:

  • Есть одна Роль

  • Есть одно действие

  • Есть одна ценность/влияние

Пример:

Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.

Use cases

Какой сценарий необходимо пройти, чтобы достичь цель?

Что UC включают в себя:

  • Кто пользуется системой

  • Что пользователь хочет сделать

  • Какая у пользователя цель

  • Шаги к достижению цели

  • Как система реагирует на действия пользователя

Например, загрузка изображений:

Маркетолог заходит в свой личный кабинет → Открывает раздел «Галерея» → загружает изображения с помощью клика по кнопке «Выбрать файлы» → Изображения загружаются → Пользователь видит уведомление об успешной загрузке изображений

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

Хак номер 2: Убрать перфекционизм

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

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

Резюмируя

MVP — только начало, начало длинного пути развития продукта.

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

Упрощайте, начинайте с первой версии и улучшайте ее постепенно, шаг за шагом.

Помните: чем быстрее вы запустите MVP - тем больше времени/ресурсов вы сэкономите и тем раньше начнете строить действительно успешный продукт.

Если вам нравится читать, обсуждать тему бизнеса и IT-продуктов, добавляйтесь ко мне в фейсбуке. С удовольствием пообщаюсь на интересные темы!