MVP. Типичные ошибки и как их избежать
В предыдущей статье наши специалисты рассказали про MVP и этапы его создания. Теперь мы хотим раскрыть основные проблемы, с которыми сталкиваются компании при внедрении минимально жизнеспособного продукта, и порекомендовать решения для подобных кейсов. 
Советы по внедрению MVP
Представьте: вы принимаете решение о создании нового продукта и начинаете разработку MVP. Но уже на первых этапах понимаете, что разработчики не осознают основных бизнес-задач, выбранная архитектура не позволяет масштабировать проект в будущем, а сам процесс разработки не систематизирован. Это приводит к дополнительным финансовым затратам и постоянным задержкам в реализации проекта.
Мы советуем придерживаться следующих шагов при создании MVP:
- убедиться, что у продукта есть идеолог;
- выбрать подходящий стек технологий;
- собрать опытную команду;
- подобрать архитектуру под требования проекта;
- организовать процесс разработки;
- осуществить процессы развертывания и обновления продукта.
Убедиться, что у продукта есть идеолог
Проблема. Вы начинаете создавать MVP без идеолога, связывающего бизнес-задачи и разработку. В процессе принятия ключевых решений участвуют слишком много людей, которые не объединены единой стратегией. Руководители отделов постоянно предлагают решения, противоречащие друг другу. Разработчики не понимают приоритетность задач и часто переделывают свою работу. В результате выпуск продукта затягивается, сроки срываются, бюджет растет, а команда теряет мотивацию.
Мы несколько раз сталкивались с проектами, где руководители разных отделов напрямую участвовали в создании продукта и предлагали противоречащие решения. Это приводило к хаосу и затягивало разработку. Без общей стратегии любое решение по функционалу каждого экрана и дизайну любой маленькой иконки приходилось согласовывать по два-три раза, а потом переделывать под новые требования. В итоге продукт так и не выпустили.
Как действовать. Наймите продакт-менеджера, который будет связывать бизнес и разработку. Такой специалист работает на стыке бизнеса, маркетинга, дизайна и программирования. Он полностью отвечает за создание и реализацию продукта — от первоначальной идеи до выхода на рынок. Продакт-менеджер определяет ключевые преимущества продукта, стратегию его продвижения и способы монетизации. В идеале он должен иметь профессиональный опыт и разбираться в сфере, в которой создается продукт. Подобные специалисты редко бывают свободными на рынке, поэтому их необходимо привлекать интересными условиями и перспективами. Кто такой продакт можно понять на примере Илона Маска или Стива Джобса, людей, которые стали идейными вдохновителями своих продуктов.
Выбрать подходящий стек технологий
Проблема. Компания выбирает стек технологий только
Стек технологий — это набор языков программирования, фреймворков и систем управления базами данных, которые используются для реализации проекта. Выбор стека технологий влияет на масштабируемость и надежность продукта.
Мы разрабатывали интеграционный продукт для страховых компаний. Заказчик имел экспертизу на 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 вы столкнулись с проблемами и не знаете, что делать — свяжитесь с нами и мы проконсультируем вас по всем аспектам запуска минимально жизнеспособного продукта.
