Если вы задумались о создании мобильного приложения для своего бизнеса или о начале бизнеса с новым мобильным приложением, здесь вы найдете несколько слов о создании его первой версии.
946 просмотров
Это определенно хорошая идея — попробовать создать версию, которая содержит только самые важные функции и отвечает самым важным целям, чтобы планировать дальнейшую работу на основе собранной информации.
Привет, меня зовут Глеб Шалимов, я студен Университета Иннополис. В свое телеграмм-канале я нахожу интересные стартапы на Product Hunt и рассказываю о них. Буду очень рад, если Вы подпишитесь на канал.
Перед вами перевод статьи из блога FiveDotTwelve. Сейчас в университете мы как раз проходим предметы, связанные с созданием своего сервиса, поэтому мне есть, чем поделиться с вами.
Что значит создать первую версию мобильного приложения?
Есть множество причин называть продукт, который вы планируете создать, «первой версией». Существуют также различные термины, которые используются как взаимозаменяемые с «первой версией», такие как MVP и MMP. Все зависит от целей вашего продукта.
Быстрое создание Portable версий программ | PC-Lessons.ru
Первая версия мобильного приложения обычно является результатом:
- ограниченный бюджет
- желание проверить идею и продукт, прежде чем вкладывать в него деньги
Как следует из названия, те, кто решает создать первую версию, обычно также планируют развивать ее дальше, создавая вторую версию, третью, и так далее, сколько потребуется. Кроме того, как уже упоминалось выше, это делается не только в ситуациях, когда бюджет проекта ограничен.
Потому что всегда стоит проверить и утвердить свое приложение, прежде чем вкладывать в него больше средств. Как только вы убедитесь, что первая версия вашего мобильного приложения соответствует поставленным целям, самое время приступить к разработке следующих функций!
Ключевые моменты для эффективного создания первой версии мобильного приложения — процесс
Давайте рассмотрим наиболее важные вопросы при создании первой версии собственного приложения и весь процесс его создания. Есть некоторые вещи, на которые вы должны обратить внимание, чтобы убедиться, что разработка вашего приложения не будет пустой тратой времени и денег.
У первой версии должны быть определенные цели, и чтобы их достичь, вам нужно позаботиться о нескольких вещах:
1. План и видение вашего продукта
Вам необходимо определить, что именно вы хотите создать — каким должен быть продукт, какую проблему он должен решать и какой функциональностью должен обладать. То есть, в широком смысле, вам нужно знать цели и видение продукта. Это позволит вам создать дорожную карту, чтобы команда знала, что делать, работа была структурирована, и в процессе разработки не возникало никаких изменений или дискуссий о том, что строить или менять.
Это также обеспечит эффективность работы всей команды.
Вы создадите первую версию своего мобильного приложения эффективно, если будете точно знать, что создавать.
Псевдо-вирус на python
2. Проведение маркетинговых исследований среди конкурирующих мобильных приложений
На рынке так много приложений, что вам будет трудно выделиться на фоне конкурентов. Кроме того, вряд ли удастся изобрести мобильное приложение, которое будет отличаться от всех остальных. Вот почему очень важно провести исследование и проверить, как работают и выглядят приложения конкурентов.
Проведите конкурентный анализ среди мобильных приложений ваших конкурентов, используя информацию из магазина Google Play, App Store и просто тестируя различные продукты. Обратите внимание на:
- Стратегии монетизации конкурирующих приложений
- Особенности конкурирующих приложений
- Отзывы пользователей
- Оценки пользователей
- Технологии, используемые для создания этих приложений
Исследование конкурентов поможет вам решить, какими функциями должно обладать ваше приложение, и даже как оно должно выглядеть, а также, возможно, поможет вам оценить, имеет ли идея такого приложения шансы на успех на рынке.
Проанализируйте свой бюджет. Если он достаточен, начните создание приложения в первой версии на целевом технологическом стеке, в хорошем качестве. В дальнейшем продукт будет развиваться на тех же технологиях, фреймворках и коде.
Однако если у вас недостаточно бюджета, выберите самое дешевое из возможных технологических решений, чтобы проверить, есть ли у вашей идеи потенциал для успеха. Выпуск продукта как можно скорее поможет вам проверить его на рынке и решить, стоит ли вкладывать в него деньги. Однако учтите, что если вы выберете этот путь и идея окажется успешной, качество может оказаться недостаточным, и вам, возможно, придется создавать еще одну версию продукта с нуля.
4. Команда разработчиков мобильных приложений
Правильная команда — это обязательное условие. Это, наверное, неудивительно. Если ваш бизнес основан на новой идее мобильного приложения, то, вероятно, не очень хорошая идея создавать собственную команду для разработки продукта. Многие компании потерпели неудачу, приняв такой подход. Если это что-то новое, совершенно новая идея и непроверенный продукт, вы должны помнить о том, что совершаете эту ошибку.
Процесс разработки мобильного приложения может длиться годами, и это может означать, что вам придется сотрудничать с командой разработчиков все это время, это правда. Но это только в том случае, если первая версия вашего приложения окажется действительно успешной, и вы решите продолжить работу над новыми функциями.
Это может показаться горьким, но правда в том, что ваша идея приложения может оказаться ошибочной. Тем не менее, это не значит, что вы всегда виноваты и что вы неудачливый создатель. Иногда дело, например, в неправильном выборе времени.
Вот почему так важно создать первую версию и проверить ее жизнеспособность, прежде чем думать о более сложных функциях и дальнейшей разработке. И именно поэтому чаще всего эту задачу лучше отдать на аутсорсинг, выбрав правильных людей.
Несколько советов о том, как найти такую команду:
- Не относитесь к исследованиям как к пустой трате времени — дело не только в качестве работы, хотя это, конечно, тоже важный фактор, но вы также должны просто выяснить, подходите ли вы и команда в плане общения и т.д.
- Просмотрите портфолио и тематические исследования — компании чаще всего рассказывают о своей предыдущей работе над различными проектами. Это определенно то, что должно вас заинтересовать.
- Проверьте отзывы и рекомендации — отзывы предыдущих партнеров могут многое рассказать о компании и команде. Обратите внимание на то, на каких этапах проектов находились предыдущие партнеры.
- Позаботьтесь о вопросах коммуникации — когда вы впервые обращаетесь в незнакомую вам компанию, очень важно, как вам понравится общение с ней.
Правильный выбор партнера имеет решающее значение, когда речь идет о разработке программного обеспечения, поскольку, если вы встретите компанию, которая заслужила доверие клиентов, она компенсирует недостатки в документации по видению продукта, а также отсутствие у вас технических знаний. Прежде всего, он позволит вам точно определить объем первой версии продукта и уложиться в реалистичные сроки в рамках гораздо более выгодного бюджета, чем полная версия продукта.
5. Выбор основных функций
Когда вы создаете приложение для первой версии, оно должно содержать только основные функции — самые важные. Нет смысла тратить время и деньги на сложные функции и сложный дизайн приложения, пока вы не уверены, будет ли оно приносить прибыль. Минимальная версия — это как раз то, что вам нужно на данном этапе.
Целевые пользователи должны иметь возможность протестировать основные функции и дать вам достаточно отзывов, чтобы вы могли начать планировать следующие этапы. Или решите остановить проект на этом этапе. Это может произойти.
Выбор правильного технологического стека
Это не значит, что вы вдруг должны стать техническим экспертом в области разработки приложений. Вам не нужно знать все технологии и фреймворки, которые могут быть использованы для создания мобильных приложений. Тем не менее, необходимо провести некоторые исследования по этому вопросу.
Например, исходя из вашей целевой аудитории, вы можете оценить, что лучше — создать приложение для Android или iOS, или выбрать кроссплатформенное решение (приложение, созданное для нескольких платформ одновременно).
Может оказаться, что большая часть вашей целевой группы — пользователи Android или iOS, и если вы решили создать приложение для пользователей одной платформы, вы можете создать нативное приложение. Нельзя сказать, что нативные приложения лучше или хуже кроссплатформенных, просто все зависит от вашего выбора функций приложения.
Изменение технологического стека для второй версии вашего приложения
Кроссплатформенные приложения обычно создаются быстрее, и это решение также может быть более экономически эффективным, чем создание двух отдельных приложений для двух платформ. Поэтому есть также возможность выбрать этот метод для создания первой версии приложения, а затем переписать код и продолжить внедрение новых функций с помощью различных фреймворков, например, создать нативное приложение.
6. Планирование выпуска следующих функций и обратная связь
Опять же, не пытайтесь создать обширный продукт, на создание которого уйдет шесть месяцев. Вы даже не знаете, приживется ли идея, и потеряете много времени и денег. После каждого обновления собирайте отзывы пользователей, анализируйте результаты, выясняйте потребности, внедряйте улучшения и снова собирайте отзывы.
Такая гибкая разработка продукта позволит вам как можно скорее проверить, насколько актуальна ваша концепция, соответствует ли она ожиданиям целевой группы, какие функции важны и их стоит развивать, а какие можно опустить.
Создание продукта в тесном контакте с пользователями и на основе данных даст вам наилучшие результаты.
7. Назначение первой версии вашего продукта
Вот основные цели выбора создания первой версии и проверки идеи перед планированием следующих функций и перед созданием полноценного продукта:
- Как можно скорее показать свой продукт миру
Конечно, завершением процесса создания первой версии приложения будет то, что мы хотим как можно скорее вывести продукт на рынок и показать нашу идею. Это нужно для того, чтобы понять, что нужно изменить, что оставить, и есть ли вообще смысл делать из этого бизнес, или идея оказалась ошибочной.
- Проверка идеи вашего приложения
Это одна из самых важных причин, по которой владельцы бизнеса создают первую версию своего приложения. Если вы хотите создать действительно успешное приложение, вам необходимо разрабатывать его в соответствии с отзывами пользователей приложения.
Вы можете найти их мнения в магазинах приложений, вы можете спросить их непосредственно в приложении или в социальных сетях, вы можете использовать любой метод, чтобы убедиться, что ваши следующие шаги будут прибыльными.
Эффективность — это видение, достижение больших целей в конкретные сроки и предоставление запланированной ценности. И все это в рамках запланированного бюджета. Но когда речь идет о результатах, касающихся самого продукта, все просто:
Эффективный продукт = продукт, который нравится пользователям
Поэтому при создании первой версии приложения следует уделять больше внимания требованиям целевой аудитории, чем, например, пользовательскому интерфейсу.
- Сбор отзывов пользователей и планирование дальнейшего развития
Учитывайте отзывы пользователей и планируйте выпуск следующих версий сразу же после завершения первой. Это должен быть непрерывный процесс, и единственная причина прекратить его — если выяснится, что продукт приносит плохие результаты.
Если вашей целью было получить 50 загрузок и собрать 20 отзывов в первый месяц, отслеживайте эти результаты в течение всего этого периода и планируйте второй релиз в то же время. Проверяйте результаты, собирайте отзывы пользователей, планируйте следующие версии и повторяйте.
Таким образом, пользователи вашего приложения будут постоянно иметь доступ к новым функциям и смогут следить за развитием продукта. Они с еще большей вероятностью будут рекомендовать его дальше, если их мнение будет учтено и предложенные улучшения будут реализованы.
- Сокращение расходов
Вы можете сэкономить много денег для своего бизнеса, если решите создать первую версию приложения, прежде чем создавать сложное приложение.
Во-первых, если идея окажется неудачной, вы остановите разработку и не потратите больше средств.
Во-вторых, вы сможете начать зарабатывать на приложении раньше, внедрив модель монетизации в первую или любую раннюю версию приложения, а затем использовать эту прибыль для развития продукта.
- Содействие внедрению изменений
Разработчикам приложений гораздо сложнее вносить изменения и исправления в обширный продукт, чем в небольшой. Кроме того, изменения тем менее значимы, чем меньше функций, поэтому, внесенные в такое время, они не будут иметь много шансов навредить вашим бизнес-целям. Даже если вы ошибетесь.
Кроме того, если вам понадобится сменить команду, это также не такая уж большая проблема, когда ваше приложение еще совсем маленькое.
- Больше времени на анализ
Пока вы разрабатываете первую версию своего приложения, вы всегда должны следить за тем, что делают конкуренты. Следите за тем, разрабатываются ли аналогичные решения в то же время, вводят ли конкуренты новые функции и дают ли они положительные результаты.
По мере планирования и создания последующих версий у вас будет время проанализировать рынок и адаптироваться к нему.
Заключение
Первая версия продукта имеет четкие цели, которые необходимо выполнить. Думая об этом таким образом, вы сможете сделать это эффективно.
Если вы планируете разработку приложения, необходимо принять довольно много решений. Вот почему так важно провести глубокое исследование рынка и уделить внимание всем этим важным вопросам.
Прохождение через все вышеперечисленные шаги, безусловно, поможет вам принять правильные решения относительно первой версии вашего приложения, сделать это эффективно и добиться успеха.
Надеюсь, что эта статья поможет вам. Делитесь своим мнением в комментариях и подписывайтесь на мой телеграмм-канал
2 комментария
вряд ли удастся изобрести мобильное приложение, которое будет отличаться от всех остальных
Я может душню, но не нужно недооценивать количество низковисящих плодов
если два способа создать продукт — найти что сейчас популярно и скопировать чуть улучшив, тогда кардинально новых функций изобрести сложно
либо сначала полностью придумать и продумать с нуля вплоть до раннего ТЗ, а потом идти искать конкурентов и смотреть как сделано у них и вполне может оказаться, что так как придумал ты никто из конкурентов не делал
по-моему этот прием называется «чистый лист», так иногда делают, когда создают продукт и берут в команду профи с замыленными взглядами знающими «как надо» абсолютного нуба, что бы он был свежим и с чистым как у младенчика мозгом, желательно только что из МГУ
С отзывами тоже надо осторожнее, скорее всего на 1000 юзеров мы получим отзывов 20-30 из которых 5 будет о какой-то фиче, которая очень нужна, ты будешь долго и упорно ее делать, а потом окажется, что пользуются ей человек 15
Это происходит потому, что отзывы не экстраполируются на всю базу, если у человека горит от отсутствия фичи он идет и пишет отзыв, потому что ему очень надо. А те кому не надо отзывы не пишут, им и так все норм, и большинству как правило реально не надо.
В общем ориентироваться стоит не на отзывы, несмотря даже насколько они гневные, а на метрики. А отзывы только дают подсказки куда можно копать.
Источник: vc.ru
Как писать версию программы
Для начала создадим каталог для тестового репозитория.
mkdir test-ver
Далее заходим в папку.
Инициализируем пустой репозиторий.
git init
Создаём тестовый файл
touch index.html git add index.html git ci -m «Init commit»
Теги в Git есть двух основных типов:
- теги с аннотациями, которые содержат сообщение, имя и почту автора тега, как при коммите;
- легковесные теги — просто указатель на определённый коммит, без всякой допонительной информации.
Для добавления тега с аннотацией — используем -a или –annotate :
git tag -a v1.0 -m «Init version»
Проверяем следующей командой:
git tag
Для добавления легковесного тега — просто пропускаем -a и -m :
git tag v1.0lw
Теги для предыдущих версий
Давайте создадим тег для версии, которая идет перед текущей версией, и назовем его v1-beta . В первую очередь нам надо переключиться на предыдущую версию. Вместо поиска по хэшу, мы будем использовать символ ^ , обозначающий «родитель v1».
Если обозначение v1^ вызывает у вас какие-то проблемы, попробуйте также v1~1 , указывающее на ту же версию. Это обозначение можно определить как «первую версию предшествующую v1».
git checkout v1^ cat hello.html
А теперь сделаем тег:
git tag v1-beta
Переключайтесь по отмеченным версиям.
git checkout v1 git checkout v1-beta
git tag
Вы также можете посмотреть теги в логе
git hist master —all
Источник: codebra.ru
Правила написания Release Notes
Release Notes – это документ, описывающий изменения между выпускаемой и предыдущей версиями программного продукта. Адресатом данного документа в первую очередь являются технические специалисты клиента, которые занимаются обслуживанием продукта, интеграторы и команды внедрения. Поэтому документ в первую очередь должен содержать полезную техническую информацию, а не маркетинговые лозунги.
Состав документа
Сам документ состоит из следующих разделов:
Краткое описание продукта
Несколько предложений или пара абзацев о продукте. Служит для того, чтобы человек, которому в руки попал документ, мог погрузиться в контекст. Иначе без введения на него сразу будет вывален список нового функционала и багов. Не нужно сразу пугать людей.
Что нового
Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.
Исправленные ошибки
Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях.
Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.
Включать в этот список все содержимое баг трекера не нужно:
- Если баг был сделан, найден и исправлен в процессе разработки текущей версии, то пользователь его видеть не мог, а значит и писать о нем смысла нет.
- Если баг был в прошлой версии, но пользователь его с ним не мог столкнуться. Например, проблема была прикрыта заплаткой в стиле «программа падает при вводе имени пользователя длинной более 10 символов, поэтому мы сделали ограничение на ввод в 9 символов».
Удобно указывать ID проблемы, для удобства истории ошибки.
Список известных проблем или known issues
Если у вас нет known issues – значит никто не тестировал продукт.
Приводим список известных проблем (багов). Идеально, если в нем содержатся все актуальные баги для данной версии. Если их слишком много, то выбираем наиболее критичные для пользователя. Для каждого бага нужно указывать:
- ID по которому дальше можно отслеживать его судьбу.
- Workaround. Что делать пользователю, если он встретился с данной проблемой? Если workaround’а нет для критичного бага, значит продукт содержит критическую проблему и не готов к релизу.
Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.
Не стоит забывать и про мотивационную составляющую. Если люди работают в условиях прозрачности, то они склонны делать свою работу более качественно, краснеть никто не любит.
Технические ограничения
Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.
Системные требования
В данном разделе все понятно: минимальные и рекомендуемые требования по железу, поддерживаемые операционные системы, требуемый сторонний софт.
Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.
Особенности обновления с прошлой версии.
Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.
Кто пишет документ
Документ должен писать технический писатель, как обладатель грамотного письма. А вот информацию для документа: системные требования, описания workaround’ов, исправленные баги и т.п., должны готовить технические специалисты, руководитель разработки, product manager. Если повесить все на человека, у которого основной навык знание языка, то получиться плохо.
Источник: pmlife.ru