MVP. Типичные ошибки и как их избежать

MVP. Типичные ошибки и как их избежать

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

Советы по внедрению MVP

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

Мы советуем придерживаться следующих шагов при создании MVP: 

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

Убедиться, что у продукта есть идеолог 

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

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

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

Выбрать подходящий стек технологий

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

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

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

Как действовать. 

  • Проанализируйте потребности продукта и предусмотрите увеличение функционала в будущем. 
  • Проконсультируйтесь с авторитетным IT экспертом, который подскажет лучший набор технологий именно для вашего проекта.   
  • Не спешите выбирать «перегретые»‎ стеки. Найдите баланс между популярным стеком и потребностями вашего продукта. Используя менее дорогой и популярный язык программирования, вы сможете быстрее набрать команду и сократить лишние издержки. 
  • При разработке мобильных приложений для MVP используйте кроссплатформенный язык. Это сократит финансовые затраты, позволяя создавать сразу несколько платформ одновременно.   
  • Продукты с более простым функционалом можно создавать с помощью no-code и low-code платформ, которые экономят время на разработку и позволяют проверить гипотезы. 

Собрать опытную команду

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

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

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

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

Подобрать архитектуру под требования проекта 

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

 

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

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

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

Организовать процесс разработки

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

Мы разрабатывали MVP для банка и столкнулись со следующей проблемой. Продуктолог со стороны заказчика не сформировал план итераций и выпуска фич. Эти работы не были оценены разработкой и согласованы с заказчиком. Как итог, требования формулировались на лету, команда работала с двукратными переработками. Нам пришлось перейти с методологии разработки Agile на Waterfall (подробнее о типах методологий разработки читайте в нашей статье) и компенсировать недостатки процесса планирования геройством разработчиков.

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

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

 

Гантт по разработке. 

 

Процесс разработки ПО. 

Подробное выстраивание процесса разработки минимизирует риски и повышает управляемость процесса. 

Осуществить процессы развертывания и обновления продукта 

Проблема. Процесс разработки и доработки продукта всегда идет непрерывно. Каждая новая версия выходит с постоянной периодичностью. Вам будет сложно обеспечить этот процесс без профессионального DevOps-инженера, который может настроить CI/CD (непрерывную интеграцию и развертывание). Такой специалист следит за ветками кода и тестированием основных фич, отслеживает цепочки сбора всех модулей и содержит все стенды. Именно он отвечает за функциональное качество продукта и оркестрирует весь процесс разработки. Отказ от услуг DevOps-инженера затягивает реализацию проекта. 

Мы разрабатывали проект для крупной строительной компании. Заказчик не хотел пользоваться услугами DevOps-инженера и требовал, чтобы все процессы были выполнены в срок без автоматизации. В результате разработка проекта затягивалась, потому что разработчикам приходилось вручную осуществлять развертывание. На переход к следующему этапу и обновление версии продукта требовалась одна неделя. После настройки процесса CI/CD это время сократилось до четырех часов.    

Как действовать. Внедрите DevOps-инженера в команду по разработке продукта. Такой специалист наладит взаимодействие между командой разработки и командой эксплуатации и осуществит процесс развертывания и обновления продукта. 

Заключение

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

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

 

MVP. Типичные ошибки и как их избежать
Оцените полезность статьи
Спасибо за оценку!