Кого нанимать для успешного запуска MVP

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

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

UX\UI дизайнер

В широком смысле UX\UI дизайнер проработает путь клиента от момента знакомства с вашим приложением до момента удовлетворения от оказанной услуги. В более узком смысле - он создаст интерфейс вашего продукта и определит то, как пользователи будут с ним взаимодействовать. Результатом его работы могут быть: CJM (Customer Journey Map), Дизайн-макеты вашего приложения.   

Разработчик

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

ВАЖНО! Дизайнеру и разработчику должны передаваться уже сформированный портрет целевой аудитории и описанная бизнес потребность, которую вы хотите реализовать посредством своего MVP. Если таких данных у вас еще нет, стоит обратится к этапу с продуктовым/маркетинговым исследованием.

Часто, функцию UX\UI дизайнера на первых этапах может взять на себя кто-то из основателей, потому что первая версия может быть очень простой. Иногда MVP может быть ограничен двумя-тремя экранам с минимальным количеством отображаемых данных. 

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

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

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

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

Разработка продукта

Этот процесс может вовлекать как одного специалиста, у которого набор компетенций достаточен для разработки MVP, так и целую команду с разными ролями и задачами. Классический состав команды для создание MVP - frontend и backend разработчики. Иногда эти две компетенции могут совмещать в себе один человек - fullstack разработчик. Сколько и каких специалистов вам необходимо - вопрос индивидуальный. В нём стоит полагаться либо на партнеров с технической экспертизой, либо обращаться к студиям разработки. Но обычно, первые версии собираются небольшим составом (1-4 специалиста). Хотя в случаях где набор задач широкий и сроки поджимают могут собираться и довольно крупные команды (10-15 человек).

Менеджмент

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

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

Кроме того, на этапе разработки острым становится вопрос о необходимости технического директора (СТО). Данная роль отвечает за всю техническую составляющую вашего продукта. СТО -  единое окно для всей команды по вопросам разработки, скорости релизов, качества релизов.

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

Эту роль на ранних этапах на себе могут взять:

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

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

Произошел релиз вашего MVP. Что делать дальше и какие специалисты могут понадобиться на этом этапе? Ответ зависит от того, какую цель вы ставите перед MVP - первые продажи и/или обратную связь от первых пользователей.

Обратная связь от пользователей

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

В крупных стартапах эту роль на себя берут продакт-менеджеры и UX\UI дизайнеры (потому что им важно понимать как люди взаимодействуют с их интерфейсами). Однако в крупных стартапах определение приоритетов и сбор обратной связи от пользователей - процесс очень сложный и многосторонний. На ранних стадиях, когда работа идет над MVP, эту функцию выполняет основатель проекта. Но здесь снова становится актуальным вопрос микроменеджмента и приоритетов. Если у вас основной фокус - фандрайзинг, возможно стоит делегировать общение с пользователями коллегам.

Первые продажи

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

Термин “Масштабирование MVP” разными предпринимателя определяется по разному. Кто-то считает, что это следующий большой этап разработки после релиза первой версии, кто-то определяет это как дальнейшее развитие продукта после возникновения первой стабильной месячной выручки. 

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

Когда вы заходите в долгую и сложную разработку помимо уже существующих возникают новые процессы:

Тестирование

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

Управление приоритетом задач

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

Поддержка технической инфраструктуры

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

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

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

Ранее мы выпускали статью на тему “Кого привлекать для разработки MVP стартапа: фрилансера, студию или наемных сотрудников?”. В ней мы рассказали о том, какие риски и какие преимущества есть в работе с каждым из этих вариантов исполнителей. Статья не утратила своей актуальности и возможно она поможет вам в выборе идеального варианта для запуска своего MVP.