«Студенти, код і банкомати»: як 10 студентів створили застосунок для інкасаторів за місяць

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт, спільното! Цього літа у нашій компанії 10 студентів працювали над розробкою застосунку для інкасаторів. Що з цього вийшло, розповім у матеріалі нижче.

Для чого і для кого

Один із головних напрямків роботи РЕНОМЕ СМАРТ, окрім створення ПЗ, — надання послуг сервісного обслуговування банкам. Вони включають віддалений моніторинг стану пристроїв, а також безпосередній виїзд інженерів до банкоматів та терміналів для їх ремонту та обслуговування. Кожен такий виїзд — це час і гроші, а проблема іноді буває настільки елементарна, що її може вирішити і людина без спеціалізованої технічної освіти. Однак, довірити втручання у роботу коштовної техніки усім ми не можемо, тож вирішили сконцентруватись на тих, хто взаємодіє із банкоматами регулярно: інкасаторами. Виникла ідея створити застосунок для служб інкасації, який би оптимізував тристоронню комунікацію «інкасатор-банк-компанія». У результаті ми планували отримати інструмент, який би скоротив час простою АТМ, зменшив кількість викликів сервісних інженерів та інженерів моніторингу, підвищив задоволеність користувачів та точність і якість виконання інкасаційних операцій.

Нюанс був лише у тому, що на момент появи ідеї усі розробники компанії були залучені в інші комерційні проєкти. Але вихід знайшовся!

Хто? Що? Коли?

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

Навесні 2025 року департамент маркетингу вкотре оголосив набір на стажування, а HR обрала серед усіх охочих студентів із потрібними нам скілами.

Тож у середині червня сформувалась команда стажистів із 10 студентів рівненських ВНЗ: двоє дівчат та восьмеро хлопців.

Усього за місяць вони мали створити застосунок для інкасаторів. Челендж? 100%.

Але їм допомагали ментори від компанії: бізнес-аналітикиня, троє розробників та UI/UX дизайнер.

Задум та реалізація

Ідея застосунку полягала у тому, щоб створити своєрідний довідник для інкасаторів, у якому містилися б наступні дані:

• інструкції з виконання інкасації
• описи типових проблем, що виникають на банкоматі та способи їх вирішення
• розшифровки SCOD-помилок (помилок касового модуля) та способів їх вирішення.

Окрім того, для випадків, коли опис проблеми і варіантів її вирішення не дав результату, застосунок також мав би містити опцію підтримки.

Усі ці опції доступні після реєстрації у застосунку, яка валідується адміністратором.

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

Адміністративна частина дозволяє редагувати контент та валідувати нових користувачів.

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

• перегляду інструкцій з інкасації за ID банкомату
• перегляду рішень типових проблем
• перегляду рішень SCOD-помилок
• зв’язку із службою підтримки

Пройдемось по усім пунктам.

Перше. Поле для введення ID банкомату для отримання інструкції з виконання інкасації. Здавалося б, навіщо вони інкасаторам, які виконують роботу з розвантаження/завантаження банкоматів чи не щодня? Річ у тому, що хоч процес стандартизований, але, залежно від виду банкомата, він може дещо відрізнятись. Некоректні дії під час інкасації можуть призвести до подальшої непрацездатності банкомата. А людський фактор не можна скидати з рахунку. Тому у застосунку передбачена можливість визначення моделі банкомата по ID та перегляду інструкції з інкасації з уніфікованими та стандартизованими покроковими вказівками. ID типово можна знайти у чеку або маршрутному листі інкасаторів, але у застосунку також можна переглянути короткий гайд, де його шукати.

Друге. Поле для введення SCOD. Кожен SCOD касового модуля відповідає певній помилці або стану касового модуля. Наприклад, SCOD 00 означає, що усе працює. Помилки нумеруються від 01 і далі та мають стандартні процедури розв’язання. Коли інкасатор бачить номер помилки, він може не пригадати одразу, що вона означає, тож у застосунок ПРОІНКАС було вирішено додати і такий функціонал, щоб спростити роботу інкасаторів і зменшити кількість звернень у службу підтримки. Передбачена також коротка інструкція для пошуку SCOD на банкоматі.

Інструкції та тексти для усіх трьох опцій конфігуруються централізовано адміністратором застосунку за допомогою xls таблиць і html. файлів.

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

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

Процес роботи та технології

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

У команді 7 людей виконували ролі розробників, із них 3 писали фронтенд, 3 бекенд і один фулстек. Одна людина виконувала роль BA, одна — PM/QA та одна — UI/UX дизайнера. Після офлайн знайомства вони самостійно розподілили ролі, у тому числі визначили, хто із розробників писатиме мобільний застосунок, а хто — адмінську частину. Стажисти обрали тімліда і саме він додавав таски у Trello. Усі таски були із позначками «сайт», «застосунок», «бекенд» тощо. Для контролю версій використовували Git.

Застосунок було вирішено писати для Android у зв’язку із тим, що ця платформа більш поширена, а також через часові обмеження стажування. Дизайн обрали світлий та мінімалістичний у сірих і бірюзових кольорах.

Які технології використовували стажисти?

• мобільний застосунок стажисти писали на React Native
• адмінську частину на React
• для серверної частини використали ASP.NET, C#
• бізнес-аналітикиня використовувала у своїй роботі Figma та draw.io

Судячи із спілкування з стажистами, ChatGPT вони використовували, але помірно.

Попри те, що у команді було два QA (один паралельно виконував роль розробника, інший — PM-а), тестуванням займались переважно самі розробники після інжинірингу кожної нової функції. Найчастіші баги стосувались дизайну (з’їхала кнопка, відобразився інший шрифт). Після фактичного завершення процесу розробки, QA ще раз протестували весь функціонал та підправили нюанси.

За місяць студенти створили понад 600 комітів у Git.

Що не реалізували, але хотілося б

Через стиснуті строки не усе задумане вдалось реалізувати.

Зокрема, була ідея інтегрувати у застосунок ШІ із можливістю введення довільного запиту текстом або голосом для швидкого пошуку інформації та формування відповіді.

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

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

Що далі

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

• Передусім — доопрацювання та тестування поточної версії
• Наповнення застосунку інформацією (описами типових проблем, інструкціями з їх вирішення, перелік SCOD тощо)
• Формування комерційної пропозиції та презентація продукту потенційним клієнтам
• За потреби — доопрацювання під потреби клієнтів
• Делівері

Висновки

Насправді застосунок перевершив очікування менторів та замовників. Вони були налаштовані дещо скептично. Однак, студенти спромоглись створити MVP за дуже обмежений термін із буквально кількома консультаціями, працюючи з прискіпливими замовниками, що періодично змінювали вимоги. Одній із стажисток компанія зробила офер і вона наразі проходить випробувальний період на роль бізнес-аналітикині. А наші розробники готуються допилювати ПРОІНКАС та просувати продукт на ринку.