Mvp приложение что это
Что такое и зачем нужен MVP
Мы часто говорим об MVP (minimum viable product) когда речь заходит о разработке. О том, что это минимально жизнеспособный продукт знают многие. Но мы решили еще шире раскрыть это понятие и подробно рассказать о значении MVP в процессе создания новых продуктов.
Представим, что у вас есть идея — приложение с полным набором функций и опций, доступное на всех платформах, способное обслуживать миллионы пользователей по всему миру. Отлично!
А теперь давайте переведем разговор в более приземленную плоскость и сделаем вид, что идея вашего приложения — это эклер. Но не просто пирожное, а экстра-эклер в форме таксы, заправленный кремом на основе альпийского масла, со взбитыми сливками и посыпкой из трех видов шоколада. Это вкусный, привлекательный и очень сложный продукт. А еще непонятно, нужен ли он людям.
Здесь-то и пригодится MVP, чтобы проверить идеи. Самая первая версия вашего приложения должна быть больше похожа на простой эклер — тот, что люди знают, любят и хотят попробовать от нового поставщика. MVP приложения должны быть включены только основные функции. Когда будет готов программный продукт, с ним можно познакомить пользователей. Такое решение будет относительно дешевым и быстрым в разработке.
Форма MVP и конечного продукта зависит от технологии разработки. Это могут быть нативные или кроссплатформенные решения, о таком выборе мы уже писали в нашем блоге, загляните.
В любом случае стоит проконсультироваться с разработчиками, с которыми вы решили сотрудничать. Они дадут информацию о сроках, затратах, размере команды и, возможно, предложат новые решения. Например, вместо создания мобильного приложения вы можете начать с PWA (прогрессивное веб-приложение) и собирать отзывы от первых пользователей, прежде чем тратить ресурсы на реальный продукт.
С живым приложением вы можете продолжить разработку, основываясь на фактах, а не на предположениях. Реальные пользователи протестируют продукт и дадут обратную связь: расскажут, что им не понравилось, а что нужно добавить.
Благодаря отзывам вы узнаете, как поживает ваш «обычный эклер» и получите дополнительную информацию о том, как его можно улучшить. Если никто не просит оригинальную форму таксы, возможно, пока нет смысла вкладывать средства в ее разработку.
Подход MVP дает хорошее представление о будущих потребностях в развитии продукта. Вы можете продолжать добавлять сливки и посыпать эклер. Но что, если продукт станет настолько популярным, что люди захотят его повсюду, а не только в одной кондитерской? Тогда будет актуальней задуматься о масштабировании.
Мобильное приложение будет иметь ограничения на количество пользователей, которые оно может обслуживать, не засоряя сервер. У него также есть географические ограничения — язык или страны, в которых оно доступно. Имея данные об использовании приложения, вы теперь можете расставить приоритеты, что делать дальше: совершенствовать рецепт или открывать новые кондитерские.
Причина номер один. Минимально жизнеспособный продукт становится упрощением большого проекта и позволяет узнать, чего хотят пользователи. Становятся очевидны потребности рынка и функции, имеющие решающее значение для успеха продукта. Это идеальный способ проверить предположения и получить четкое представление о пути, по которому должен идти проект.
Причина номер два. Стартапам получить инвестирование с помощью MVP проще, потому что есть прямая презентация действующего мобильного приложения. Это демонстрирует серьезность намерений и укрепляет позиции.
Причина номер три. MVP дает возможность узнать, как компоненты UX и UI способствуют удобству использования и интуитивности мобильного приложения.
Причина номер четыре. MVP также является отличной стратегией для проверки идей монетизации. Гипотезы для заработка лучше протестировать с помощью MVP и определить, какая из них принесет наибольшую прибыль.
Причина номер пять. С помощью MVP можно быстрее выйти на рынок и по-прежнему иметь достаточно пространства для изменений.
Минимальный жизнеспособный продукт дает возможность стать лучше: вы сможете вносить существенные изменения в бизнес-процессы, основываясь на реальном пользовательском опыте. Можно отложить разработку менее важных функций и потратить деньги на срочные задачи.
Предположим, у вашего эклера есть серьезный недостаток, например, плохое качество муки. В таком случае это будет важнее исправить, чем добавлять новые фичи и еще больше усложнять ситуацию.
MVP — это перспективный путь реализации идей с опорой на потребности пользователей и требования владельца.
Если убрать демагогию и манипуляцию с сознанием заказчика, то придется вместо:
«что идея вашего приложения — это эклер. Но не просто пирожное, а экстра-эклер в форме таксы, заправленный кремом на основе альпийского масла, со взбитыми сливками и посыпкой из трех видов шоколада. Это вкусный, привлекательный и очень сложный продукт. А еще непонятно, нужен ли он людям.»
написать:
«что идея вашего приложения — это небоскреб. И не просто небоскреб, а 200-этажный небоскреб в форме летящей чайки и прозрачный после 115-го этажа. Это очень сложный продукт. А еще непонятно, нужен ли он людям. «
Поэтому давайте очень быстро из говна и палок построим сарайчик дачного типа, и расскажем заказчику, что строя сарайчик мы поняли, из КАК и из КАКИХ МАТЕРИАЛОВ строить небоскреб. ))) Идеи в статье применимы, если инфоцыганам нужно тестировать две гипотезы в неделю на маркет фит, или если нужно сделать одностраничник для кофейни. Для чего-то посложнее нужен архитектор, исследование и бэкенд, где сосредоточено 80% системы.
Что такое MVP и как это использовать
MVP — это паттерн, который используют многие разработчики, даже если не догадываются об этом. Может, вы один из них?
MVP — это паттерн программирования графических интерфейсов. В нём приложение делится на три компонента:
Как и другие подобные паттерны (MVC, MVVM), MVP позволяет ускорить разработку и разделить ответственность разных специалистов; приложение удобнее тестировать и поддерживать.
Чаще всего его используют разработчики мобильных приложений, однако он гораздо популярнее, чем может показаться. Дело в том, что этот паттерн активно применяется в вебе, хотя там его и называют MVC:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Как работает MVP
На схеме выше видно, что приложение, созданное по принципам MVP, работает с помощью связи модели, вида и представителя. Происходит это так:
Основное отличие MVP и MVC в том, что в MVC обновлённая модель сама говорит виду, что нужно показать другие данные. Если же этого не происходит и приложению нужен посредник в виде представителя, то паттерн стоит называть MVP.
Всё это можно сравнить с работой издательства:
Конечно, это не точный алгоритм работы издательства, но для иллюстрации принципов MVP его достаточно.
Пример MVP-приложения
Так как MVP служит для упрощения разработки графических интерфейсов, рассмотреть его можно на примере WPF-приложения. В качестве вида будут выступать файлы MainWindow.xaml (разметка интерфейса) и MainWindow.xaml.cs (обработчик событий).
Начать можно с создания интерфейса авторизации:
Как создать MVP: еще один гайд от Purrweb
В AppStore и Google Play доступны буквально тысячи приложений. С таким разнообразием становится сложно создать нечто уникальное и привлечь аудиторию. В то же время большинство стартапов проваливаются на первых этапах, а 21% пользователей удаляет приложения после первого использования.
Время чтения: 5 минут
Что такое MVP и где здесь ловить выгоду?
MVP (Minimal Viable Product, минимально жизнеспособный продукт) — версия приложения, сокращенная до основных функций. Главная цель MVP — понять, насколько «живуча» идея и собрать фидбек без больших вложений в разработку. Вот еще несколько преимуществ, которые вы получите с MVP:
1. Маркет-чек идеи
Выше говорили, что рынок мобильных приложений переполнен. Предложить что-то особенное, что-то такое, что решит проблему целевой аудитории — только так можно выделиться среди конкурентов. А хорошо сделанный MVP поможет понять, соответствуете ли вы этому критерию.
Если MVP взлетел на рынке, полноценное приложение с такими фичами тоже ждет успех. Кроме того, вы познакомите аудиторию с брендом, вас станут узнавать, появится лояльная аудитория будущих пользователей.
2. Экономия бюджета
Один из исходов, к которому нужно подготовиться — приложение может провалиться. Это может произойти по разным причинам — на некоторые факторы нельзя повлиять. Например, Это не значит, что надо сейчас же забыть об идее, но лучше всегда помнить о рисках.
Если вы решите сходу разработать продукт со всеми задуманными функциями, и ваша идея провалится — вы зря потратите все ресурсы. Разработка MVP требует меньше вложений, поэтому в случае провала у вас все еще будут средства на «вторую попытку». — измените что-то в вашем приложении или начните новый проект.
3. Целевая аудитория и фидбек
Создание MVP продукта привлечет самых активных пользователей. Даже если фидбек по приложению только с основными функциями не такой существенный, как по полноценному, это не значит, что он не нужен. Используйте его в следующих итерациях и продолжайте открыто общаться с юзерами.
5 шагов к MVP
Шаг 1. Проводим иследование
Перед разработкой всегда проводите исследования. Когда речь идет об MVP, нужно четко понимать проблему, которую решит приложение, и людей, у которых эта проблема существует — целевую аудиторию.
Держи друзей близко, а врагов еще ближе. Другими словами, изучайте конкурентов. Что отличает ваш продукт, как улучшить решения, которые уже существуют на рынке?
Шаг 2. Определяем основные функции
Когда определились с проблемой, настало время решать, какие фичи будут ее решать. У вас есть список самых полезных фич приложения? Это и есть основные функции продукта, которые нужно включить в MVP.
Если сложно определить главные фичи, вспомните о том, что MVP продукта, в первую очередь, ориентируется на клиента. Сосредоточьтесь на тех функциях, которые принесут максимум пользы. Но не забывайте, что на MVP не стоит тратить много ресурсов — выбирайте фичи с умом.
Шаг 3. Намечаем пользовательские сценарии
Когда все приготовления завершены, время начинать дизайн процессы. На этом этапе нужно посмотреть на продукт глазами пользователя. Определите маршрут, который проведет пользователя от установки приложения до решения его задачи.
Путешествие пользователя по приложению должно быть логичным и интуитивным. Пользовательский сценарий (юзер флоу) — это одновременно набор отдельных действий и цельный процесс.
Шаг 4. Разрабатываем и запускаем MVP
Что касается дизайна, он не должен отвлекать от сути приложения, так что избегайте сложных элементов, быстрой смены экранов и запутанной анимации. Сделайте отдельный экран для каждого процесса и подумайте, как пользователь будет перемещаться между ними. MVP все еще решает проблему пользователя, не воспринимайте его как окончательную версию продукта.
Шаг 5. Собираем фидбек — и погнали дальше!
Последний по счету, но не по значению шаг: после запуска MVP собрать отзывы и спросить потенциальных пользователей о впечатлении от приложения. Фидбек не только поможет оценить успех идеи, но и откроет новые пути развития.
Будьте готовы к тому, что не вся обратная связь полезная. Анализируйте, выбирайте самые конструктивные идеи, вносите изменения и тестируйте. И так снова и снова. Разработка MVP для стартапа — итеративный процесс, а в конце получается полноценное приложение.
Как понять, что MVP ждет успех?
Несколько метрик помогут понять, взлетит или не взлетит MVP приложения:
Чем больше людей взаимодействуют с MVP, тем успешнее приложение. Если число юзеров не растет, поищите проблему в UI/UX дизайне или маркетинге.
Такие пользователи тоже существуют, и это нормально. Правда, если приложение удаляют все и сразу, с ним, наверное, что-то не так. Число удалений рассчитывается как отношение количества пользователей, отказавшихся от приложения в течение определенного периода, к общему количеству пользователей в начале этого периода
Озвучим очевидную вещь: чем больше денег, тем успешнее MVP. Другая метрика — средний ежемесячный доход с каждого пользователя. Эти два показателя взаимозаменяемые.
Этот показатель рассчитывается так: делим деньги, которые вы потратили на трафик, на количество пользователей, полученных от этого трафика. Чем меньше это число, тем успешнее MVP.
Избегаем распространенных ошибок
1. Переработки и недоработки
Чем больше фич, тем больше ресурсов потребуется. Много фич отвлекают пользователя от основной функциональности. К тому же, разработка MVP не должна отнимать много времени, так что если работа над ним длится уже который месяц — стоит резать скоуп.
«Недоразработать» MVP — тоже ошибка. Хорошего фидбека не будет, если приложение сложно использовать, в нем много багов или оно не несет никакой пользы. Жаль, что не существует способа проверить, достаточно ли MVP качественный. Так что важно, чтобы в команде был разработчик с опытом создания минимально жизнеспособного продукта.
2. Не те основные фичи
Основные функции приложения должны не только решать проблему пользователя, но и выделять вас среди других игроков на рынке. Если приложение не предлагает ничего нового, интерес у пользователей оно не вызовет.
Однако, быть уникальным не всегда значит быть классным. В погоне за уникальностью легко навести беспорядок в приложении. Нужно понимать продукт и то, как его хочется представить на рынке. Иначе есть риск произвести негативное впечатление и не собрать фидбек.
3. Не та аудитория
4. Проблемы с обратной связью
А еще есть проблема «количества и качества» обратной связи. Первое фокусируется на вопросе «Как много?», а второе на «Почему?» Если зациклиться на что-то одном, то комплексного взгляда на MVP не получится. Держите баланс!
5. Так себе команда разработки
Неважно, как хороша и уникальная идея, как четко вы все спланировали и рассчитали, если страдает реализация. Недостаточно иметь хорошие инструменты — нужно, чтобы их держали умелые руки.
Существует много вариантов, как найти умелых подрядчиков — от найма внутренней команды до обращения на аутсорс. Возможностей масса! Выбирайте ту, что подходит по бюджету и направлению проекта.
Финалочка
Если все сделать правильно, MVP станет хорошим стартом для любого приложения. Без него, конечно, можно обойтись, но лучше не избегать этой стадии. Знаете Uber, Snapchat и Spotify? Их объединяет то, что она стартовали с MVP. Не бойтесь воплощать идеи — возможно, они станут всемирно известными приложениями. Обратитесь в агентство с экспертизой в разработке MVP — например, Purrweb — и творите историю уже сейчас!
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
руководитель направления мобильной разработки компании Neti
Практически каждый современный бизнес хочет обзавестись мобильным приложением. Одни используют его для связи с клиентами, другие — для автоматизации внутренних процессов и повышения эффективности сотрудников. При этом сегодня все больше компаний разрабатывают мобильные приложения для доставки в условиях самоизоляции.
О том, как создается прототип и зачем нужен MVP мобильного приложения, рассказывает Наби Ибатулин, руководитель направления мобильной разработки компании Neti.
Преимущество мобильного приложения заключается в том, что оно нативно работает на смартфоне или планшете пользователя. Однажды установленное на устройство, мобильное приложение потребляет минимум трафика, может работать в автономном режиме и потенциально создает обширные возможности для персонализации.
Но для этого нужно тщательно проработать как логику функционирования приложения, так и его интерфейс.
Прототип мобильного приложения
В мобильной разработке прототипом обычно называют проработку пользовательского интерфейса. Основная задача на стадии прототипа заключается в том, чтобы нарисовать внешний вид экранов, а также продумать логику перехода между ними. Прототип может создаваться как самим заказчиком, так и дизайнерами подрядчика.
Прототип приложения — пример набора экранов
Для простых приложений, таких как мобильная версия интернет-магазина или форма заказа блюд из ресторана, прототип выглядит достаточно просто. В нем должен содержаться каталог, корзина и форма отправки заказа.
Для более сложных приложений, содержащих чаты, интегрированных с картой или платежными шлюзами, поддерживающих программы лояльности, прототип будет выглядеть сложнее. Поэтому на его разработку уходит больше сил и времени.
Запуск в формате MVP
Хорошо, когда вы понимаете, каким должно быть приложение, четко формулируете спектр его функций и возможностей и предоставляете исполнителю исчерпывающее техническое задание. Однако в 90% случаев ситуация складывается иначе, и менеджеры разработчика участвуют в создании концепции мобильного приложения вместе с заказчиком.
На большинстве проектов используется подход MVP (Minimum Viable Product). В состав MVP обычно входят только самые базовые элементы мобильного приложения.
Например, если речь идет о заказе товаров на дом, MVP будет включать в себя каталог и форму заказа. Такие функции, как оплата в приложении, встроенный чат и поддержка push-уведомлений, как правило, реализуются на следующих этапах.
Белые — часть MVP, серые — для последующей реализации
Запуск MVP позволяет предложить пользователям первую версию своего мобильного приложения намного раньше, чем если бы разработка велась сразу по всем предполагаемым функциям.
В зависимости от проекта, MVP приводит к значительному сокращению time-to-market — иногда даже до 10 раз!
Возможность получить первичный фидбек от своих пользователей помогает скорректировать или сформулировать стратегию развития приложения. Например, может оказаться, что вам вовсе не нужна геолокация или интеграция платежного шлюза. Это позволит сэкономить время и средства, которые ушли бы на реализацию этой функции.
Использование кросс-платформенных фреймворков
Разработка мобильного приложения начиная с MVP может происходить нативно для конкретных платформ — например, iOS и Android, — либо на базе универсального фреймворка.
Используя Flutter или React Native можно создать одно приложение, которое будет работать сразу на всех платформах. Таким образом, время разработки уменьшается как минимум вдвое, а любые изменения и доработки отражаются на версиях для всех платформ.
Минусы такого подхода — это увеличенный размер приложения и незаметное для пользователя снижение производительности. Но для бизнес-проектов зачастую гораздо критичнее оказывается time-to-market.
Интеграции мобильного приложения
Еще один важный момент, о котором нужно помнить при разработке мобильного приложения, — это наличие серверной части. Даже когда запускается первая, упрощенная версия MVP, приложение с мобильного устройства клиента должно обращаться к серверу, получать и отправлять данные.
Если речь идет о мобильном приложении для бизнеса, то на серверной стороне бывает полезно сразу провести интеграцию с другими системами.
Например, у многих уже есть каталог в 1С, используется CRM для приема заказов либо уже подключена система лояльности, которую логично использовать в мобильном приложении. Вместо разработки дублирующих решений логично настроить интеграцию и использовать имеющиеся системы.
Дальнейшее развитие
После успешного прохождения стадии MVP мобильное приложение продолжает развиваться и обрастать функциональностью. Дальнейшая разработка может происходить в самых разных форматах, с использованием фреймворков или без них.
Но самое главное — тщательно проработать стадию прототипа и MVP, потому что вносить изменения в уже реализованные элементы дольше и дороже, чем планировать постепенное развитие продукта и на каждом этапе адаптировать свое видение мобильного приложения к запросам реальных пользователей.
Как достичь максимума
Если вы решили создавать мобильное приложение, перед стартом проекта следует выполнить следующие шаги:
От идеи мобильного приложения до MVP, в который вложатся инвесторы
Как создать MVP приложения, в который вложатся инвесторы
Шаг 1. Составить требования
Шаг 2. Выбрать компанию-разработчика
Шаг 3. Создать ТЗ и собрать прототип для фокус-групп
Шаг 4. Разработать и протестировать приложение
Шаг 5. Опубликовать приложение
Как найти инвестора?
Раунд 0. Если есть идея, но нет продукта
Раунд 1. Если есть готовый MVP без монетизации
Раунд 2. Если есть готовый MVP c монетизацией
Другие способы привлечения инвестиций
Полезные ссылки
MVP (Minimum Viable Product) — дословно минимально жизнеспособный продукт.
В статье сконцентрированы полезные советы и даны ответы на следующие вопросы:
Вы загорелись идеей создать мобильное приложение, не нашли аналогов, и осознав насколько много людей готовы платить за его функционал, поняли — нужно действовать.
Получили оценку стоимости от множества агентств и пришли к выводу — на качественную разработку приложения и маркетинг для запуска проекта Ваших средств недостаточно.
Если этот шаг ещё не пройден — в конце несколько полезных ссылок на сайты, которые помогают произвести самостоятельную оценку стоимости разработки.
Идеи летают в воздухе и медлить значит отдать идею тому кто смог привлечь инвесторов.
Прийти с одной только идеей к инвестору можно, но если есть бюджет, то для старта лучше разработать MVP мобильного приложения и уже с ним найти инвестиции.
Во-первых, если идея действительно стоящая, то просто изложив её инвестору и получив отказ, спустя некоторое время на очередной презентации можно случайно узнать, что идея почти реализована именно теми людьми, которые не пожелали вложиться в Ваш проект.
Тем же могут грешить и бизнес акселераторы, обещающие привлечь инвесторов, ведь теория вероятности подобных событий не исключает.
Если Вы приходите к инвесторам как полноправный владелец приложения, все играет другими красками.
MVP (Minimum Viable Product) — дословно минимально жизнеспособный продукт.
Применимо к мобильному приложению жизнеспособный равно полезный пользователю, ведь если целью создания была монетизация, то в первой версии приложения обязательно должен присутствовать функционал, представляющий ценность для аудитории.
Аудитория должна быть либо многочисленной, либо с узкоспециализированной потребностью и проблемой, которую не могут решить существующие сервисы и приложения.
Проблема и потребность аудитории при идеальном раскладе возникает с некоторой периодичностью, а не единожды.
5 шагов для создания MVP мобильного приложения, в который вложатся инвесторы
Составить требования к MVP который будет соответствовать ожиданием пользователей и инвесторов.
Хороший MVP в понимании инвесторов должен иметь формулу монетизации:
Возможно из “Дохода” придется вычесть комиссию APP STORE в размере 30 %, поэтому нужно четко понимать с каких платежей взимаются эти комиссии, информация о том за какие функции приложения придется произвести откат стору есть на официальном сайте apple.
Если с численностью аудитории и монетизацией всё ясно, можно переходить к следующему шагу.
Вторым шагом будет именно выбор разработчика, а не написание технического задания, т. к. доверить описание функционала и выбор технологий разработки лучше конечным исполнителям. Если Вы не специалист из IT сферы, самостоятельно составить ТЗ, в котором будут учтены все нюансы, будет очень сложно.
В следующем пункте будут рекомендации по подготовке материалов для разработчиков, уменьшающие стоимость разработки ТЗ (спойлер: именно Вы, как автор идеи, наилучшим образом можете описать пользовательские истории).
Признаки компаний которые идеально подходят для реализации и поддержки мобильных стартапов:
Компании из региона, и у них нет клиентов “гигантов” которых они поддерживают не первый год, как у крупных столичных компаний.
Такие разработчики имеют амбиции и адекватное ценообразование, с охотой возьмутся за реализацию MVP и не отодвинут на его на задний план в самый ответственный момент, потому что крупный клиент внезапно захотел масштабное обновление.
Разработчики которые не темнят, называя стоимость (велика вероятность что подробного ТЗ на шаге запроса стоимости у Вас не было и вилку стоимости все называли по разному).
Обратите внимание на коммерческие предложения, в которых есть разбивка работ с указанием человеко часов, затрачиваемых на конкретные работы, сравните объем информации, который разработчики запрашивали для оценки, чем подробнее был бриф и глубже был рассмотрен проект тем адекватней подход компании.
Компании с гибким подходом к этапам оплат и разработки.
Изучите NDA (соглашение о неразглашение коммерчески ценной информации) и типовой договор компании разработчика и обязательно обсудите возможность разработки и оплаты с разбивкой по этапам, в каждом из которых есть осязаемый результат либо в виде исходного кода, либо в виде части полноценно завершенных работ, например: этап дизайн — при принятии работ переданы все материалы для верстки и макеты в векторном формате, второй этап верстка — полностью завершена и реализована точно по согласованным ранее макетам. Если от предложенного Вами подобного формата компания отказывается это повод задуматься.
Составление технического задания и сборка кликабельного прототипа для фокус группы
Чтобы написать техническое задание самостоятельно:
Описать все (а не только идеальные) пользовательские шаги с учетом всех возможных сценариев взаимодействия пользователя с приложением (пример одного из сценариев “когда что то пошло не так”- разрыв соединения с интернетом или входящий вызов, при совершении какой либо операции в приложении. Что должно произойти? Например кеширование данных для повторной отправки и т.п.)
Исследовать рынок мобильных устройств на предмет активного использования определенных моделей устройств у Вашей аудитории и возможностей данных устройств относительно необходимых Вам функций. Это необходимо для указания в ТЗ версий мобильных ОС которые необходимо поддерживать разработчику (в том числе это влияет и на стоимость, больше версий выше стоимость).
Продумать структуру интерфейса обеспечив всем пользователям одинаковый UX (пользовательский опыт). Пример: авторизация с помощью Touch ID. Сам Touch ID есть не на всех устройствах, но пользователи поменявшие устройство за время использования мобильного приложения тоже хотят пользоваться этой функцией, поэтому возможность задать отпечаток пальца для авторизации должна быть не только на экранах регистрации, а например и в настройках профиля.
В приведенном примере сценарий “не смертельный”, а всего лишь ухудшающий пользовательский опыт (и хорошо если такой непродуманный сценарий всего один иначе раздражение пользователя превращается в снежный ком), но в некоторых случаях упущенное и непродуманное требование к функционалу может быть весьма критичным для использования приложения, например: пользователь вынужден через приложение заполнять множество полей заявки (такой уж бизнес процесс) и вдруг пресловутый входящий вызов… Все заполненные поля пусты? Если да, это печально… Кто виноват? Это было в ТЗ?
Прописать архитектуру взаимодействия базы данных, сервера, клиентских приложений, административной панели — составить корректное описание может только специалист.
Должны быть учтены множество нюансов.
Второй вариант заказать техническое задание у разработчиков:
ответить на их вопросы и получить качественное ТЗ.
В большинстве случаев техническое задание пишут параллельно с разработкой дизайна приложения или с его прототипированием.
Это удобно и рационально.
Из макетов экранов можно собрать кликабельный прототип, с помощью которого впоследствии можно проверить и удобство использования и корректность заложенных в дизайн шагов пользователей.
Такой прототип можно собрать с помощью бесплатных сервисов InVision, Moqups, Marvelapp.
Третий путь золотая середина между первым и вторым: описываете подробно сценарии (и иллюстрируете их в прототипах) и отдаёте их разработчикам для оформления ТЗ.
Техническое задание описывающее те сценарии которые Вы отразили в прототипах, дополненное разработчиками описанием технических “подводных камней”, будет стоить в разы меньше относительно ТЗ которое студия составляла бы с Вами с нуля.
С разработкой всё просто ведь есть ТЗ и дизайн, а вот на тестирование нужно обратить особое внимание, по хорошему разработчик должен предоставить отчет о тестировании в формате закрытых чек листов с привязкой к устройствам и платформам подтвердив что все предусмотренные ТЗ сценарии работают на поддерживаемых устройствах корректно.
Пятый шаг публикация в маркетах, с одной стороны это финишная прямая и здесь только одно предостережение не привязывать события связанные с продвижением к каким либо датам до прохождения ревью в APP STORE, просто представьте себе как будет неприятно организовать мероприятие, целью которого является демонстрация приложения и в последний момент выяснить что презентовать его не возможно, так как оно ещё не опубликовано. Поэтому сначала пройдите ревью и только потом назначайте даты презентаций.
Раунды развития проекта и где искать инвестора в зависимости от раунда:
Как привлечь инвесторов если Вы находитесь на раунде “0”?
На раунде который называют нулевым нет продукта как такового и лучшим вариантом поиска инвестиций будет вложение (или внушительная скидка) со стороны разработчиков проекта.
Реализуя проект как внутренний (иначе говоря “свой собственный” с потенциалом получения прибыли) разработчики однозначно выберут масштабируемую архитектуру, оптимальный стек технологий, безопасные способы хранения данных и прочие составляющие обеспечивающие стабильное развитие проекта и рациональные расходы на сторонние сервисы.
Совет Если Вы находитесь на раунде “0” — описывая идею разработчикам акцентируйте внимание на схеме монетизации сервиса предположите, как быстро могут появится конкуренты которые попытаются воспроизвести функционал Вашего сервиса.
Эти два пункта (помимо уникальности идеи) будут особенно важны для принятия решения о вложении в Ваш проект. Из них следует условная нагрузка (которую разработчик будет сопоставлять с имеющимися рабочими ресурсами) и формируется понимание того как часто и с какой скоростью необходимо выпускать обновления чтобы оставаться наиболее успешным из подобных сервисов (возможно Ваша идея не на 100% уникальна и Вы создаёте лучшую версию существующего сервиса, тогда этот пункт особенно важен).
Соответственно сами Бизнесаксилераторы (в финале статьи перечень наиболее популярных) безусловно полезны для проектов, которые самостоятельно не могут произвести качественное исследование аудитории и конкурентов, выстроить план развития и продвижения, более того у акселераторов есть “каналы сбыта” фондам и бизнес-ангелам. Но всё же если у Вас уже сформировано общее представление проекта по всем пунктам, которые я описывал Выше то Вам не стоит “платить дважды”, так как на инвесторов и бизнес ангелов можно выйти самостоятельно да и консалтинг никто не отменял.
Как привлечь инвесторов если Вы находитесь на раунде “1”?
Когда проект готов к запуску и можно продемонстрировать его полную функциональность хотя бы на тестовых пользователях то можно транслировать идею бизнесу (конкретной компании) особенно если проект имеет специфику полезности для специалистов конкретной сферы.
Если проект такой специфики не имеет то легче будет донести информацию о потенциале и перспективах приложения частному инвестору или бизнесмену с высокой социальной активностью интересующемуся it сферой и имеющему хотя бы базовое представление о том как монетизируются it проекты, “консервативному бизнесу“ презентовать MVP будет труднее это очевидно.
Где же ловят бизнес ангелов проекты первого раунда?
Наиболее адекватный формат это демо день или так называемый день инвестора информация о запланированных демо днях размещается всеми крупными компаниями в свободном доступе
вот кстати интересный обзор от участника такого демо дня в котором даны рекомендации по подготовке к выступлению https://vc.ru/flood/43855-den-investora-demo-day-ili-kak-ya-prezentoval-startap-za-3-minuty
Если Вы находитесь на раунде номер 2 то лучшим вариантом Вашего опыта будет отсутствие потребности в инвестициях так как полезный продукт, который уже монетизируется с большой долей вероятности можно поддерживать и развивать самостоятельно (по крайней мере рассматриваемый нами продукт мобильное приложение).
Если инвестиции все же необходимы то:
Есть ли другие способы “получить средства на проект”?
Дайджест полезных ссылок в продолжении темы:
Публикации и электронное издание Романа Янковского
(Автор книги «Закон стартапа», «Венчурный юрист», к.ю.н., преподаватель в МГУ.)