Сколько времени нужно, чтобы превратить идею в полноценный продукт? Что мне делать, чтобы мое приложение появилось на рынке? С кем связаться? Что делать?

В этом сообщении блога я постараюсь описать путь превращения вашей идеи в продукт.

В этой статье я подумаю о создании мобильного приложения, но я думаю, что это полностью применимо к другим «ИТ» продуктам, таким как Интернет, настольный компьютер и т. Д.

Для начала предположим, что у вас есть блестящая идея. Вы принимали душ, и вас осенило. Вы влюбились в идею. Вы хотите это сделать.

Давайте начнем!

Проведите исследование

Должен сказать, мне очень сложно придумать что-то, чего раньше не изобретали. Даже если я думаю, что моя идея уникальна, оказывается, что на рынке много похожих продуктов. Это неплохая вещь. Попробуйте их использовать. Не торопитесь и играйте с ними.

Они точно такие же, как ваша идея? Хотели бы вы их использовать? Если нет, что бы вы изменили? Посмотрите, как приложения повлияли на рынок? Они популярны? Многие ли ими пользуются? Будут ли люди использовать ваше приложение?

Один из моих друзей, просматривая эту статью, сказал:

Всегда полезно найти группу людей, которые могли бы заинтересоваться вашим продуктом или которые занимаются тем же бизнесом, что и вы. Отправьте им электронные письма. Задайте им вопросы о проблеме, которую вы хотите решить с помощью своего продукта. Не предлагайте ответа. Может, они подскажут, что делать

Задайте себе много вопросов. Делать записи. Напишите «за» и «против» и решите, хотите ли вы продолжить или нет. Может быть трудно отказаться от своей идеи, но поверьте мне - все же лучше отказаться здесь, чем тратить много долларов и сдаваться позже.

Подумайте о монетизации и стоимости вашего приложения

Да, я знаю: у вас просто возникла идея и вы хотели создать одно приложение, но поверьте мне: это все равно будет выглядеть непросто. Сейчас это идея, но мы хотим, чтобы она превратилась в полностью пригодный для использования продукт. Никто (даже самые богатые люди) не хочет создавать продукт, который теряет свои деньги. Вам нужно подумать, хотите вы зарабатывать на этом деньги или нет. Если да, то как вы хотите, чтобы это произошло? Здесь есть много вариантов. Вы можете включать рекламу, вы можете вводить премиум-пользователей, вы можете сделать приложение платным. Только ты знаешь, что делать. Конечно, процесс разработки стоит денег. Каждый месяц или целый год с вас, вероятно, будет взиматься плата. Думаю об этом. Даже если вы не хотите поддерживать свое приложение после выпуска (что я не рекомендую), все равно придется платить за серверы. Можете ли вы заплатить за них бесплатно? Вы готовы это сделать? Помните, что это все еще идея.

Найдите свой народ

Это довольно сложный момент. К настоящему времени вы определили идею, вы знаете, чего хотите, и у вас есть (более или менее) бизнес-план. Пришло время действовать. Пришло время найти команду, которой можно доверять. И здесь все усложняется.

Опять же, тот же друг, который рецензировал эту статью, сказал, что хорошо найти соучредителя. Он добавил, что хорошо, если у него другие способности, чем у тебя. Если вы технический специалист, найдите кого-нибудь с лучшими коммуникативными навыками. Если вы маркетолог, найдите технического специалиста и т. Д. У вас не получится запустить это самостоятельно. Найдите кого-нибудь, кто сможет вам помочь!

А теперь давайте найдем команду разработчиков, которая создаст для вас продукт. Как это сделать? На мой взгляд, просто говорите и задавайте вопросы.

Почему я считаю, что нужно делать упор на поиски команды? Потому что здесь возникает конфликт интересов. Вы хотите, чтобы ваш продукт появился вживую. Компания вашей команды хочет зарабатывать деньги. В ИТ: время = деньги.

Вам нужно найти действительно профессиональную компанию. Компания, которая понимает, что в первую очередь обслуживает клиента. Возможно, вам нужно будет поговорить, поговорить и поговорить. Поговорите с владельцами компании (или ответственными лицами); поговорите с менеджером, который должен позаботиться о вашем проекте; просто говори. Я знаю, что это может быть сложно, потому что иногда нам приходится выбирать компанию на тендере.

Если у вас есть возможность выбрать компанию, выберите компанию, в которой вы хотите работать.

Представьте продукт своей команде

Нет ничего хуже, чем команда разработчиков, которые не разбираются в продукте. Вы должны объяснить, почему вы хотите создать приложение, почему пользователи хотели бы использовать приложение, какова ваша цель и т. Д. Чем больше вы говорите об этом, тем лучше для продукта. Ваша команда должна полностью понимать суть проблемы. Поделитесь своей идеей, что нужно сделать, как вы хотите, чтобы это было сделано и т. Д.

