Многоликий MVP: мифы и реальность о разработке технологических продуктов

Юрий Чумин — о том, как венчур билдеру Digital Horizon удается строить MVP, которые становятся успешными технологическими продуктами, а не слитыми бюджетами.

Реализация любой инновации начинается с разработки MVP (Minimal Viable Product — минимально жизнеспособный продукт). Для многих проектов этот этап станет первым и последним по самым разным причинам: от невостребованности идеи рынком до нехватки денег у фаундеров. Но тем ценнее понять, чем отличаются MVP, которым удалось «преодолеть долину смерти» и выстрелить.

В интервью CTO венчур билдера Digital Horizon Юрий Чумин рассказал:

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

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

Спрошу, на какой стадии проработки находится бизнес-модель. Разработка любого нормального продукта никогда не стартует с идеи. Даже если делаешь сайт для магазина, ты сначала должен проанализировать рынок, целевое размещение продукта, конкурентов, понять, как выходить на этот рынок. Продукты для b2b, b2c или более сложного варианта b2b2c будут создаваться и запускаться по-разному.

Бизнес-модель существенно влияет на IT-архитектуру — как в плюс, так и в минус. Например, на уровне идеи кажется, что продукт очень простой, а при проработке бизнес-модели оказывается, что нужна достаточно сложная распределенная архитектура. Или, наоборот, в ходе анализа бизнес-модели выясняется, что все можно сделать чуть ли не по существующим шаблонам.

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

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

И хорошо, если не нужно полностью менять архитектуру.

Это то, как организована система, как она взаимодействует с внешней средой, как определены внутренние компоненты и их взаимодействие друг с другом.

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

От особенностей продукта и конкретного MVP.

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

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

Да, но нет. Выбор архитектуры для MVP неоднозначный.

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

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

Неправильно определяют, какой MVP нужно строить.

Конечно. MVP как продукт может иметь несколько конфигураций. Мы для себя выделяем три.

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

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

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

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

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

Да, самый сложный. Это полноценный продукт, но с жестко урезанной функциональностью на первых этапах.

Условно, это версия 1.0, после которой последуют 2.0, 3.0 и т. д. Процесс расширения функциональности идет прозрачно: пользователи знают, что в следующем обновлении возможности продукта расширятся.

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

Время.

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

MVP должен измеряться месяцами. В идеале — полгода, если начинать от идеи с бизнес-требованиями.

Не совсем. Это зависит опять же от конфигурации. Вариант без разработки можно сделать за 1 млн рублей, функциональное демо — около 10 млн рублей. Но мы внутри венчур билдера Digital Horizon в основном строим полнофункциональные MVP, стоимость которых начинается от 20 млн рублей и включает косты на эксплуатацию системы в будущем.

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

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

Это риски. Они минимизируются при правильном выстраивании первоначального MVP.

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

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

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

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

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

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

У разработки и бизнеса одна цель — выпустить продукт на рынок. Но требования разные.

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

В венчур билдере ты становишься причастным сразу к нескольким крутым проектам. У нас каждый продукт — это стартап в полном смысле этого слова.

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

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

У нас есть разработчики, девопсы для поддержки инфраструктуры, тестировщики. Бизнес-аналитики и UX/UI дизайнеры в нашу структуру не входят, но мы тесно общаемся.

Для своей команды я стараюсь не выискивать фулстэк-разработчиков. Когда продукты нужно строить быстро, выгоднее всегда разбивать работу по направлениям, чтобы бэкэнд и фронтэнд работали параллельно. Безусловно, опыт фулстэка — это хорошо. Но в нашем случае мы, скорее, ищем T-shaped специалистов.

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

Для компании такой вариант — это страховка по ресурсам, для разработчиков — возможность прокачать дополнительную экспертизу на практике, а не просто изучать новый стек вхолостую, сидеть дома и писать “Hello, world!”

Безусловно. Разработка продукта — это не просто написание кода. Разработчик привносит собственные идеи, апробирует их, реализует и отвечает за свое творение.

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

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

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

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

В противном случае придется объяснять «соседнему» разработчику, как и что у тебя работает, а это потеря времени, динамики, денег.

Инженеры, разработчики, тестировщики, которые хотят быть вовлечены в создание продукта. Готовые не только решать поставленные задачи, но и брать ответственность за свои решения. Те, кто хочет развиваться.

У нас порядка 15 вакансий. В основном для «джавистов», но есть и для других специализаций, например, Python, Golang. Это связано с тем, что мы расширили сферу интересов, двинулись в маркетинг, энтертейнмент, работу с контентом.

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

Впрочем, хорошая зарплата, ДМС, офис напротив парка «Зарядье», гибридный график работы — все это у нас тоже есть. Так что присылайте резюме на hr@digitalhorizon.ru, рассмотрим.

Да. В личку на Facebook и LinkedIn постоянно кто-то стучится, но я игнорирую. Мне интересны проекты Digital Horizon и опыт, который я тут получаю. Например, сейчас начинаем строить платформу и приложение для обработки видеобэка. Это прямо хардкорный стартап, когда у тебя есть жесткие сроки и нужно достичь результата практически любыми способами. Тоже классный опыт.

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

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

Технологии совершенствуются все быстрее, поэтому нужно быть в стриме. И мне это нравится.

Я технооптимист.