Skip to main content
Improvado
Международный агрегатор рекламных кампаний
60 млн $
капитализация
22 млн $
инвестиции в серии А
Создаем стартапы на блокчейне Cardano с использованием платформы Plutus, написанной на Haskell
Узнать больше

Кого нужно нанимать в команду для запуска MVP?

launching

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

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

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

Прототипирование идеи

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

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

UX\UI дизайнер


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

Разработчик


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

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

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

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

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

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

Разработка и запуск MVP

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

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


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

Менеджмент

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

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

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

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

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

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

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

Реальный опыт СЕО стартапа. Источник: Quora

Тестирование MVP и сбор обратной связи

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

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

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

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

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

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

Интересный случай

У одного моего знакомого предпринимателя случилась неприятная ситуация. 

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

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

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

Роман Штых
CEO MetaLamp

Масштабирование MVP

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

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

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

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


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

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

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

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

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

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

Как искать всех этих специалистов и как понять точно ли они нужны на этом этапе?

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

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

Больше интересных статей

выбор редакции
myths

Статьи

web3
dApps
startup
Мифы о разработке блокчейн продуктов

Николай Бордуненко

Project manager at MetaLamp

twa
горячее
Тренды блокчейна и криптоиндустрии 2024: Telegram Web Apps

Елизавета Черная

Редактор Бренд-медиа

Статьи

web3
buildings
новое
anonymus
новое
Zero-knowledge proof: один из трендов 2024 в блокчейне

Евгений Биктимиров

Венчурный аналитик

Статьи

ethereum
web3
dApps
cpay
выбор редакции
AA zksync
zero knowledge proofs
выбор редакции
stock market chart
выбор редакции
planets
fundraising
выбор редакции
cto
wallet
tokens
выбор редакции
rocket computer
выбор редакции
Как создать дизайн для MVP стартапа за 7 дней

Юлия Черепанова

Head of Design Office

Статьи

startup
MVP
design
nft
AI
crypto wallets
выбор редакции
Account Abstraction: что это такое и зачем нужно криптомиру

Павел Найданов

Solidity разработчик

Статьи

ethereum
web3
business
red space
выбор редакции
speed up development
myths
выбор редакции
Мифы о разработке блокчейн продуктов

Николай Бордуненко

Project manager at MetaLamp

Статьи

web3
dApps
startup
launching
выбор редакции
Кого нужно нанимать в команду для запуска MVP?

Алексей Сухарев

Head of Sales Department

Статьи

business
startup
MVP
galaxy
magazine
spaceman
выбор редакции
coffee
investors
nft
Первый NFT marketplace на Cardano

Станислав Жданович

Haskell разработчик

Статьи

cardano
web3
nft
stair
выбор редакции
bridge
rocket
abstraction
Как мы нанимаем Plutus инженеров через собственную программу обучения

Светлана Дульцева

Супервизор программы обучения

Статьи

education
cardano
web3
mountains
blockchain
salary
salary increase
app
developer with books
keyboard
abstract