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

За последние годы в Else Digital мы реализовали десятки проектов: от небольших MVP до сложных финтех- и B2B‑сервисов. Мы тестировали разные сценарии работы с пользователями, интеграции с платежными системами, сталкивались с багами и сложными кейсами, считали реальные сроки и риски. В итоге стало понятно, как строить мобильное приложение для учета газа, чтобы оно было удобным, безопасным и готовым к работе с реальными пользователями, без потери данных и функциональности.

Определение базового функционала

Компания «Турбулентность Дон» более 18 лет занимается производством приборов учёта газа и жидких углеводородов. Бизнес хорошо выстроен на уровне оборудования, но взаимодействие с конечными пользователями долгое время оставалось офлайн‑ориентированным: показания передавались вручную, оплата вызывала сложности, а контроль расхода был фрагментарным.

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

• передача показаний газа;
• получение и хранение квитанций;
• онлайн‑оплата;
• контроль и анализ расхода.

Ключевым требованием со стороны заказчика было реальное повышение удобства и лояльности пользователей, а не формальное присутствие в App Store и Google Play.

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

Процесс разработки

Выяснилось несколько проблем:

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

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

Над проектом работала кросс‑функциональная команда:

• проджект‑менеджер;
• бизнес‑аналитик;
• UX/UI‑дизайнер;
• iOS- и Android‑разработчики;
• backend‑разработчик (Python);
• тестировщик.

Разработка велась итерационно. Каждая функция проходила путь: аналитика → прототип → разработка → тестирование → проверка на реальных сценариях.

Как устроено приложение и какие решения были приняты

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

Трудность: важно было обеспечить корректную работу при наличии нескольких счётчиков у одного пользователя.

Решение:

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

В результате пользователь вводит данные один раз и дальше работает в приложении без лишних шагов и повторов.

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

Реализованы:

• PUSH‑уведомления о необходимости передать показания;
• уведомления о новой квитанции;
• напоминания о поверке счетчиков.

Решение:

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

Онлайн‑оплата как часть пользовательского опыта. Финансовые операции — зона повышенных ожиданий со стороны пользователей. Здесь важны простота, безопасность и прозрачность.

В приложении реализована онлайн‑оплата газа. Пользователь всегда видит:

• сумму к оплате;
• выбранный способ платежа;
• подтверждение успешной операции.

Трудность: интеграция платежной системы должна была быть устойчивой и понятной для пользователей без цифрового опыта.

Решение:

• проработали пользовательский сценарий оплаты шаг за шагом и убрали все необязательные действия;
• интегрировали платежную систему с обязательным подтверждением успешной операции.
• добавили визуальные статусы: сумма, способ оплаты, результат транзакции.

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

• стандартный и накопительный расход;
• историю показаний списком;
• график потребления газа.

Трудность: данные должны быть наглядными и понятными, без перегруженных графиков и сложных терминов.

Решение:

• определили минимальный набор показателей, который действительно нужен пользователю;
• реализовали архив с историей показаний, накопительным расходом и визуальным графиком;
• проверили отображение данных на реальных показаниях и сценариях.

Это снизило количество обращений в поддержку и дало пользователю ощущение контроля над данными.

Техническая архитектура

Приложение разработано под две платформы:

• iOS — Swift;
• Android — Kotlin;
• backend — Python.

Через API реализован обмен данными:

• передача показаний;
• получение квитанций;
• подтверждение оплат;
• взаимодействие с системой учёта.

Отдельным этапом стала официальная интеграция с Газпромом, которая обеспечила легальную и стабильную работу с ресурсоснабжающей организацией.

Рекомендации для разработки коммунальных приложений

1. Начинайте с аналитики, а не с дизайна. Ошибки в сценариях обходятся дороже, чем правки интерфейса.
2. Минимизируйте регулярные действия пользователя. Всё, что можно автоматизировать, должно быть автоматизировано.
3. Используйте push‑уведомления только по необходимости. Отправляйте только те сообщения, которые ведут к конкретному действию.
4. Финансовые операции должны быть максимально прозрачными. Пользователь всегда должен понимать, что и за что он платит.
5. Думайте о масштабировании с первого релиза. Интеграции, архитектура и данные должны быть готовы к росту нагрузки и функциональности.

Результат и выводы

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