В предыдущей статье наши специалисты рассказали про MVP и этапы его создания. Теперь мы хотим раскрыть основные проблемы, с которыми сталкиваются компании при внедрении минимально жизнеспособного продукта, и порекомендовать решения для подобных кейсов. 
Представьте: вы принимаете решение о создании нового продукта и начинаете разработку MVP. Но уже на первых этапах понимаете, что разработчики не осознают основных бизнес-задач, выбранная архитектура не позволяет масштабировать проект в будущем, а сам процесс разработки не систематизирован. Это приводит к дополнительным финансовым затратам и постоянным задержкам в реализации проекта.
Мы советуем придерживаться следующих шагов при создании MVP:
Проблема. Вы начинаете создавать MVP без идеолога, связывающего бизнес-задачи и разработку. В процессе принятия ключевых решений участвуют слишком много людей, которые не объединены единой стратегией. Руководители отделов постоянно предлагают решения, противоречащие друг другу. Разработчики не понимают приоритетность задач и часто переделывают свою работу. В результате выпуск продукта затягивается, сроки срываются, бюджет растет, а команда теряет мотивацию.
Мы несколько раз сталкивались с проектами, где руководители разных отделов напрямую участвовали в создании продукта и предлагали противоречащие решения. Это приводило к хаосу и затягивало разработку. Без общей стратегии любое решение по функционалу каждого экрана и дизайну любой маленькой иконки приходилось согласовывать по два-три раза, а потом переделывать под новые требования. В итоге продукт так и не выпустили.
Как действовать. Наймите продакт-менеджера, который будет связывать бизнес и разработку. Такой специалист работает на стыке бизнеса, маркетинга, дизайна и программирования. Он полностью отвечает за создание и реализацию продукта — от первоначальной идеи до выхода на рынок. Продакт-менеджер определяет ключевые преимущества продукта, стратегию его продвижения и способы монетизации. В идеале он должен иметь профессиональный опыт и разбираться в сфере, в которой создается продукт. Подобные специалисты редко бывают свободными на рынке, поэтому их необходимо привлекать интересными условиями и перспективами. Кто такой продакт можно понять на примере Илона Маска или Стива Джобса, людей, которые стали идейными вдохновителями своих продуктов.
Проблема. Компания выбирает стек технологий только
Стек технологий — это набор языков программирования, фреймворков и систем управления базами данных, которые используются для реализации проекта. Выбор стека технологий влияет на масштабируемость и надежность продукта.
Мы разрабатывали интеграционный продукт для страховых компаний. Заказчик имел экспертизу на Python и хотел вести разработку только с помощью этого языка программирования. Но такой стек не соответствовал задачам проекта и значительно увеличивал общую стоимость. Поэтому мы порекомендовали провести разработку на .Net Core, что снизило бы издержки и сохранило качество продукта. Заказчик выбрал Python и столкнулся с прогнозируемыми трудностями при реализации проекта.
Как действовать.
Проблема. Вы хотите сэкономить и набираете разработчиков-фрилансеров без необходимого опыта, не уделяя должного внимания этапам отбора и собеседований. Отсутствует грамотный технический руководитель IT-команды, который бы смог отследить процесс выполнения задач и организовать всю работу. Команда начинает реализовывать проект, но
В нашем случае заказчик разрабатывал продукт, связанный с хранением чувствительных пользовательских данных. Первоначальная команда оказалась неопытной и выбрала платформу с уязвимостями в безопасности. По ходу реализации проекта руководство несколько раз меняло исполнителей, что привело к затягиванию сроков. Когда пришло время масштабировать продукт уже нашими силами, пришлось переписывать прошлые «костыли» и закрывать уязвимые места.
Как действовать. Соберите команду с правильным распределением ролей или возьмите готовую с релевантным опытом. Проведите многоступенчатый отбор для новых специалистов, чтобы подтвердить их квалификацию.
Наши команды разрабатывают MVP для сложных длительных проектов, а также работают над кейсами, где результат нужно обеспечить в сжатые сроки. Мы имеем собственные наработки в виде библиотек готовых компонентов и базовых микросервисов, за счет которых сможем «влезть» в меньший бюджет и быстрее добежать до цели.
Проблема. Многие компании не понимают в каких случаях стоит использовать микросервисную архитектуру вместо монолитной. Часто происходит следующий сценарий: команда начинает разработку на микросервисах, хотя вместо этого достаточно было бы использовать монолит. В результате этого решения сроки разработки и бюджет проекта кратно возрастают.
В одном из наших проектов по разработке корпоративной системы закупок мы сначала создали работающую систему на монолите, запустили продукт, получили первые платежи и первую обратную связь от пользователей, а уже потом перешли на микросервисную архитектуру, когда появилась потребность в расширении функционала.
В другом проекте мы разработали и запустили цифровую обучающую платформу на монолите. И только когда этот продукт начал приносить деньги, мы «распилили» его на микросервисы. Заказчик, сэкономивший на этом бюджет, остался доволен.
Как действовать. В большинстве случаев мы рекомендуем создавать MVP на монолитной архитектуре. Применяйте микросервисную архитектуру, когда минимально жизнеспособный продукт сразу рассчитан на большую нагрузку или у вас есть команда с опытом и готовыми наработками в виде переиспользуемых микросервисов.
Проблема. Ваша команда начинает реализацию проекта без документа, в котором сформулированы шаги его развития. Разработчики теряют время на постоянные согласования о порядке и сроках запуска фич. Продуктолог неправильно оценивает бюджет проекта и его сложность. Разработка затягивается, финальный продукт не отвечает требованиям инвесторов.
Мы разрабатывали MVP для банка и столкнулись со следующей проблемой. Продуктолог со стороны заказчика не сформировал план итераций и выпуска фич. Эти работы не были оценены разработкой и согласованы с заказчиком. Как итог, требования формулировались на лету, команда работала с двукратными переработками. Нам пришлось перейти с методологии разработки Agile на Waterfall (подробнее о типах методологий разработки читайте в нашей статье) и компенсировать недостатки процесса планирования геройством разработчиков.
Как действовать. Разработайте и поддерживайте дорожную карту по выпуску фичей. Она состоит из стадий аналитики, разработки, тестирования и публикации на продуктовые сервера. Особенное внимание стоит уделить стадии аналитики, на которой формулируются функциональные требования. Такие требования объясняют, что должно быть сделано. Они включают в себя макеты, описание бизнес-процессов, модель данных, путь пользователя, этапы его взаимодействия с продуктом.
На наших проектах мы выстраиваем процесс разработки следующим образом:
Гантт по разработке.
Процесс разработки ПО.
Подробное выстраивание процесса разработки минимизирует риски и повышает управляемость процесса.
Проблема. Процесс разработки и доработки продукта всегда идет непрерывно. Каждая новая версия выходит с постоянной периодичностью. Вам будет сложно обеспечить этот процесс без профессионального DevOps-инженера, который может настроить CI/CD (непрерывную интеграцию и развертывание). Такой специалист следит за ветками кода и тестированием основных фич, отслеживает цепочки сбора всех модулей и содержит все стенды. Именно он отвечает за функциональное качество продукта и оркестрирует весь процесс разработки. Отказ от услуг DevOps-инженера затягивает реализацию проекта.
Мы разрабатывали проект для крупной строительной компании. Заказчик не хотел пользоваться услугами DevOps-инженера и требовал, чтобы все процессы были выполнены в срок без автоматизации. В результате разработка проекта затягивалась, потому что разработчикам приходилось вручную осуществлять развертывание. На переход к следующему этапу и обновление версии продукта требовалась одна неделя. После настройки процесса CI/CD это время сократилось до четырех часов.
Как действовать. Внедрите DevOps-инженера в команду по разработке продукта. Такой специалист наладит взаимодействие между командой разработки и командой эксплуатации и осуществит процесс развертывания и обновления продукта.
Для идеального запуска MVP вам нужны профессионалы, которые понимают все детали разработки продукта и имеют достаточный опыт в данной сфере.
Если на одном из этапов разработки MVP вы столкнулись с проблемами и не знаете, что делать — свяжитесь с нами и мы проконсультируем вас по всем аспектам запуска минимально жизнеспособного продукта.
