Що Потрібно Знати, Починаючи Розробку Власного Мобільного Додатку?

Зміст

#1. Етапи процесу розробки
#2. Бізнес-модель і монетизація
#3. Склад команди розробників
#4. Архітектура та технологічний стек
#5. Вартість створення додатку

Щоденно в Apple Store і Google Play з'являються тисячі нових додатків, але лише декілька з них стають фінансово успішними. Усі інші зникають: 80% - у перший рік, решта - протягом наступних п'яти років. Головною причиною іх невдач є небажання розбиратися в нюансах мобільної розробки, що призводить до багатьох необов'язкових помилок. В цій статті ми розкажемо про 7 ключових речей, які має знати кожен, хто хоче розробити свій додаток.

Етапи процесу розробки

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

Стратегія і бачення. Перший крок при запуску будь-якого стартапу - зрозуміти, про що саме буде ваш проект. Ви маєте визначитися з тим, що ви хочете, щоб ваш додаток робив? Яких цілей ви хочете досягти і яким чином? Давши відповіді на ці запитання, ви зможете створити бачення свого проекту: завдання, функції, ніша, цільова аудиторія, монетизація, унікальна ціннісна пропозиція тощо.

Після того як ви сформуєте базову концепцію майбутнього мобільного додатку, можна звертатися до вашої внутрішньої команди розробників або постачальника технічних послуг на аутсорсингу. Разом із розробниками ви зможете чіткіше визначити завдання проекту та шляхи їх досягнення. Розподіл зон відповідальності під час розроблення стратегії має такий вигляд:

• замовник визначає, НАВІЩО робимо;
• розробник вирішує, ЩО і ЯК робимо.

Аналіз і планування. Після того як завдання поставлено та визначено основні функції пропозиції, настає час для аналізу та планування. Зазвичай на цьому етапі підключають бізнес-аналітика, який створює технічну специфікацію, що ґрунтується на бізнес-завданнях, передових методах розробки додатків, аналізі конкурентів і ринку, а також на власному досвіді.

У результаті ви отримаєте технічне завдання проекту і детальний план розробки, який містить опис бізнес-потреб, функціоналу, технологічного стека і API, вимог до дизайну і макети, які допоможуть вам і розробникам говорити однією мовою. Далі обговорюються терміни, канали комунікації та KPI. Коли всі ці речі узгоджені, складається договір.

Створення UI/UX дизайну. На цьому етапі дизайнер створює концепцію UI/UX-дизайну для вашого додатку на основі каркасів, які можуть бути написані бізнес-аналітиком або дизайнером UX. Далі на основі каркасів створюють макети і прототипи призначеного для користувача інтерфейсу додатку.

На все це може піти до 20% від усього процесу створення додатку, залежно від його складності та глибини опрацювання. Зрозуміло, що складнішим буде дизайн, то більше часу і грошей піде на його реалізацію. Але це не означає, що на дизайні потрібно економити. Зовсім навпаки: дизайн - це один із найважливіших елементів успіху будь-якого IT-стартапу, оскільки саме він найбільше впливає на перше враження та користувацький досвід.

Написання програмного коду. На цьому етапі команді розробників надають концепцію дизайну, макети і технічну специфікацію. Вони вивчають цю інформацію і приступають до написання програмного коду програми. Цей процес у більшості компаній зазвичай досить гнучкий, що означає, що весь він ділиться на спринти, і кожен наступний спринт може бути змінений залежно від того, що було досягнуто під час попереднього.

Швидкість і вартість розробки залежать від кількості задіяних фахівців, їх досвіду та навичок, а також технологічного стека. Зверніть увагу, що розробникам потрібен буде якийсь час на початковому етапі, щоб налаштувати середовище розроблення, базу даних, серверну частину та архітектуру. Якщо розробка розділена на окремі блоки, то також знадобиться час на об'єднання всіх елементів у єдину структуру та її тестування.

QA і тестування продукту. У сучасному циклі розробки перевірка коду часто відбувається майже одночасно з його написанням: поки розробники пишуть код, QA-фахівці паралельно проводять різні автоматичні тести та вручну перевіряють код. Такий підхід допомагає прискорити процес тестування та виправлення помилок: легше знаходити невідповідності в невеликих фрагментах свіжого коду, ніж вносити зміни до великого коду наприкінці розробки.

Сам процес тестування коду зазвичай включає такі речі:

• Димове тестування. Набір базових тестів, що має на увазі ретельну перевірку на явні помилки в найбільш важливих і критичних елементах з урахуванням того, що це не до кінця доопрацьований продукт.
• Повторне тестування. Це повторне виконання раніше невдалого тесту з новим (виправленим) кодом, щоб перевірити, чи вирішено проблему.
• Регресійні тести. Підбірка тестів, спрямованих на усунення регресійних помилок, які з'являються при внесенні змін до наявного білду або при виправленні інших багів, що стає причиною виникнення нових помилок у вже протестованому продукті.
• Тести продуктивності. Повномасштабні тести на "витривалість" застосунку під час найрізноманітніших навантажень, включно з перезавантаженням, перемиканням між офлайн- і онлайн-модами та іншими внутрішніми операціями.

Після виконання кожного тесту й отримання відгуків QA-інженер вносить поліпшення в код, що займає більшу частину часу фази тестування.

Розгортання продукту. Після того як застосунок готовий і всі тести підтвердили якість коду створеного програмного забезпечення, мобільні застосунки випускають на Google Play і App Store. Перед додаванням нового застосунку у свої лістинги ці маркетплейси перевіряють його на відповідність правилам майданчика і мінімальній якості. Якщо в коді виявлять помилки, у вас буде дуже мало часу на їх виправлення (2 дні в App Store). Тому ми настійно не рекомендуємо економити час і бюджет на тестуванні.

Технічне обслуговування. Обслуговування мобільного застосунку зазвичай означає його поліпшення для сумісності з новими версіями операційних систем, пристроїв і платформ. Крім того, це також передбачає поліпшення дизайну з функціоналом і підключення різних сторонніх сервісів. Завдяки всьому цьому ваш додаток залишатиметься актуальним протягом багатьох років, а не тільки в перший час одразу після запуску.

Бізнес-модель і монетизація

Бізнес-модель - це те, як функціонує компанія: що вона робить, заради чого, як отримує прибуток зі своєї діяльності, як взаємодіє з клієнтами та партнерами, у що інвестує тощо. У разі мобільного додатку його бізнес-модель може бути спрямована на виконання найрізноманітніших завдань. Найбільш очевидна - отримання доходу безпосередньо із додатку. Інший популярний варіант - служити "магнітом" для залучення цільової аудиторії, побічно збільшуючи охоплення бренду або допомагаючи продавати товари в іншому місці.

Якщо ви оберете перший варіант, ось як це можна зробити:

• Freemium-модель. Такі додатки можна завантажити безкоштовно і використовувати без будь-якої оплати, але не на всі 100 %. Деякі функції та/або контент будуть заблоковані. Отримати доступ до заблокованих речей можна буде тільки через покупку або оформивши підписку.
• Платні (преміум) застосунки. Для використання таких додатків їх потрібно купити в магазині, як звичайний товар у супермаркеті. Цей підхід створює ціновий бар'єр для входу, тому під час запуску такого додатку потрібно розробити маркетингову стратегію, яка продемонструє перевагу вашого софту порівняно з безкоштовними конкурентами.
• Покупки всередині додатку. У цій моделі ваш мобільний додаток слугуватиме каналом для продажу цифрових або фізичних продуктів, наприклад, брендованого мерчу або ексклюзивного контенту.
• Реклама в додатках. Це, мабуть, найпростіша і найдоступніша модель монетизації з усіх, тому що користувачі зможуть використовувати ваш додаток абсолютно безплатно, що прибирає будь-які бар'єри для входу. Але будьте обережні з кількістю реклами, оскільки занадто велика кількість банерів і рекламних вставок може відлякати людей.
• Модель із підпискою. За такого підходу доступ до додатку користувачі отримують після оформлення місячної, піврічної або річної підписки.
• Спонсорство. Цей варіант передбачає, що додаток буде безкоштовним, а гроші на його підтримку ви отримуватимете шляхом добровільних пожертвувань користувачів.

Склад команди розробників

Мобільний додаток - це досить складне програмне забезпечення, яке поки що не можна створювати подібно до того, як запускають сайти за допомогою WordPress. Для цього потрібні внутрішня команда розробників або технічний партнер на аутсорсингу. Команда в штаті - хороший варіант, якщо в них буде робота на постійній основі, що буває досить рідко. Тому в більшості випадків створення додатків доручають компанії-розробнику на аутсорсингу.