Пусть команда предложит

Создать приложение не так-то просто. Допустим, вы хотите иметь мобильное приложение. Вы знаете, сколько различных фреймворков / технологий можно использовать для создания приложения? Есть по крайней мере 8 популярных, о которых я могу подумать (а я думал около 5 секунд). У каждого есть свои плюсы и минусы. Выбор подходящего варианта зависит только от вас. Компания должна открыть глаза и выделить плюсы и минусы. Будьте осторожны здесь. У каждой компании ограниченный набор технологий - они могут захотеть продать вам что-то не самое подходящее.
Но выбор технологий - не единственное, о чем следует думать. Спросите, какую структуру они хотят использовать для управления проектом. Будет ли это водопад? Канбан? Скрам? Опять же, спросите, каковы недостатки и достоинства каждого из них.
Опять же: читайте и говорите. Говорите и читайте.

Мозговой штурм

В одном из проектов, в котором я участвовал, у клиента возникла идея. Он пришел к нам, чтобы создать для него приложение. Он поделился с нами идеей. Мы думали, что это неплохо, но клиент не знал, как именно этого добиться. Итак, мы предложили мастерскую. Это было что-то среднее между Brainstorm и EventStorming. Мы провели целый день. Под нами я имею в виду нашего менеджера по маркетингу, нашего UI / UX-дизайнера, backend-разработчика и мобильного разработчика. У нас были тонны бумаги, стикеры, маркеры и скотч. Мы залили бумагой всю стену нашей переговорной. Мы создали весь поток приложения. Во время этого мероприятия у нас возникли вопросы; у клиента возникли вопросы. В потоке были пробелы. Мы обнаружили крайние случаи. Мы уточнили несколько вещей. Но знаете что? Во время той встречи нам удалось все исправить. В принципе, после одной встречи мы знали, что нам делать. Каждый из нас знал свой домен.
Как я уже писал выше: я считаю этот момент очень важным, чтобы разработчики знали продукт. Если они этого не сделают, им придется подозревать, как это должно работать - это может привести к проблемам и даже провалу проекта.
Кроме того, мозговой штурм может помочь позже в создании задач / пользовательских историй. Вы знаете, чего хотите, зачем вам это нужно и как это должно работать. Ты знаешь все.

Действительно стоит иметь что-то подобное. Даже если вы не видите потенциальной прибыли сейчас, вы увидите ее позже. Кодирование станет намного проще, а управление станет более плавным.

Развивать

Этот шаг может быть самым длинным. Во-первых, поговорите с дизайнером. К настоящему времени он должен знать, как должно работать приложение и что нужно включить. Но он не знает, какие у вас цветовые предпочтения. Может быть, у вас уже есть представление об ощущениях от приложения? Тяжелый, темный или красочный, веселый, дружелюбный? По какому пути должен идти дизайнер? Поговори и расскажи ему. Я хотел бы добавить, что на этом этапе дизайнер (перед отправкой предложения клиенту) должен отправить его разработчикам. Некоторые вещи может быть сложно реализовать (или не стоит того), в то время как другие могут быть предоставлены почти сразу же.
В то же время разработчики могут работать над созданием проекта. Перед реализацией реальных функций необходимо проделать определенную работу. Нам, разработчикам, необходимо создать репозиторий, настроить серверы, настроить CI / CD, создать скелет проекта и т. Д. Конечно, это требует времени. Имея готовый хотя бы один дизайн, разработчики могут приступить к работе над функциями.

В зависимости от того, с чем вы согласились, они должны часто показывать вам результаты своей работы. Если они этого не показывают, знайте, что что-то может пойти не так. Вы на правильном пути? Достижим ли срок? Как узнать, не видишь ли ты результатов их работы?

Если вы думаете, что сможете увидеть результат в конце разработки проекта - позвольте мне сказать вам одно: не делайте этого. Допустим, вы работаете в SCRUM. У вас есть двухнедельные спринты. Это означает, что вы будете видеть результат их работы каждые 2 недели. Вы можете протестировать его самостоятельно после получения новой версии. Если вы обнаружите ошибку, вы можете сообщить им раньше, чтобы у них было время исправить ее. Если вам не нравится, как это работает, вы можете сказать. Если вы хотите изменить требования, вы можете сделать это, когда увидите это.
С другой стороны, допустим, вы получаете версию после всего процесса разработки. Наверняка у вас будет куча комментариев о приложении, вы заметите несколько проблем. Но можете ли вы изменить требования сейчас, когда получите последнюю версию? Конечно, можно, но за это придется заплатить. Не то чтобы хорошо. Помните, что время = деньги. Чем раньше вы что-то заметите, тем лучше для вас.

