Проектирование мобильного приложения
Проектирование нужно не каждому приложению. Простое приложение не требует проведения работ по проектированию. Проектирования требуют приложения с уникальным, заведомо новым функционалом, интегрирующие в себе множество функций и систем, предполагающие неоднозначность возможных решений. В отдельных, особо сложных случаях, услуга по проектированию выносится в отдельный договор.
Задача этапа — понять и зафиксировать:
1. Как будет происходить взаимодействие команд на проекте с той и с другой стороны
2. Какие ресурсы будут задействованы в разработке (в первую очередь — труд специалистов со стороны заказчика и разработчика)
3. В какие сроки реально запустить MVP, его функционал
4. Как будет развиваться проект после выпуска MVP (долгосрочный план развития проекта)
1 шаг: определите обязательные функции
Прежде чем разрабатывать приложение, убедитесь, что вы знаете, для чего оно предназначено. Нет ничего хуже, чем создать приложение, которое никто не использует, потому что оно не достигает цели, которую вы для него поставили. Прежде чем приступить к созданию прототипа приложения, убедитесь, что у вас есть четкое представление о том, что вы собираетесь делать. Тогда будьте готовы к серьезному делу.
Когда вы создаете прототип, важно определить, как ваше приложение будет работать, чтобы вы могли определить его основные функции. Например, если вы создаете приложение для покупок, функции будут включать добавление нового продукта и отображение его цены
В процессе разработки важно учитывать, будет ли приложение выполнять все основные функции конечного пользователя. К ним относятся основные служебные функции, такие как кнопки, текстовые поля и загрузчики изображений
Когда вы разрабатываете прототип, убедитесь, что вы учитываете, как пользователи будут с ним взаимодействовать, и знайте, что, протестировав его, вы сможете сразу обнаружить любые технические или дизайнерские проблемы.
При создании прототипа приложения вы хотите создать функциональный макет приложения, который можно использовать для получения количественных и качественных данных от реальных пользователей. Приложение должно быть простым в использовании и позволять пользователям делать то, что без него невозможно.
Затем вам нужно нарисовать набросок основного функционала и интерфейса приложения. Начните с мозгового штурма, опроса и изучения вашего целевого рынка с функциями, которые им были бы интересны.
После того, как вы провели мозговой штурм, опросили и исследовали свой целевой рынок с теми функциями, в которых они были бы заинтересованы, вам нужно наметить основные функции и интерфейс вашего приложения.
Не пытайтесь создать все функции сразу. Начните с малого и познакомьте потенциальных клиентов с основными преимуществами вашего приложения. Выясните, чего больше всего хотят люди, и обязательно включите эти основные функции в свою первую версию. Затем нанесите их на ментальную карту или электронную таблицу, чтобы их было легко использовать во время создания.
Ошибка № 1
Когда мы собираем Agile-команду, мы сокращаем время производства за счет того, что собираем все эти компетенции вместе и вводим в команду уникальную роль Владельца продукта.
Владелец продукта — человек от бизнеса. Но бизнес привык работать по-старому и говорит: «Я заказчик, и вы делаете то, что я сказал». Команда соглашается – это же заказчик так сказал. В данном случае это антипаттерн. Владелец продукта – это не заказчик, это представитель заказчика внутри Scrum команды.
И если вы видите, что заказчик, который стал владельцем продукта, отстранен от команды, что-то не работает. Мы специально берем владельца продукта от бизнеса для того, чтобы сократить коммуникацию между бизнесом и заказчиком.
На слайде показан пример структуры кроссфункциональной команды.
Кроссфункциональная команда – это не все компетенции, еще нужен бизнес заказчик внутри команды.
Как бывает в классическом варианте? Бизнес просит что-то сделать, но если вы не можете это сделать, он просит сделать хотя бы что-то другое. Когда ребята приносят готовый продукт или кусочек продукта, заказчик говорит, что хотел что-то другое. Команда переделывает, но заказчику снова не нравится. Такие циклы иногда повторяются очень часто.
Чтобы этого не было, мы помещаем внутрь команды представителя бизнеса.
Представьте: есть Product Owner, он посередине, но есть заинтересованные лица, есть пользователи и есть ваша кроссфункциональная команда.
Заинтересованные лица – это, вероятнее всего, заказчики извне, их может быть много.
Кроссфункциональная команда работает с приоритизированным списком задач, который называется бэклог.
А владелец продукта – это этот фильтр, который, получая информацию от заинтересованных лиц и от пользователей, принимает определенное решение и, самое важное, запускает продукт в производство.
Но самое интересное, что эта роль может в некоторых случаях при поступлении задачи от заказчика сказать «нет». Но это не просто «нет», это обоснованный отказ, основанный на цифрах и данных.
Product Owner является балансировщиком между задачами пользователей и заинтересованных лиц. Ведь пользователи и заинтересованные лица – это всегда два лагеря.
Простой пример из жизни Facebook:
- акционеры (заказчики) хотят, чтобы в соцсети было много рекламы;
- а пользователи говорят: «Если будет много рекламы, мы этим пользоваться не будем».
И здесь нужно соблюсти баланс: и заказчиков удовлетворить, и пользователей.
Другой пример – про гостиницы.
- Заказчики хотят много клиентов, много денег, поэтому строят большие гостиницы и делают большие комплексы, экономя на стенах и чем-то еще.
- А потребитель хочет, чтобы в комнате у него было тихо, чтобы соседи не кричали, чтобы во время завтрака не надо было стоять в больших очередях.
В случае 1С пример, наверное, будет таким:
- бизнес всегда хочет многим внешним заказчикам продать одно и то же и подороже;
- а внешние заказчики хотят бесплатно и побольше и под себя.
В продвинутых западных странах фокус владельца продукта последнее время смещается в сторону Customer Value (потребительская ценность): когда мы удовлетворяем больше ожиданий пользователей, пользователи довольны, они приносят больше денег. В российских реалиях, к сожалению, пока мы двигаемся в другую сторону: мы пытаемся сделать бизнесовые задачи, не задумываясь о пользователях. Но этот тренд, я думаю, со временем все-таки уйдет, а пока мы немножко отстаем.
А можно по-русски?
Вот несколько примеров перевода с айтишного на русский:
| Айтишный | Русский |
| Нашли опенсорсную либу, запилили прототип, окнули у стейкхолдеров и ушли в спринт на MVP. | Мы нашли библиотеку с открытым кодом, которая решала нашу задачу. Проверили её в действии на прототипе и убедились, что она работает. Далее мы согласовали с руководителями разработку минимального продукта, чтобы показать приложение пользователям. |
| Ментор сказал, что наш MVP больше похож на прототип, а прежде чем выйти на IPO, мы должны допилить кор-продукт, чтобы он стал ярдовой историей. | Наставник раскритиковал качество нашего приложения: по его мнению, в нём не хватает важных пользователю возможностей, без которых приложение не будет интересно. И прежде чем думать о выходе на биржу и продаже акций предприятия, сначала нужно создать такой продукт, который потенциально может привлечь более миллиарда долларов инвестиций. |
| Начинайте с недорогих MVP и следуйте принципу fail fast. | Выпускайте простые, но рабочие продукты. Если вы видите, что продукт не идёт и вы в чём-то ошиблись — не бойтесь это быстро признать и работать дальше. |
Smart Money словарь
Здесь предтавлены основные термины для использования Smart Money Concept.
Retail traders — розничные трейдеры, трейдеры технического анализа.MS (Market Structure) — маркет структура, структура рынка.СHoCH — слом структуры, смена тенденции цены.Bos — обновление максимумов (при восходящем тренде) и минимумов (при нисходящем), подтверждение структуры.IMB — имбаланс, пустые зоны, которые оставляет за собой цена после импульсного движения.OB — ордерблок.Breaker — прошитый резким движением (импульсом) цены ордерблок.FVG — разрыв справедливой стоимости.RR — соотношение риска и прибыли.POI — зона интереса.RTO — return to origin.FTA — первая проблемная зона.SFP — ложный пробой максимума или минимума предыдущего свинга.TF — таймфрейм.HTF — старший таймфрейм.LTF — младший таймфрейм.PDH — максимум предыдущего дня.PDL — минимум предыдущего дня.PWH — максимум предыдущей недели.PWL — минимум предыдущей недели.DO — открытие дня.WO — открытие недели.MO — открытие месяца.YO — открытие года.EQH — ровные вершины, за которыми ликвидность в виде стоп-приказов ретейл-трейдеров.EQL — ровные низы, за которыми ликвидность в виде стоп-приказов ретейл-трейдеров.SL — стоп лосс, остановка потери.FIb — фибоначи.WICK — свеча с длинной тенью, которая снимает ликвидность, стопы.Сквиз — быстрый рост или падение цены.Range — бокове движение цены в определенный период без обновления максимумов и минимумов.Deviation (девиация) — ложный выход, за границы ренджа.EQ (equlibrium) — середина ренджа.ТВХ— точка входа.Take Profit — забрать прибыль.FU — f*ck you move.STB — свип (манипуляция) ликвидности, продажа актива перед ростом.BTS — cвип (манипуляция) ликвидности, покупка актива перед падением.AMD (accumulation manipulation distribution) — накопление, манипуляция, распределение (distribution)
Принципы MVP
Жизнеспособность MVP определяется тем, продает он или нет. Речь не обязательно о деньгах. Рост пользовательской базы — тоже хороший показатель. Проще говоря, у MVP должно хватать ценности для первых пользователей.
Есть и другие принципы, которым должен соответствовать MVP:
- Видна перспектива на будущее. Первых клиентов — удержать, новых — привлечь.
- Обеспечена обратная связь, которая помогает понять перспективы продукта и при необходимости скорректировать курс его развития.
- Количество функций не имеет значения. Главное, чтобы MVP показывал ключевую идею продукта.
MVP — история больше про процесс, чем про результат. Обратная связь помогает найти ошибки и вовремя свернуть на другое направление или улучшить текущую идею. Основная задача — избежать создания бесполезных продуктов, применяя знания о потребностях пользователей, полученные из первых уст.
Распространенные ошибки при создании MVP:
- Слишком много функций.
- Продукт в минимальном виде не решает никаких проблем пользователей или решает незначительные проблемы.
- Неправильно определена целевая аудитория.
- Сделали продукт для себя.
- Не организована обратная связь или процесс ее обработки.
И, наверное, одна из самых распространенных ошибок — попытки довести до идеала вместо того, чтобы выпустить и проверить продукт. Зацикленность на мелких улучшениях убивает даже самые перспективные идеи. Эффективнее будет выпустить продукт, получить обратную связь от рынка и уже затем фокусироваться на улучшениях.
Что такое MVP
Сначала немного теории о MVP. Схематично это выглядит так:
MVP расшифровывается как Model-View-Presenter (модель-представление-презентер). Если рассматривать Activity, которое отображает какие-то данные с сервера, то View — это Activity, а Model — это ваши классы по работе с сервером. Напрямую View и Model не взаимодействуют. Для этого используется Presenter.
Если в Activity пользователь нажал кнопку Обновить, то Activity сообщает об этом презентеру. При этом Activity не просит презентер загрузить данные. Оно просто сообщает, что пользователь нажал кнопку Обновить. А презентер уже сам решает, что по нажатию этой кнопки надо делать. Он запрашивает данные у модели и передает их в Activity, чтобы отобразить на экране.
Если экран отображает данные из базы данных, то модель — это база данных. Презентер может подписаться на уведомления модели об обновлении. В случае, когда данные в БД изменятся, модель оповестит об этом презентер. Презентер получит эти изменения и передаст их в Activity.
Можно сказать, что презентер — это логика, вынесенная из Activity в отдельный класс. А Activity остается для отображения данных и взаимодействия с пользователем. Если вы решили сделать другое Activity для отображения данных, то вам уже не нужно будет переносить логику в новое Activity, можно будет использовать готовый Presenter. А если вы решили поменять логику, то вам не нужно будет лезть в Activity и там, среди кода, который отвечает за отображение данных и взаимодействие с пользователем, искать логику и менять ее. Вы меняете код в презентере.
Важное замечание! Пример реализации, который мы сейчас будем рассматривать, не является единственно правильным вариантом, выполненным по канонам MVP. В разных случаях могут быть шаги влево и вправо. Но общую концепцию этот пример отражает.
Как оно бывает: примеры
Самый простой пример: нам нужно понять будет ли наш сервис пользоваться популярностью. Мы создаем мобильное приложение для передержки собак. Вы уезжает в Бангкок, а пекинеса с собой взять не получается. Заходите в приложение GavSave и выбираете человека, которые за вознаграждение готов взять вашу зверушку на сохранение.
Нужно проверить эту идею, но как это сделать?
- Создаем 2-3 лендинга (одностраничный сайт) куда выносим свою идею сервиса.
- В центре ставим кнопку “заказать передержку” или “найти предержку”. Можно с разными цветами и сообщением оформить каждый из вариантов.
- Определяем тестовый бюджет на рекламную кампанию и время для замера результатов.
- Настраиваем рекламу (контекст, социальные сети или ещё что-то) под заранее выбранную целевую аудиторию.
- Запускаем поток на лендинги.
- Смотрим сколько человек нажимают на кнопку и делаем вывод.
Если результаты вас устроили, то берите в работу сервис и делайте хорошо, красиво, удобно. Если нет, то просто выбросите эту идею и переходите к следующей. Это лишь один из примеров MVP. Для проверки новой фишки на существующем продукте можно повесить просто баннер или горящую кнопку, замерить нажатия и прикинуть приблизительный интерес пользователей к новой идее.
На практике бывает и так, что занимаясь проверкой гипотез (в простонародье MVP), ты можешь вообще не делать прототип. Погуглил, посмотрел нет ли чего-то похожего в мире? А может уже исследования какие-то проводились на эту тему? Нужно просто покопать. Не исключено, что вы найдете ответ в уже существующих источниках информации.
MVP и MVaP — «отцы и дети» в бизнес-среде
Всё чаще и чаще на просторах Интернета, на отраслевых митапах и конференциях можно отметить фразу «Minimal Valuable Product» (MVaP) — минимально ценный продукт. Но что это? Новый метод разработки решений? Или оговорка экспертов и ошибка редакторов? — Давайте разбираться.
Самая распространённая причина неудач стартапов и новых продуктов — невостребованность на рынке. Около 34% стартапов «терпят крушение» из-за отсутствия ценности. Продуктовые команды или не могут донести её до потребителя, или изначально готовят бесполезный MVP из разряда «сделаем стартап и поднимем лёгких денег». Опытные product-команды ставят перед собой цель сделать ценный продукт. И чтобы постоянно напоминать себе об этом, используют аббревиатуру MVaP.
MVaP — это не выпуск «я сделаль»-продукта при минимальных затратах. Разработка ценного решения ставит в приоритет своих пользователей: учитываются их потребности и ожидания. Команда уделяет время исследованиям, анализу юзабилити, оценке демографии. Она ищет наилучшие способы удовлетворения запросов целевой аудитории.
Ещё одно преимущество, которое чаще применимо для крупных брендов — сохранение репутации. Ведь традиционно MVP делается неаккуратно, из-за чего соответствовать ожиданиям пользователей не всегда возможно. Именно из-за этого выбирают более надёжный путь — разработку дорогого, но ценного продукта, MVaP.
Владелец продукта (product owner) – это роль Scrum Framework
Начнем с роли владельца продукта. Это – роль, которая появилась во фреймворке Scrum. До этого были различные другие роли – продуктовик, продуктолог, продукт-менеджер. Но роль владельца продукта вошла в обиход, и сейчас от нее ждут очень разных вещей, иногда очень странных.
Об истоках появления этой роли я сейчас более детально расскажу и расскажу, какие ошибки допускает эта роль.
Я не буду рассказывать про отличия подходов Agile и Водопад, я только скажу, что мы теперь работаем не большими длительными циклами, а запускаем Agile для того, чтобы сократить Time-to-Market.
Основная цель этого – ускорить производство. Представьте, у вас есть производство. Это может быть ИТ-производство, может быть страховое производство, может быть строительное производство, и вы хотите быстрее делать продукт.
Чтобы делать продукт быстрее, мы все долгие этапы пытаемся сократить и в команду включаем все необходимые роли. Это получается дороже, но мы сокращаем время.
По результатам каждого отрезка времени, которые называются итерациями, мы делаем небольшое приращение продукта, которое называется инкремент.
И пользователь потихоньку из несчастного человека превращается в счастливого. А иногда он остается где-то посередине.
Дам краткую характеристику Agile-команды. Она должна быть небольшая, самостоятельная, иметь общую цель. Причем, эта цель должна быть бизнесовая.
Команда должна быть стабильной. Чтобы собрать команду, нужно время. В среднем становление команды занимает 3-6 месяцев. Поэтому если вы делаете короткие проекты, какие-то быстрые с уникальными наборами компетенций возможно формировать стабильную команду не рационально.
Пошаговое руководство создания MVP мобильного приложения
Шаг 1: Определение идеи и целей
Прежде чем приступить к созданию MVP (Minimum Viable Product), необходимо четко определить идею вашего мобильного приложения и установить конкретные цели, которых вы хотите достичь
Важно понять, что конечный продукт является лишь минимальным функционалом и способом проверить гипотезу о его полезности
Шаг 2: Анализ рынка и исследование целевой аудитории
Оценка рынка и изучение целевой аудитории поможет вам понять, насколько популярным может стать ваше приложение и какие функции могут быть востребованы пользователями. На этом этапе также стоит изучить возможную конкуренцию и найти способы, как ваш продукт может выделиться.
Шаг 3: Прототипирование и дизайн
Прототипирование поможет вам визуализировать на первых этапах основные функции и интерфейс вашего приложения. Создание wireframe и дизайна играют важную роль в том, чтобы пользователи и инвесторы могли лучше понять, что вы хотите создать и смочь визуально оценить внешний вид и удобство использования продукта.
Шаг 4: Разработка основных функций
Следующий этап — разработка основных функций вашего приложения. В MVP стоит сосредоточиться на самых важных и неотъемлемых функциях, которые помогут достичь цели вашего проекта. Не забывайте об удобстве использования и простоте интерфейса.
Шаг 5: Тестирование и сбор обратной связи
Шаг 6: Запуск MVP
После успешного завершения тестирования и учета обратной связи, вы готовы к запуску MVP вашего мобильного приложения. Не забудьте провести предварительное продвижение и маркетинговые мероприятия, чтобы привлечь первых пользователей и оценить их реакцию на ваш продукт.
Шаг 7: Анализ и оптимизация
После запуска MVP следует проанализировать его успех и провести оптимизацию продукта. Обратитесь к аналитике и обратной связи пользователей, чтобы разобраться, какие функции работают хорошо и каким образом вы можете улучшить приложение. Постепенно добавляйте новые функции и развивайте продукт в соответствии с потребностями пользователя.
Помните, что MVP — это только первый шаг в разработке вашего мобильного приложения. Основная задача — проверить гипотезу о его полезности и спросе на рынке. Постепенно развивайте и совершенствуйте свой продукт, чтобы создать идеальное приложение для ваших пользователей.
Как правильно сделать MVP?
Шаг 1. Обозначьте проблему, которую хотите решить
Первое, что нужно сделать, — сформулировать цель продукта.
Ответьте на вопрос: «Для чего нужен этот продукт?».
Переходите к следующему шагу, как только четко изложите в нескольких словах ценность продукта.
Например, если вы хотите открыть сервис доставки еды, проблема, которую вы хотите решить, может звучать так: «Обеспечить пользователям получение еды из местных ресторанов навынос».
Шаг 2. Определите целевую аудиторию и сузьте ее
Удовлетворить потребности широкой аудитории — ошибочное решение. Увеличьте свои шансы на успех — выберите определенную аудиторию.
Сделайте развернутое описание персоны, которой может понравиться ваш продукт.
Представления об образе жизни интересной вам аудитории помогут понять, сможет ли ваш будущий продукт решать проблемы потенциальных покупателей, с которыми они сталкиваются регулярно.
Шаг 3. Проанализируйте конкурентов
Не переоценивайте эксклюзивность своего продукта, особенно если заранее знаете о других компаниях в отрасли. Проанализируйте конкурентов.
Выясните их сильные и слабые стороны, чтобы определить функциональность своего будущего продукта.
“Проанализируйте трех главных игроков рынка, узнайте, как долго они существуют на нем, какие продукты и услуги предоставляют. Определите, есть ли у них конкурентные преимущества и оцените свою способность предложить что-то лучшее.”
Шаг 4. Определите карту путей пользователя
User flow — путь, который проходит пользователь при взаимодействии с продуктом. Он должен быть логичным и понятным.
Карта путей пользователей — руководство с требованиями к контенту и дизайну сайтов / приложений.
При построении хорошей карты путей пользователей вы должны понимать, что хотят получить клиенты при использовании вашего продукта.
Убедитесь, что вы предоставили пользователям дополнительную информацию и выясните возможные недочеты, которые могут помешать им перейти на следующий шаг.
Шаг 5. Составьте список функций с градацией по приоритету
Вам необходимо перечислить обязательные функции для будущего продукта.
Вы должны выяснить, насколько важна и ценна конкретная функция, как часто она используется, имеет ли риски, сколько пользователей к ней обращаются.
После того, как вы упорядочили функции в соответствии с их приоритетом, начертите вертикальную линию и разместите их в нужной последовательности
Самое важное и часто используемое поставьте в верх списка, остальное — разместите снизу
Шаг 6. Определите объем MVP
После того, как вы расставили функции по их приоритету, можно определить объем MVP.
Первый горизонтальный ряд на карте называется ходячим скелетом (каркасом).
Этот ходячий скелет — наименьшая полезная версия продукта, которой недостает «мяса», то есть функциональности. Сначала мы должны создать каркас.
В некоторых случаях MVP совпадает с каркасом, а иногда обладает ограниченной функциональностью.
Чтобы понять, какие есть отличия между каркасом, минимально жизнеспособным продуктом и его дальнейшей концепцией, вы должны классифицировать функции.
Шаг 9. Используйте альфа- и бета-тестирование
Альфа -так называемое внутреннее тестирование, когда ограниченная группа людей оценивают продукт.
Если продукт прошел этот тест, вы можете перейти к бета-тестированию — позволить реальным пользователям попробовать продукт в течение одной-двух недель.
Проанализируйте обратную связь и определите, какие функции необходимо добавить или заменить, чтобы сделать продукт лучшим.
Если вы собрали достаточно отзывов, можете обновить продукт, затем снова протестировать его и получить обратную связь.
Количество циклов «создания-тестирования-обучения» и их временные рамки зависят от продукта.
Дизайн, разработка и запуск MVP
После планирования и выбора функций наступает этап проектирования, разработки и запуска. Этот этап включает набор основных функций для создания первой версии MVP. Этот этап направлен на поиск баланса между экономичностью, простотой и соответствием ожиданиям.
Минимальный продукт поможет сосредоточиться на значимых аспектах, а не работать над всем сразу. Если есть неосуществимые функции, можно легко перестроить или соответствующим образом отредактировать приложение и добавить их в будущих итерациях.
Разработчики MVP могут контролировать приложение на этапе разработки и тестирования, что упрощает непрерывные итерации. Разработчикам проще собирать отзывы и улучшать функциональность позже.