Як знайти такого партнера і на що звертати увагу під час його вибору, ми описали в статті: "Як вибрати компанію-розробника".

Що стосується складу команди розробників мобільних додатків, то він у більшості випадків буде таким:

• Бізнес-аналітик. Збирає завдання і вимоги клієнта до бажаного продукту, аналізує те, який вигляд софт має мати, і які функції потрібно включити в розробку, щоб на основі цієї інформації створити технічну специфікацію і розпланувати весь процес із бюджетом.
• Менеджер проекту. Розподіляє завдання між командою розробників, планує хід роботи, мотивує, контролює процес і координує загальні дії. Також несе відповідальність за управління ризиками, тайм-менеджмент і дії в разі непередбачених ситуацій.
• UI/UX дизайнери. Використовують каркаси, створені клієнтом і/або бізнес-аналітиком, щоб на їхній основі "намалювати" макети інтерфейсу (UI). Також дизайнери відповідають за створення відмінного досвіду користувача у кінцевих користувачів вашого мобільного додатку.
• Розробники/програмісти. Відповідають за втілення дизайну і функціоналу додатку в програмному коді, який зрозумілий пристрою користувача, серверам і різним стороннім сервісам. Програмісти можуть спеціалізуватися на фронтенд-, бекенд- і мобільній розробці.
• QA-фахівці. Тестують застосунок на наявність багів у коді та інших помилок із подальшим наданням звіту команді розробки, яка має виправити їх. Іноді QA-інженери самі виправляють помилки.

Архітектура та технологічний стек

Архітектура. Мобільний додаток - це складний програмний продукт, який складається з безлічі різних компонентів, таких як екран входу в систему, призначений для користувача інтерфейс, бази даних, онлайн-магазин тощо. Для управління цими компонентами програмісти створюють архітектуру додатка, щоб логічно визначити стосунки і спосіб взаємодії між усіма цими компонентами. Ось приклад такої архітектури:

Зазвичай така архітектура передбачає поділ усіх компонентів додатку на клієнтську (front-end) і серверну (back-end) частини, які пов'язані між собою і з різними сторонніми сервісами через API (Application Programming Interface). Набір компонентів для серверної та клієнтської частин, а також API залежить від типу конкретного додатку, його функціоналу та завдань.

Front-end. Включає в себе компоненти, з якими взаємодіє кінцевий користувач, наприклад покупець у магазині. Це призначений для користувача інтерфейс (те, що бачить кінцевий користувач на своєму екрані) та інтерфейс системи. Для створення клієнтської частини потрібні спеціальні інструменти (технічний стек для фронтенду). Ось приклад такого стека для розробки мобільного сервісу управління електронними медичними картами (EMR):

Back-end. Програмно-апаратна частина системи, яка відповідає за роботу з інформацією та здійснення функціонування внутрішньої частини додатку. Ось як виглядає технологічний стек для розробки EMR-додатку:

• Веб-сервери: nginx, Apache.
• Веб-фреймворки: Ruby On Rails, Phoenix.
• Мовапрограмування: Ruby, Elixir, Python, PHP, Java.
• Серверибазданих: PostgreSQL, MySQL.
• Хостинг: AWS, Google Cloud Platform, Microsoft Azure.

API (Application Programming Interface). Набір спеціальних протоколів для з'єднання клієнтської та серверної частин системи, а також інтеграції різних сторонніх сервісів, що розширюють функціональні можливості додатку. Ось приклад набору API для розробки власного EMR-додатку:

Вартість створення додатку

Згідно з Clutch, компанії в середньому витрачають на створення власних мобільних продуктів від 13 до 142 тисяч доларів. Настільки великий розкид пояснюється здебільшого двома факторами: складністю софту і місцем розташування розробника. Під складністю мобільного додатку зазвичай мають на увазі кількість функцій і складність їх реалізації. Крім того, на складність розробки також впливають дизайн інтерфейсу та кількість потрібних інтеграцій.

Що стосується місця розташування, то цей фактор важливий, оскільки середня зарплата мобільних розробників у різних регіонах може відрізнятися у два-три рази. Так, програмісти зі Сполучених Штатів Америки в середньому отримують 95 дол/год, Великої Британії та Західної Європи - 67 дол/год, Східної Європи - 32 дол/год, Африки та Азії - до 25 дол/год.

Ось орієнтовна вартість розроблення свого мобільного додатку залежно від його складності та місця розташування технічного партнера: