Как разработать приложение, которое будет приносить деньги

Мы не раз писали о приложениях полезных или просто развлекательных. На крупнейших маркетплейсах — AppStore и GooglePlay — их сотни тысяч, как и компаний, небольших команд и инди-разработчиков, их разрабатывающих. И более 95% приложений созданы с одной целью — заработать деньги тем или иным способом.

Цель, безусловно, хорошая — ты наверняка и сам думал о том, чтобы сделать приложение, которое тебя обогатит. Но как это сделать? От чего зависит успех приложения? Как происходит процесс разработки? Почему Flappy Bird и Pokemon Go возымели необычайный успех, а действительно полезные приложения остаются в тени? Мы не знаем всех ответов, но попробуем помочь тебе, несмотря на нашу «гуманитарность». Пока оставим в стороне вопрос разработки, ведь ты можешь сделать это сам либо заказать ее.

Идея

Очевидный и банальный пункт, но с этого всё начинается. Есть два варианта — сгенерировать идею из «ничего» или слямзить. В первом случае можем посоветовать такой подход: приучи себя замечать несовершенства этого мира лично для себя и для других людей. Замечай то, что тебе не нравится, и думай, как решить эту проблему (это применимо вообще к любым сферам, не только приложениям). К примеру: было бы круто слушать музыку с YouTube на смартфоне, не открывая официальное приложение (оно останавливает видео при сворачивании). Или: хочу знать, где мои близкие в данный момент (ну, это можно узнать через сервисы Google, но не суть). Или, например, общественный транспорт (тут, конечно, потребуются физическая реализация и участие самих водителей). Думаем, суть ты уловил.

Для второго варианта всё тоже достаточно очевидно — нужно взять готовую идею и улучшить ее. Например, вся редакция находит Wunderlist просто ужасным, DropBox — неудобным, и в таком духе. Всегда можно улучшить что-то имеющееся. Или, к примеру, дополнить функционал имеющихся решений (например, создать приложение для чтения известного сайта). Короче, исследуй текущий рынок.

Виды приложений и монетизации

Приложения могут быть для компьютеров, мобильными и web-приложениями. Могут быть кроссбраузерными и кроссплатформенными. Могут быть гибридными. Сейчас, конечно же, котируются приложения, которые можно запустить везде. Web-приложения можно, в принципе, запустить на чем угодно, ибо нужен лишь браузер, но они ограничены функциональностью платформы и работают медленнее. Тут тебе нужно подумать, кто твой целевой юзер, так как много приложений для разных платформ — это много материальных и временных затрат.

Категории обозначать долго, зайди в Google Play и посмотри — их там штук 50. А вот схемы монетизации есть такие:

• Платное приложение. Продажа приложения в магазине.
• Бесплатное приложение с платной подпиской.
• Бесплатное приложение со встроенными покупками.
• Бесплатное с рекламой внутри.
• Пожертвования.
• Продажа данных пользователей.
• Продажа своего приложения.
• Привлечение спонсоров и инвестиций.
• Гибридные схемы.

Техническое задание

Техническое задание — описание того, что мы, собственно, хотим видеть в конечном продукте — вещь архиважная. Его сложно составить и без него нельзя. Оно пригодится независимо от того, будешь ли ты сам разрабатывать приложение или купишь разработку. В первом случае это просто поможет тебе не потеряться, не забыть ничего — своеобразный «to do list». По мере развития твоего проекта ТЗ может поменяться сотни раз, но суть именно в наглядности. Можно использовать, кстати, и сервисы для визуального построения схем — с картинками, пометками и прочим (Descle, RealtimeBoard — в них поддерживается и командная работа).

Еще одна причина. Если ты решишь заказать разработку, то ТЗ не только ускорит ее, но и позволит продуктивно вести диалог с разрабами, если что-то не будет соответствовать твоим желаниям. Плюс ко всему, разработчики ненавидят, когда нет четкого ТЗ. Многие их клиенты — это люди, которые говорят: «Ну, просто сделайте круто». Что такое «круто», естественно, никто не въезжает, что и приводит к проблемам на этапе сдачи проекта заказчику. Но мы так и не сказали, как составить ТЗ. Хороший подход к составлению — писать так, как будто это документ, который будет защищать тебя на суде. Обозначим основные пункты:

