Как мы пришли к ScanClick

ScanClick начался не с идеи, а с наблюдения. Мы делали клиенту доработку учётной системы и поехали на склад — посмотреть, как люди реально работают. Это привычка, которая экономит недели: то, что описано в задаче, и то, что происходит в жизни, обычно две разные вещи.

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

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

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

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

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

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

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

Это, кстати, общий принцип, который мы вынесли: инструмент, который работает в 90% случаев, люди не используют вообще. Не в 90% случаев — вообще. Потому что нельзя построить процесс на том, чему нельзя доверять.

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

Технически всё довольно скучно, и это осознанно. Мобильный клиент на Flutter — одна кодовая база под iOS и Android, для интерфейса из четырёх экранов этого более чем достаточно. Сервер на Go: принимает пачки отсканированного, разбирает, складывает, отдаёт наружу. Разворачивается в Docker, в том числе на инфраструктуре клиента, если данные нельзя выпускать за периметр.

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

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

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