«Бізге мобильді қосымша керек» - әзірлеушілерге ең жиі айтылатын сөйлемдердің бірі. Алайда осы сөйлемнің артында әрқашан әртүрлі жағдай жатады: біреудің нақты жұмыс істейтін бизнесі бар да, клиенттерге қолайлылық жасағысы келеді; біреуде тек идея бар; үшіншісі бәсекелестерінің қосымшасы бар екенін көріп, «біз де болуымыз керек» деп шешкен. Бастапқы нүкте қандай болса да, қосымшаның сәттілігі код жазылғаннан кейін емес, әлдеқайда ертерек - қандай мәселені шешетінін түсінген сәтте анықталады.
Бұл мақалада мобильді қосымшаның идеядан бастап дүкендерге шығарылғанға дейінгі және одан кейінгі өмірін кезең-кезеңімен қарастырамыз: әр қадамда не болады, бизнес тарапынан не талап етіледі және қайсы жерде ақша мен уақыт көбіне босқа кетеді.
Қосымша әзірлеу неден басталады
Көптеген жобалар дизайнер мен бағдарламашыдан басталады, бірақ шын мәнінде олар бір сұрақтан басталуы тиіс: бұл қосымша кімге және қандай мәселені шешу үшін керек? Егер жауап «барлығына және бәрін» болса, жоба бастапқыда-ақ қауіпті жолда тұр, өйткені мұндай қосымшаның мүмкіндіктер тізімі шексіз өседі, ал бюджет пен мерзім олармен бірге өседі, бірақ пайдаланушыға нақты құндылық бермейді.
Бизнес үшін практикалық тәсіл - қосымшаны сайтпен салыстыру. Егер клиент мәселесін браузердегі қарапайым сайт шеше алатын болса, мобильді қосымша тек қосымша шығын болады. Ал егер пайдаланушы күнде оралатын болса, push-хабарламалар, офлайн жұмыс немесе телефон камерасы мен геолокациясына терең қолжетімділік қажет болса, қосымшаның пайдасы анық. Бұл таңдау туралы біз «Сайт па, мобильді қосымша ма» мақаласында толығырақ жаздық.
Идеяны және аудиторияны тексеру
Код жазудан бұрын идеяны арзан жолмен тексеру ең пайдалы қадам болып қалады. Мақсатты аудиториямен бірнеше әңгіме жүргізу, бәсекелестердің қосымшаларын қолданып көру, олардың пайдаланушы пікірлерін оқу - мұның бәрі әзірлеушісіз де жасалады және жобаның ең үлкен тәуекелдерін ерте көрсетеді. Бәсекелестердің дүкендегі пікірлеріндегі қайталанатын шағымдар көбіне сіздің қосымшаңыздың қайсы жерде ұтып шығуы мүмкін екенін дәл көрсетеді.
Осы кезеңнің нәтижесі - қысқа және нақты анықтама: қосымша кімге арналған, қандай негізгі мәселені шешеді және пайдаланушы алғашқы минуттарда қандай әрекетті орындауы тиіс. Егер бұл үш сұраққа бір-екі сөйлеммен жауап беру қиын болса, әзірлеуге кірісуге әлі ерте.
Талдау және техникалық тапсырма
Идея расталған соң, оны әзірлеушілер түсінетін тілге аудару керек. Бұл кезеңде бизнес-талдаушы немесе жоба менеджері қосымшаның экрандарын, пайдаланушы рөлдерін, негізгі сценарийлерін және сыртқы жүйелермен байланыстарын (төлем жүйесі, CRM, хабарлама сервистері) сипаттайды. Нәтиже - техникалық тапсырма (ТЗ), ол әзірлеуші мен тапсырыс беруші арасындағы келісімнің негізі болады.
Жақсы ТЗ барлық мүмкіндікті бірден қамтуға тырыспайды. Керісінше, ол бірінші нұсқаға (MVP) кіретін мүмкіндіктерді нақты бөліп, қалғанын кейінгі кезеңдерге қалдырады. Бұл тәсіл аз бюджетпен нарыққа тезірек шығуға және нақты пайдаланушылардың мінез-құлқына қарап келесі қадамдарды шешуге мүмкіндік береді, ал әлі бірде-бір клиент қолданбаған функцияларды болжап жазудан құтқарады. MVP-ге не кіретіні туралы бөлек мақаламызда егжей-тегжейлі жазылған.
UX/UI дизайн және прототип
Мобильді қосымшада экран кішкентай, ал пайдаланушының назары қысқа, сондықтан дизайнның рөлі сайтқа қарағанда да жоғары. Бұл кезең әдетте екі бөліктен тұрады: алдымен UX - экрандар арасындағы жол және логика, содан кейін UI - көрініс, түстер, қаріптер, компоненттер. Алғашқы нұсқаны әдетте боялмаған схемалар (wireframe) түрінде жасайды, ол іске қосылмай тұрып-ақ логикадағы олқылықтарды көрсетеді.
Одан кейін интерактивті прототип жасалады: онда экрандар бір-бірімен байланысқан, ал нақты пайдаланушыларға көрсетіп, олардың қайда тұрып қалатынын бақылауға болады. Дизайн өзгерісінің құны әзірлеу басталғаннан кейін бірнеше есе өседі, сондықтан бұл кезеңде жіберілген бір күн кейін апталармен өлшенетін қайта жасаудан сақтайды.
Технологияны таңдау
Мобильді әзірлеуде негізгі таңдау - нативті әзірлеу мен кросс-платформалы тәсіл арасында. Нативті әзірлеу iOS және Android үшін бөлек код жазуды білдіреді: ол құрылғы мүмкіндіктеріне максималды қолжетімділік пен өнімділік береді, бірақ екі команданы немесе екі еселенген жұмысты талап етеді. Кросс-платформалы тәсілде, мысалы Flutter арқылы, кодтың басым бөлігі екі платформаға ортақ болады, бұл бюджет пен мерзімді айтарлықтай қысқартады және көптеген бизнес-қосымшалар үшін сапада байқалатын айырмашылық бермейді.
Нативті жолға ойындар, күрделі 3D-графика немесе құрылғының ерекше мүмкіндіктерімен терең жұмыс істейтін жобалар барады. Каталог, тапсырыс, жеке кабинет, жазылу, хабарлама сияқты типтік бизнес-сценарийлер үшін кросс-платформалы шешім көбіне ақылға қонымды әрі үнемді таңдау болады. Нақты салыстыру Flutter мен нативті әзірлеу туралы бөлек мақалада берілген.
Клиенттік бөлікпен қатар сервер жағы да таңдалады: деректер базасы, API, аутентификация, файлдар сақтау, төлем жүйелерімен және CRM-мен интеграциялар. Қосымша пайдаланушылар саны өскенде де жұмыс істей беруі үшін архитектураны бастапқыда-ақ кеңеюге болатындай етіп жобалаған жөн.
Әзірлеу процесі
Әзірлеу әдетте қысқа итерациялармен (спринттермен) жүреді: әр екі-үш аптада тапсырыс беруші жұмыс істейтін нәтижені көреді, пікір білдіреді және келесі кезеңнің басымдықтарын түзетеді. Мұндай ырғақ «жоба айлап үнсіз жүріп, соңында күтпеген нәтиже шығатын» қауіпті жояды, өйткені бағыт ауытқуы ерте көрінеді және оны түзету арзан тұрады.
Параллель түрде жүретін екі ағын бар: клиенттік қосымша (пайдаланушы көретін бөлік) және сервер жағы мен әкімшілік панель (бизнес қосымшаны басқаратын бөлік). Көптеген бизнес әкімшілік панельді бағаламайды, ал іс жүзінде контентті, тапсырыстарды, пайдаланушыларды және хабарламаларды басқару мүмкіндігінсіз қосымша әр өзгеріс үшін әзірлеушіге жүгінуге мәжбүр етеді. Сондықтан панельдің қажеттілігін ТЗ кезеңінде талқылау керек.
Сұрақ қойыңыз немесе өтінім қалдырыңыз
Мәселеңізді айтыңыз — лайықты технологияны, MVP құрамын және мерзім бойынша бағдар ұсынамыз.
Форманы жіберу арқылы дербес деректерді өңдеуге келісім бересіз.
Тестілеу
Мобильді қосымшаның тестілеуі сайттікінен күрделірек, себебі Android құрылғыларының әртүрлілігі орасан зор: экран өлшемдері, жүйе нұсқалары, өндірушілердің өз бейімдеулері. Сондықтан тестілеу бір-екі телефонмен шектелмей, құрылғылар мен жүйе нұсқаларының өкілдік жиынтығында жүргізілуі тиіс. Функционалдық тестілеу сценарийлердің дұрыс жұмыс істейтінін, ал өнімділік тестілеуі баяу интернетте және әлсіз құрылғыларда қосымшаның қалай ашылатынын тексереді.
Жеке назар қауіпсіздікке аударылады: деректердің қорғалған арнамен берілуі, токендер мен құпия сөздердің дұрыс сақталуы, пайдаланушы деректеріне рұқсат шектеулері. Егер қосымша жеке деректермен жұмыс істесе, персональді деректер туралы заң талаптары да осы кезеңде ескеріледі - бұл туралы бөлек мақаламызда айтылған. Дүкендерге жіберер алдында шағын топпен жабық бета-тестілеу өткізу нақты пайдаланушылар ғана байқайтын қателерді ашады.
App Store және Google Play-ға жариялау
Қосымшаны дүкендерге шығару - әзірлеудің соңғы қадамы емес, оның өз талаптары бар бөлек процесс. Әр дүкеннің контентке, құпиялылық саясатына, деректерді жинауды жариялауға және интерфейске қатысты ережелері бар, ал модерация бірнеше күнге созылуы мүмкін, ал бас тартылған жағдайда түзетіп қайта жіберуге тура келеді. Сондықтан жариялау мерзімін жоспарға алдын ала қосу керек, әйтпесе «дайын қосымша» айлап дүкенге кіре алмай тұрып қалуы мүмкін.
Жариялауға бейнелер мен скриншоттар, сипаттама, кілт сөздер, санат және құпиялылық саясатына сілтеме дайындау кіреді. Дүкендегі қосымша беті - өзі бір маркетингтік құрал, оның сапасы жүктеп алу санына тікелей әсер етеді. Тексеру тізімі туралы бөлек мақалада толығырақ.
Релизден кейін не болады
Релиз жобаның соңы емес, жаңа кезеңнің басы. Нақты пайдаланушылар келгеннен кейін ғана қосымшаның шын мәніндегі мінез-құлқы көрінеді: қай экранда адамдар кетіп қалады, қай функция қолданылмайды, қандай қателер жиі кездеседі. Бұл деректерді жинау үшін аналитика мен қателерді бақылау құралдары (crash reporting) бастапқыдан қосылуы керек.
Қосымшаға тұрақты қолдау қажет: Android пен iOS-тың жаңа нұсқалары шыққанда оның үйлесімділігін сақтау, қауіпсіздік жаңартулары, дүкен талаптарының өзгеруіне бейімделу. Қолдау болмаса, қосымша бірнеше жылда-ақ ескіріп, дүкеннен шығарылып тастау қаупіне ұшырайды. Сондықтан жобаның жалпы құнын бағалағанда әзірлеу бағасына жыл сайынғы қолдау шығындарын қосу керек, ал қолдау шарты бөлек талқыланады.
Мерзім мен құнға не әсер етеді
Қосымшаның құны мен мерзімі бірнеше факторға байланысты: экрандар мен мүмкіндіктер саны, тұрғызылатын платформа (бір немесе екеуі де), дизайнның бірегейлік деңгейі, сыртқы жүйелермен интеграциялар саны, әкімшілік панельдің күрделілігі, офлайн режим, нақты уақыттағы функциялар (чат, трекинг). Бір ғана «қосымша» сөзінің артында шағын бизнес құралынан бастап күрделі маркетплейске дейінгі диапазон жатыр, сондықтан орташа баға туралы сөз өте шартты.
Практикалық кеңес: бағаны алу үшін әзірлеушіге мүмкіндіктер тізімін емес, мәселені және мақсатты нәтижені сипаттаған жөн. Сонда команда мақсатқа жетудің ең арзан жолын ұсына алады. Нақты есептеу үшін MVP құнын есептеу туралы мақаламыз көмектеседі.
Жиі кездесетін қателіктер
Ең жиі кездесетін қателік - алғашқы нұсқаға барлық мүмкіндікті сыйғызуға тырысу: бұл бюджетті үлкейтеді, мерзімді созады және нарықта сынақтан өтпеген болжамдарға ақша жұмсатады. Екінші типтік жағдай - дизайн мен техникалық тапсырмаға жеткілікті уақыт бөлмей, әзірлеуге асығыс кірісу, нәтижесінде өзгерістер әзірлеу барысында қымбат түседі. Көп жобада әкімшілік панель мен қолдау бастапқы бюджетке кірмей қалады, ал жариялаудан кейін бұл олқылық ашылады.
Сонымен қатар, бизнес көбіне қосымшаны жариялаумен жұмыс аяқталды деп есептейді және маркетингке, пайдаланушыларды тартуға және кері байланыс жинауға ресурс қалдырмайды. Қосымша дүкенге түскеннен кейін өздігінен пайдаланушы таппайды, ал жаңа қосымшалардың көпшілігі дәл осы себепті ешкімге көрінбей қалады. Соңында, қауіпсіздік пен персональді деректерді соңғы сәтке қалдыру - кейін қайта жасауға әкелетін қымбат қате.
Тексеру тізімі
- Қосымша қандай мәселені және кімге шешетіні бір-екі сөйлеммен тұжырымдалған
- Идея мақсатты аудиториямен әңгіме және бәсекелестерді талдау арқылы тексерілген
- Техникалық тапсырма жасалған, MVP мүмкіндіктері кейінгі кезеңдерден бөлінген
- Интерактивті прототип нақты пайдаланушыларға көрсетіліп, түзетілген
- Технология (нативті немесе кросс-платформалы) тапсырмаға қарай негізделіп таңдалған
- Әкімшілік панель жоспарға және бюджетке кіргізілген
- Әртүрлі құрылғылар мен жүйе нұсқаларында тестілеу өткізілген
- Қауіпсіздік пен персональді деректер талаптары ескерілген
- Дүкендерге жариялау мерзімі мен материалдары алдын ала дайындалған
- Аналитика мен қателерді бақылау қосылған
- Релизден кейінгі қолдау мен жаңартулар жоспарланған және бюджеттелген
