Розробка мобільного додатка для продажу залізничних квитків

Мобільний застосунок для продажу залізничних квитків: вузькі місця

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

Якщо рішення «місце вільне» ухвалює клієнт, двоє проходять підтвердження й отримують той самий проїзний документ — а розбиратися доводиться вручну.

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

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

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

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

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

Запуск змінює не картинку, а вимірювані показники: скільки людей доходить до оплати, скільки часу витрачає кожен, чи витримує система пік. Нижче — що саме перевіряємо на даних після релізу.

Шлях покупця: від пошуку до посадкового

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

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

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

Поведінка в день відкриття продажів

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

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

Зворотний бік — звернення до підтримки. Коли статус квитка видно в застосунку, а помилка оплати пояснюється людським текстом, потік «квиток не прийшов», «списали двічі» помітно знижується.

Це і є критерій приймання: метрики знімаються до релізу й через час після, на одних і тих самих сегментах.

Варіанти реалізації: нативна розробка, єдина кодова база, веб

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

Допрацювання вже випущеного застосунку

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

Що не можна вирішити зміною підходу

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

Етапи впровадження: від аудиту системи продажів до передачі

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

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

Підготовка: аудит і схема обміну даними

1. Інвентаризація джерел: розбираємо запити до системи перевізника — пошук, бронювання, оплата, статус замовлення, — і фіксуємо час відгуку кожного.
2. Схема обміну даними: описуємо потік «пошук → вибір місця → бронювання → оплата → квиток», позначаємо операції, які зобов’язані бути ідемпотентними при повторі.
3. Локальний контур на пристрої: кеш розкладів і черга невідправлених запитів, щоб замовлення не губилося на перегоні чи в метро.

Перевірка: навантаження, обриви зв’язку, повернення

• Перевірка під навантаженням: відтворюємо відкриття продажів на популярний напрямок — сплеск пошуку, конкуренцію за останні місця, відмову платіжного сервісу.
• Сценарії обривів: рвемо зв’язок між оплатою й підтвердженням і перевіряємо, що повторне надсилання не створює друге бронювання й не списує двічі.
• Повернення та обміни: проганяємо повний цикл — заявка із застосунку, оновлення статусу, повідомлення пасажира.
• Передача проєкту: передаємо вихідні коди, документацію з обміну, доступи й регламент релізів, приймання йде за чек-листом.

Так на момент передачі замовник отримує не збірку, а передбачуваний контур продажів, який витримує пік і не ламається на слабкому зв’язку.

Що залишається у замовника: конфігурації, схеми, регламенти

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

Документація з обміну даними та ролями доступу

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

Регламенти підтримки й випуску оновлень

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

Документи лежать у репозиторії поруч із кодом і проходять ту саму перевірку, що й реліз, — тому регламент не розходиться з фактичною поведінкою застосунку.

Кейс: запуск продажів на 40 напрямках без простоїв

Що було до: ручні звірки та черги

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

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

Що стало: метрики після запуску

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

Утримання знімається за таймаутом, а подвійний продаж закрито блокуванням місця — клас відмов «продано двічі» пішов разом із ручними звірками.

За навантаженням 40 напрямків тримають пік без черги: бронювання підтверджується до 2 секунд, сервіс піднімається за 3-4 хвилини після збою. Частка повторних покупок зросла з 19 до 43% — позначилися стабільні статуси бронювання й передбачуваний час оформлення. Підтримка звільнила нічні зміни під реальні звернення, а не під звірку вивантажень.

Як організувати повернення та обмін, якщо рейс скасовано?

Скасування рейсу — пакетна подія: анулюється одразу десятки документів, і застосунок отримує не одне замовлення, а список зачеплених поїздок. Його звіряємо з квитково-обліковою системою перевізника: які бланки анульовано, які залишилися чинними.

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

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

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

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

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

Спірні операції — повернення на іншу картку, скасування після обміну, звернення після строку — потрапляють в окремий журнал з історією статусів, де рішення ухвалює оператор.

Технічні сумніви: інтеграція, навантаження, безпека

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

Нижче — п’ять технічних сумнівів, які найчастіше піднімають до початку робіт. Розбираємо кожен предметно, бо саме на них тримається довіра до системи.

Що бачить пасажир під час обриву зв’язку?

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

Хто відповідає за розбіжність щодо місць?

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

Як проходять повернення з ініціативи перевізника?

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

Що входить у підтримку після запуску?

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

Обговоримо задачу: що надіслати і як почнемо роботу

Щоб розмова була предметною, а не «розкажіть у загальних словах», надсилайте те, що вже є: опис сценаріїв продажу, доступи до тестового контуру систем бронювання, приклади вивантажень.

За цими матеріалами ми повертаємося з оцінкою задачі та складом робіт на першу поставку — без зустрічних прохань «спочатку придумайте за нас».

Що підготувати до першого обговорення:

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

Далі порядок такий: обговорення задачі по суті, оцінка задачі та склад робіт, узгодження плану впровадження за етапами, потім передача документації — схем інтеграції, конфігурацій середовищ та інструкцій для вашої команди підтримки.

Якщо матеріалів поки мало, приходьте з тим, що є: на зустрічі визначимо, чого не вистачає для плану, і зафіксуємо, хто і що готує.