Разработка мобильного приложения для продажи ж/д билетов

Мобильное приложение для продажи жд билетов: узкие места

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

Второе узкое место — зависание на оплате. Платёж ушёл в банк, ответ не вернулся: сеть пропала или экран закрылся. Человек видит бесконечный индикатор, повторяет попытку и получает второе списание при одном неоформленном билете.

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

Потеря корзины при обрыве связи — самая частая причина брошенной покупки. Поезд, вагон, места и данные пассажиров живут в памяти экрана: метро, входящий звонок, перезапуск — и всё заново. Повторный ввод пассажиров на телефоне занимает ровно те минуты, за которые место уходит другому.

Все четыре точки измеримы: доля двойных продаж, глубина расхождения с кассой, время возврата к брошенному заказу. Разбираем, как это закрывается — от серверной блокировки места до черновика заказа, который переживает обрыв.

Что меняется после запуска: скорость покупки и возвраты

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

Путь покупателя: от поиска до посадочного

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

Время прохождения пути считаем по сегментам — одиночная поездка, группа, возвратный маршрут. Так видно, где ещё теряются покупатели: чаще всего это ручной ввод данных на нескольких пассажиров и повторная авторизация.

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

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

Обратная сторона — обращения в поддержку. Когда статус билета виден в приложении, а ошибка оплаты объясняется человеческим текстом, поток «билет не пришёл», «списались дважды» заметно снижается. Это и есть критерий приёмки: метрики снимаются до релиза и спустя время после, на одних и тех же сегментах.

Варианты реализации: нативная разработка, единая кодовая база, веб

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

Доработка уже выпущенного приложения

Если приложение уже выпущено, смена подхода редко окупается. Сначала снимаем замеры холодного старта, поиска по расписанию и прохождения оплаты, находим узкое место и закрываем его точечно: кэш расписания, переработка экрана оплаты, очередь запросов.

Что нельзя решить сменой подхода

Сменой подхода не лечится серверная часть. Медленный поиск, отвалы при оплате, отсутствие повторной попытки возврата остаются на стороне сервисов, а требования магазинов к обновлениям и работе с персональными данными действуют при любом варианте.

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

Разработку начинаем не с экранов поиска, а с аудита системы продаж: какие справочники поездов и мест доступны, как оформляется бронь, где живут возвраты и обмены. Пока не понятно, откуда приходит актуальное наличие мест и с какой частотой оно меняется, любой макет поиска — рисунок.

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

1. Инвентаризация источников: разбираем запросы к системе перевозчика — поиск, бронирование, оплата, статус заказа, — и фиксируем время отклика каждого.
2. Схема обмена данными: описываем поток «поиск → выбор места → бронь → оплата → билет», помечаем операции, которые обязаны быть идемпотентными при повторе.
3. Локальный контур на устройстве: кэш расписаний и очередь неотправленных запросов, чтобы заказ не терялся на перегоне или в метро.

Проверка: нагрузка, обрывы связи, возвраты

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

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

Что остаётся у заказчика: конфигурации, схемы, регламенты

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

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

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

Регламенты поддержки и выпуска обновлений

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

Документы лежат в репозитории рядом с кодом и проходят ту же проверку, что и релиз, — поэтому регламент не расходится с фактическим поведением приложения.

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

Что было до: ручные сверки и очереди

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

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

Что стало: метрики после запуска

Мы вынесли работу с билетами в отдельный сервис бронирования: место удерживается на время оплаты и подтверждается по факту транзакции, приложение больше не ждёт пакетных выгрузок. Удержание снимается по таймауту, а двойная продажа закрыта блокировкой места — класс отказов «продано дважды» ушёл вместе с ручными сверками.

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

Как организовать возврат и обмен, если рейс отменён?

Отмена рейса — пакетное событие: аннулируется сразу десятки документов, и приложение получает не один заказ, а список затронутых поездок. Его сверяем с билетно-учётной системой перевозчика: какие бланки аннулированы, какие остались в силе. Без сверки часть пассажиров получит возврат за поездку, которая состоится, а часть останется без денег.

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

Обмен проездного документа — отдельная ветка. Если есть подходящий рейс, предлагаем пересесть в приложении: место выбирается заново, разница в тарифе добирается или возвращается тем же способом оплаты, а старый бланк гасится только после оформления нового. При сбое на середине пассажир остаётся с действующим билетом, а не без обоих.

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

Массовые возвраты разбираем очередью с ограничением параллельных операций и повторными попытками с нарастающей паузой: платёжный сервис не считает нагрузку подозрительной, а реестр не растёт быстрее подтверждений. Спорные операции — возврат на другую карту, отмена после обмена, обращение после срока — попадают в отдельный журнал с историей статусов, где решение принимает оператор.

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

Интеграция с кассовой системой перевозчика — первое, что проверяют на старте: обмен идёт через отдельный слой синхронизации, кассы продолжают продавать в своём режиме, а мобильное приложение получает и освобождает места по короткому циклу. Если обмен встал, продажи в кассе не останавливаются — очередь догоняет состояние сама.

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

Что видит пассажир при обрыве связи?

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

Кто отвечает за расхождение по местам?

Расхождение закрывается на уровне обмена: место помечается занятым только после подтверждения от кассовой системы, а спорные случаи уходят в журнал сверки. Разграничение доступа строится по ролям — перевозчик видит свои рейсы и возвраты, перевозчик-партнёр только статистику.

Как проходят возвраты по инициативе перевозчика?

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

Что входит в поддержку после запуска?

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

Обсудим задачу: что прислать и как начнём работу

Чтобы разговор был предметным, а не «расскажите в общих словах», присылайте то, что уже есть: описание сценариев продажи, доступы к тестовому контуру систем бронирования, примеры выгрузок. По этим материалам мы возвращаемся с оценкой задачи и составом работ на первую поставку — без встречных просьб «сначала придумайте за нас».

Что подготовить к первому обсуждению:

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

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

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