Назад

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

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

Время чтения: 7 минут

Содержание

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

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

Если нет времени на сбор команды

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

По данным исследования HeadHunter и компании «Яков и Партнеры», наем сотрудников занимает 2–3 месяца, а специалистов уровня миддл+ хантить еще дольше — поиск может растянуться и на полгода. При этом, по оценкам кадрового агентства «ХЭД», на подбор одного разработчика придется потратить 14–16% от его годового оклада. Это около 250 000–400 000 ₽.

Если отдать разработку MVP на аутсорс, вы сэкономите время на наем. У подрядчика уже есть команда, которую он быстро подключит к вашему проекту. Вы сможете запустить работу над проектом «вот прям щас», а не через 3–6 месяцев. А еще не придется думать, чем занять новых сотрудников после релиза, если продукт не выстрелит и вы не будете его развивать. 

У нас в Purrweb над MVP обычно работает команда из 5–7 человек: аналитик, разработчики, UI/UX-дизайнер, тестировщик и проджект-менеджер. Если мы сотрудничаем с техническим директором стартапа (CTO), то на этапе знакомства предлагаем ему пообщаться с нашим техдиром. Это нужно, чтобы обсудить бизнес-цели проекта и подобрать команду с максимально подходящими техническими скилами. 

Кейс из практики Purrweb

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

В результате мы:

    • за неделю сделали прототипы профиля клиента и повара, чтобы проверить гипотезу;
    • за пару недель составили дорожную карту проекта с этапами дизайна и разработки;
    • расставили все этапы работы по приоритетам, чтобы уложиться в бюджет клиента — 2 млн ₽;
    • зарелизили MVP за 5 месяцев.
Кейс Talentum

Клиент попросил нас сделать акцент на реальных людях, а не на еде. Для этого мы добавили чат-бота, который определяет вкусовые предпочтения клиента, и сделали UI с фокусом на личность повара

Если хочется свести к минимуму неприятные сюрпризы 

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

Мем

Мем, может, и смешной, а вот ситуация страшная…

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

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

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

Если тошнит от созвонов и необходимости всё контролировать

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

Мем про CTO

Так может ощущать себя СТО, когда по уши погрузился в операционку MVP

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

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

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

Подробнее о менеджменте в нашей студии рассказывали здесь

Если понимаете, что для проекта не хватает экспертизы 

Создавать нишевые MVP сложно, даже если вы разрабатывали IT-продукты много лет. Например, не получится с нуля сделать приложение для буддистов, если никогда не касались этой ЦА. Команда на аутсорсе может привнести в проект полезную экспертизу, ведь у крупного подрядчика, как правило, в портфеле не одна сотня проектов для разных ниш и стран.

Вот две ключевые ситуации, когда пригодится экспертиза аутсорс-команды 👇🏻

✔️ Подготовка к проекту. Опытная команда на аутсорсе подскажет, с какой стороны зайти в сложный продукт. Например, если надо сделать «тиндер» для арабского рынка, аналитик проведет исследование ЦА из стран Ближнего Востока и проверит, есть ли спрос. Если его не окажется, предложит, в какую сторону повернуть проект.

Еще подрядчик поможет подготовиться к проекту, если времени очень мало. MVP не зря сравнивают с велосипедом — главное, чтобы были руль, колеса и педали, а остальное можно добавить позже. Аутсорс-команда опытным взглядом очертит объем работ, без которого приложение «не поедет», и отсечет менее важное.

Кейс из практики Purrweb

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

На этапе разработки нас ждал сложный процесс: предстояло поработать с чужим бэкендом, сделать знакомый менеджерам UX и синхронизировать десктоп с мобильной версией. Наш системный аналитик пообщался с клиентом и выявил главные разделы, нужные в ежедневных задачах менеджеров: «Календарь», «Интересы» и «Партнеры». Эти три кита стали основой продукта.

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

В галерее ниже показываем, как нам удалось адаптировать CRM клиента для мобильной версии 👇🏻

Кейс Koblik Group

Так выглядел раздел «Интересы» в десктопной версии CRM клиента

Кейс Koblik Group

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

Кейс Koblik Group

Процесс продажи разделили на цветовые блоки, чтобы было удобнее ориентироваться

Кейс Koblik Group

Добавили календарь с событиями на день, неделю и месяц

Кейс Koblik Group

И продумали офлайн-режим

✔️ Дизайн. В сложном продукте у аудитории могут быть специфические требования к UX и UI. Например, в приложении для слабовидящих пользователям будет сложно нажимать много кнопок или оценивать фотографии — это надо учитывать. Команда на аутсорсе сможет поднять базу со схожей ЦА, чтобы точнее определить ее потребности. Или подключит аналитика, который умеет проводить исследования для нестандартных проектов.

Кейс из практики Purrweb

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

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

В этом проекте всё сложилось, потому что у нас в портфолио уже было больше 300 MVP со схожими бизнес-целями. Поэтому разработка Dosis шла по проверенному плану.

Листайте галерею, чтобы посмотреть пользовательский дизайн и интерфейс для системы донатов в Dosis 👇🏻

Кейс Dosis

Цветовая гамма приложения: градиент коричневого и оранжевые детали

Кейс Dosis

Пользовательский дизайн: рекомендации на стартовой странице и каталог с поиском контента

Кейс Dosis

Страница автора контента с яркой кнопкой для донатов

Кейс Dosis

А также криптокошелек — знакомый UX в формате банковского приложения

Выводы

Еще раз коротко объясню, когда стоит нанимать подрядчика для разработки MVP 👇🏻

  1. Если не хватает времени на сбор команды инхаус.
  2. Если нет сил решать внезапные проблемы: увольнение сотрудника или сложности с запуском.
  3. Если не хочется ходить на созвоны каждое утро и постоянно контролировать работу команды.
  4. Если берете в работу специфичный продукт, но чувствуете, что не хватает экспертизы.

Я желаю каждому CTO однажды примерить на себя роль Майкла Скотта и хотя бы пару недель провести в счастливом неведении. Больше кейсов об аутсорс-разработке и дизайне приложений читайте на нашем сайте.

Насколько публикация полезна?

Оцени эту статью!

7 оценок, среднее 4.6 из 5.

Оценок пока нет. Поставьте оценку первым.

Так как вы нашли эту публикацию полезной...

Подписывайтесь на нас в соцсетях!

Share