• 1. Ясное и понятное описание проекта в одном предложении.
• 2. Общее раскрытое описание, для кого/чего/зачем.
• 3. Платформы, на которых приложение будет работать (iOs, Android, Web, Windows).
• 4. Привести примеры, если есть.
• 5. Обозначить основные определения (хотя бы так, как ты их понимаешь).
• 6. Обозначить основные требования и ограничения к проекту.
• 7. Описать основные модули приложения — экраны, кнопки, элементы интерфейса и их функции/поведение (расскажем далее).
• 8. Если сможешь, нарисовать макеты, как ты себе это представляешь (есть бесплатные сервисы: iPlotz, MockFlow, Mockup Builder, Cacoo).
• 9. Сроки, стоимость, гарантии, требования к дальнейшей поддержке.

Уже сложно. А ты как думал? Но многие студии могут сделать половину всего сами, предложить несколько вариантов и согласовывать с тобой до тех пор, пока вы не придете к соглашению. Также можно заказать разработку ТЗ. Еще неплохо использовать для составления таких вещей «ментальные карты» — пример ТЗ в этом стиле здесь.

Дизайн

Дизайн сейчас — это UI (User Interface) и UX (User Experience). Если дизайн визуальный — вполне понятная вещь, хоть и сложная, то UX — не очень. Суть в том, что пользователь взаимодействует с твоим детищем, и это взаимодействие должно быть максимально простым, удобным и очевидным. Тема сложная и многогранная. Здесь самое сложное — поставить себя на место юзера.

Желательно, чтобы эти штуки также были отражены в ТЗ. Опять-таки можно заказать разработку, а можно попробовать набросать макеты самому. Дизайн может быть универсальным, в стиле Materal Design, например, или специфичным. Для каждого случая нужно подобрать идеальный. Иногда универсальный — лучше всего, так как люди к нему уже привыкли и не путаются. Иногда, например, для игр, нужен дизайн в определенной стилистике. Как правило, студии сами всё это разрабатывают и согласовывают с тобой. Но здесь важно и твое «видение», которое может определить успех приложения. Так что стоит сохранять баланс между своими безумными идеями и рекомендациями специалистов.

Продвижение

Многие приложения взлетают просто так. Отличный пример — Flappy Bird. Оверзадротность и сложность игры определила ее успех. Другие просто настолько хороши, что люди (и сами маркетплейсы!) их советуют по собственной инициативе. Но в большинство приложений, известных тебе, были вбуханы просто огромнейшие деньжища. В Pokemon GO около 7 000 000 $, если не ошибаемся, и это чисто в продвижение. Это как с фильмами, с пиаром, рекламой и евентами по всему миру. С специализированными и уникальными приложениями, конечно, проще. Плюс можно самому проявлять активность, рекламируясь на форумах и других площадках вроде 4PDA. Но цель всё равно одна — попасть в топы Google Play и App Store. Придется взаимодействовать с подписчиками, исправлять баги, обращаться к рекламным агентствам и сервисам для продвижения, но это нормально — без агрессивной рекламы практически невозможно выжить. Бюджет на это выделить лучше заранее — если все-таки повезет не использовать услуги подобного рода, то сможешь вложить их в само приложение.

Тестирование

Тестировать придется всё. Абсолютно всё, что мы описывали, можно тестировать, и это, возможно, один из главных пунктов. Интерфейс, функции, описания приложения, схемы монетизации, да даже цвет кнопок — всё может влиять на успех. И этот цикл тестирования — он бесконечный. Гугли «A/B тестирование» и изучай тему.

Самый быстрый и простой путь

Это, безусловно, аутсорсинг — покупка разработки. И у тебя, по сути, нет других вариантов, если ты не программист. Да, такой способ стоит денег, но за всё в этой жизни приходится платить. Очевидный плюс — приложение будут делать профессионалы, которые знают в сотни раз больше, чем мы перечислили в статье. И мы знаем таких ребят.

Если коротко, они — это гарантия того, что у тебя будет то самое «крутое приложение», даже если твоя идея не из лучших. А вероятность того, что твой проект окупит себя, станет намного выше, чем при самостоятельной разработке.