14 июня – ИА SM.News. Разобраться в ней нам поможет Ринат Юнусов. Ринат является разработчиком полного цикла с более чем 10-летним опытом. Он основал веб-студию, которая успешно занимается разработкой интернет-магазинов, бизнес-сайтов и целевых страниц.
Ринат участвовал в реализации значительного количества крупных проектов, в настоящее время возглавляет запуск международных проектов в крупнейшем российском поисковом гиганте Яндекс.
Ринат, добрый день. Хотелось бы начать наш разговор с вводных вопросов. Что такое MVP и какова основная цель его разработки?
Если мы рассмотрим само определение MVP, оно нам многое покажет. MVP (MinimumViableProduct) — это минимально жизнеспособный продукт, представляющий собой версию приложения с достаточным количеством функций для привлечения первых пользователей и сбора обратной связи с минимальными затратами времени и ресурсов. Соответственно основная цель разработки заключается в проверке доходности того или иного решения бизнеса. Это позволяет компании быстро выйти на рынок, протестировать основные концепции и получить обратную связь от реальных пользователей, что обеспечивает основу для дальнейшего развития и улучшений.
Каким образом используя построение MVP можно выполнить бизнес-цель за короткие сроки?
Здесь я могу отметить 5 основных пунктов:
Приоритизацияфункциональностей:определите какие функции важны, какие менее важные и какие повлияют на первое впечатление пользователей. Фокусируйтесь на них и избегайте лишних «фишек». Важно не сделать продукт, который будет отталкивать пользователей. Привлечь пользователей попробовать ваш продукт еще раз, будет сложно. Важно обозначить, что продукт не финальный, многие пользователи могут смириться с багами, главное, чтобы была нужная функциональность!
Аджайл-методологии: используйте гибкие подходы к разработке, такие как Scrum или Kanban, для повышения гибкости и быстроты реакции на изменения.
Скромность целей: определите реалистичные и ограниченные бизнес-цели для первоначального запуска, чтобы сосредоточить усилия команды.
Автоматизация процессов: автоматизируйте тестирование, CI/CD процессы и развертывание, чтобы ускорить разработку и выпуск.
Открытые коммуникации: обеспечьте прозрачность коммуникаций между бизнесом и разработчиками, чтобы исключить ложные ожидания и своевременно решать возникающие проблемы. Представьте, что вы стартап с небольшой командой, коммуницируйте как можно чаще, но учитывайте, чтобы излишние встречи не мешали разработке.
Как определить уровень сложности проекта на ранних этапах? И какие приложения считаются сложными?
В первую очередь важно сначала понять, что такое сложный проект, если соответствуете хотя бы паре пунктов, ваш проект можно считать сложным.
Высокая нагрузка: приложение, требует поддержки большого количества пользователей или высокой частоты операций.
Сложные интеграции: приложение, требует взаимодействия с множеством внешних систем и API.
Обработка данных: приложение, работает с большим объемом данных и сложными алгоритмами обработки.
Высокие требования к безопасности: приложение в финансовом секторе, медицине и других чувствительных областях.
Чтобы определить уровень сложности проекта важно.
Проанализировать требования: проведите тщательный анализ требований, включая функциональные и нефункциональные аспекты.
Провести архитектурное ревью: определите архитектурные компоненты и идентифицируйте потенциальные узкие места или сложные интеграции.
Оценить риски: проведите оценку рисков, связанных с новыми технологиями, зависимостями, и навыками команды.
Учесть ресурсный анализ: оцените доступные ресурсы, включая время, бюджет и размер команды.
Каким образом создание MVP помогает избежать накопления техдолга при разработке сложных приложений?
На раннем этапе получение обратной связи от реальных пользователей помогает корректировать продукт и архитектуру до того, как техдолг станет проблемой. Составление MVP позволяет сосредоточиться на ключевых функциях, избегая избыточных возможностей, которые увеличивают техдолг. Меньшие, более частые релизы позволяют исправлять архитектурные и кодовые проблемы быстрее и дешевле, чем исправление накопившихся проблем позже. Поймите, нужно ли оно пользователю, избегайте такой формулировки, проведите опрос, если «Да», то делайте сейчас, если нет, то нет смысла заводить задачу в техдолг, не сделаете, а подумаете потом. Включение процесса автоматического тестирования и CI/CD на этапе MVP помогает уменьшить техдолг путем раннего обнаружения и исправления ошибок.
Ранее вы упоминали об обратной связи от пользователей. Какая роль у неё при разработке MVP?
Оперативная обратная связь является ключом к коррекции курса, позволяя быстро вносить изменения и улучшения на основе реальных данных, а не предположений. Обратная связь помогает приоритизировать функции, лучше понимая, какие из них действительно важны для пользователей и сфокусироваться на них. Таким образом, снижается риск создания ненужных или неэффективных функций, которые могут добавить техдолг и не принести пользы бизнесу. Кроме того, обратная связь помогает подтвердить или опровергнуть бизнес-гипотезы, лежащие в основе продукта, с минимальными затратами на первоначальную разработку.
И подводя итог нашего разговора, какой подход к управлению проектами поможет избежать перегруженности бэклога?
Для успешного выполнения проекта важно проводить качественное планирование и регулярные груминги всей командой, ответственной за функциональность. Обеспечьте прозрачность задач всем участникам проекта с помощью инструментов управления, таких как Jira или Trello. Периодические ретроспективы помогут скорректировать процесс управления задачами и сосредоточиться на приоритетных задачах. Ну и важно, помните, что вы делаете MVP, не нужно пытаться учесть все варианты работы функционала и предугадывать что хочет пользователь за него.
