Внутренняя кухня разработки: как мы создаем кассовое ПО⁠⁠

Продолжаем знакомить с нашей «внутрянкой»! В прошлый раз рассказали, как создаются новые кассы самообслуживания. В этом посте вместе с Михаилом Фокеевым, руководителем направления Frontol, погрузимся в процесс разработки кассового ПО для предпринимателей.

Для чего нужно кассовое ПО

Программное обеспечение — это дирижер на рабочем месте кассира. Оно объединяет всю периферию: сканеры, весы, принтеры для чеков. Связывает кассу и информационные системы: базу товаров, программу лояльности, учет алкоголя (ЕГАИС) и проверку маркированных товаров («Честный ЗНАК»). Без такого ПО кассиру пришлось бы вручную проверять каждую позицию: доставать калькулятор, сверяться с сайтом по скидкам, следить за маркировкой.

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

Зачем нужны дополнительные модули

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

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

Например, на кассовом рабочем месте стоит ПО Frontol 6 или Frontol xPOS, которые обеспечивают автоматизацию. А на серверах работают такие продукты, как Frontol Discount Unit и Frontol Cloud, которые позволяют собирать все данные в онлайн-режиме.

⮕ Узнать больше о ПО Frontol 6

Кто и как придумывает новые функции

Ты просто просыпаешься посреди ночи, и тебя осеняет: «О, а что если сделать вот такую штуку?» Шутка :) В работе мы придерживаемся классического продуктового подхода:

1. Проводим сквозное интервью с клиентами, партнерами, потенциальными пользователями.

2. Собираем гипотезы.

3. Проверяем, сколько клиентов это затронет, какую ценность даст бизнесу, сколько сил потребует реализация.

4. Часть гипотез проверяем через MVP (минимально жизнеспособный продукт) или ранний доступ.

5. Показываем прототипы экспертам, собираем обратную связь.

6. Только после этого принимается решение о дальнейшем развитии и разработке.

Можно ли прийти с личным запросом

Если какой-то функции нет на рынке и она нужна конкретному клиенту, мы анализируем запрос и потребности рынка. А главное, не сломает ли эта функция работу наших пользователей.

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

Как расставляем приоритеты

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

Поэтому большие функции мы не делаем целиком за год. Мы делим их на маленькие этапы, выпускаем MVP, щупаем рынок, собираем обратную связь. Корректируем курс прямо по ходу.

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

Как устроен процесс разработки

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

Когда квартальный план утвержден, команда уточняет детали, оценивает трудозатраты, нарезает большие задачи на маленькие (бэкенд, фронтенд, дизайн, аналитика). В течение спринта разработчики трудятся над ними. Если все сделано, клиент получает готовую бизнес-функцию.

Что может сдвинуть релиз

Внешние факторы. Например, меняется законодательство, или вендор без предупреждения обновляет API.

Баги. Иногда нужно внести изменения в уже работающие решения — такие задачи мы включаем в текущий релиз.

Отваливается тестовая среда. В таком случае мы не можем протестировать решение, а выпускать непроверенное рискованно.

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

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

Как тестируется кассовое ПО

Сложность в том, что нужно проверять не только свою работу, но и ее взаимодействие с десятками внешних систем: ЕГАИС, «Честный ЗНАК», разное фискальное оборудование. Для этого составляем тест-кейсы, часть проверяем автоматически, часть — вручную.

Когда в процесс включаются партнеры и клиенты

Еще на этапе проверки гипотез. Мы показываем партнерам макеты, прототипы, MVP и спрашиваем: «Это закрывает ваши потребности?» Иногда созваниваемся по квартальным планам: рассказываем, что хотим сделать, и слушаем предложения. Партнер может сказать: «Эта задача больше не актуальна, у нас уже есть другое решение» или «Лучше сделайте вот так».

Что происходит после релиза

Мы анализируем, как часто используют новую функцию, какая доля аудитории, растет ли проникновение. Если планировали, что за три месяца функцией начнут пользоваться 30% клиентов, а получили только 10% — ищем причину.

Варианты:

• Мы плохо объяснили рынку, как это работает. Например, однажды партнер узнал, что модуль для работы с маркировкой уже входит в тариф, через полтора года после анонса.

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

Чем мы гордимся сегодня

Активно развивается направление самообслуживания. За год мы выросли в 5–6 раз по количеству пользователей. Три года назад у нас было простое решение. Сейчас у нас новый интерфейс, мы добавляем видеораспознавание товаров: покупателю не нужно искать позицию в списке, ПО с помощью ИИ понимает, что это огурцы, а не баклажаны, позволяя более быстро совершать покупки.

Приятно видеть результат. Недавно я вылетал из Казани, зашел в бутик в аэропорту — стоит наша касса самообслуживания с Frontol Selfie Pro. Я такой: «Да, это наше решение!»

Теперь вы знаете, как создается кассовое ПО — от первых гипотез до работы в крупных сетях. Если вы развиваете бизнес и хотите ускорить продажи, избавиться от очередей или перестать бояться штрафов за просрочку, загляните на наш сайт. Выбирайте готовое решение или получите консультацию специалиста АТОЛ.