Тестовое задание

Допустим, у вас есть версия, которую вы хотите опубликовать. Ты уверен, что сможешь это сделать? Вы как следует его протестировали?

Конечно, компания, которая разрабатывала приложение, протестировала его, но первоначальная идея принадлежит вам. Вы знаете, как это должно работать и чего ожидать. Попробуй это. Не торопитесь и позаботьтесь о своем «ребенке». Убедитесь, что все работает как надо. Если вы уверены, что все в порядке, попробуйте и запланируйте выпуск.

Выпустить MVP, собрать отзывы и добавить новые функции

Это очень важный вопрос. Честно говоря, я забыл об этом. Бартек, читая эту статью, напомнил мне об этом и сказал, что это очень важно. Но о чем все это?

По сути, суть в следующем: не создавайте сразу всю систему. Внедряйте только необходимые функции - создайте продукт MVP (минимально жизнеспособный продукт) и как можно скорее представьте его людям. Почему? Потому что вы увидите, действительно ли это им нужно или нет. Если нет, то прекратите это, так как нет смысла вкладывать в него больше денег. Если да, соберите отзывы. Дайте им контактную форму или адрес электронной почты, который они могут использовать, чтобы они могли отправлять вам то, что им нравится, что они хотели бы видеть и что не работает. Это действительно важно. Иначе как узнать, что пользователи хотели бы видеть?

Если вы видите, что большинство ваших пользователей хотели бы, например. чтобы войти в систему с учетной записью Google, вам действительно стоит подумать об этом. Если вы сочтете это полезным, сделайте ему более высокий приоритет. Попросите свою команду реализовать его. Отпустите это. Сделайте своих пользователей счастливыми!

Маркетинг

Прямо сейчас, когда вы запланировали релиз, подумайте о маркетинге. Как вы хотите рекламировать приложение? Вам нужно заставить людей использовать это. Думаю об этом. Пора это сделать.

Служба поддержки

Похоже, что после выпуска вашего приложения больше нечего делать. Не правда. Вы или кто-то другой должны заботиться о нем. Собираетесь ли вы оставить ребенка одного?

Есть несколько вещей, которые могут перестать работать: ваш сервер не работает, ваше приложение заблокировано, вы обнаружите ошибку.

В каждом сценарии ваши пользователи будут расстроены. Они не могут использовать приложение. Конечно, получив кучу писем от пользователей, вы свяжетесь со своей командой и спросите: «Какого черта мое приложение не работает?». И они вам ответят: «Мы не следим за этим. Вы не просили нас об этом ».

Говоря о поддержке, у вас есть три варианта:

  • подумайте о подписании контракта на поддержку
  • следи за приложением самостоятельно
  • не заботятся о ваших пользователях.

Конечно, вы не хотите идти по третьему пути. Что я могу предложить, так это подписать контракт на поддержку. Поговорите со своей командой, сколько времени, по их мнению, уйдет на исправление ошибок в месяц. Если нечего исправить, вы можете попросить их внедрить новую функцию.

Если вы решили пойти по второму пути и самостоятельно присматривать за продуктом. Если с приложением что-то не так, вам, вероятно, все равно придется связаться со своей командой. Или вам не придется этого делать, если вы знаете, как это исправить. Но я вижу, что большинство клиентов, с которыми я работаю, не являются техническими специалистами. Каждая ошибка все еще будет проходить через мои руки.

Я не отвечу на вопрос, по какому пути идти: все дело в деньгах. Посмотрите, что подходит вашему бизнес-плану, и выберите его.

Еще кое-что нужно добавить. Поддержка - это не только исправление ошибок. Речь также идет об оптимизации производительности, обновлении сторонних библиотек, исправлении ошибок и удалении неприятных вещей, которые нам приходилось делать из-за крайнего срока.

Действовать!

Думаю, я описал весь процесс разработки. Эти 10 пунктов - лишь краткое описание того, что может случиться с вашей идеей, если вы решите превратить ее в продукт. Вы можете подготовиться, вы можете прочитать статьи о том, как это выглядит, но жизнь есть жизнь - это вас удивит, даже если вы полностью подготовлены. Так что не сомневайтесь, получайте деньги и действуйте!

Эти прекрасные изображения были нарисованы мной и моей девушкой. Изображение из шапки взято с сайта Pixabay.

✉️ Подпишитесь на рассылку еженедельно Email Blast 🐦 Подпишитесь на CodeBurst на Twitter , просмотрите 🗺️ План развития веб-разработчиков на 2018 год и 🕸️ Изучите веб-разработку с полным стеком .