Sales force automation: мобильное приложение мерчандайзера на платформе 1С с распознаванием товара на 15 языках в одном из крупнейших агентств на нашем континенте (и не только)

Меня зовут Наталья Овчинникова, я ведущий разработчик в компании «Рассвет», которая специализируется на разработке мобильных приложений для 1С.

Последние пару лет я на конференциях Инфостарта делюсь своим опытом разработки.

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

Для текущего доклада я доработала выложенный ранее шаблон приложения и тоже поделюсь им с вами – т.е. этот доклад будет продолжением начатой ранее темы.

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

 

Несколько слов о заказчике проекта:

• Open Group – это международное маркетинговое агентство с численностью около 20 тысяч сотрудников. Имеет представительства в 18 странах, в России входит в тройку крупнейших компаний в своем секторе.

• Основная задача компании – это выкладка товара на полках магазинов по требованиям производителей или торговых сетей. Компания оказывает и другие услуги, но наша основная задача была – автоматизировать работу полевого персонала.

• У агентства более сотни крупных клиентов, среди которых такие как «Балтика», Lavazza, Mars и так далее.

 

Клиент попросил нас сделать прототип мобильного приложения для мерчандайзеров с максимальным использованием существующих объектов конфигурации 1С. Они уже начали разрабатывать это приложение сами – добавили туда анкеты и задачи для мерчендайзеров. Нам нужно было только немного доработать его под требования.

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

Весь проект должен был длиться примерно два месяца, а после этого, согласно плану, мы должны были передать разработку заказчику, чтобы они уже сами дорабатывали ее дальше силами своего ИТ-отдела.

 

Основные цели и требования проекта заключались в следующем:

• в приложение мерчандайзеру должны прилетать анкеты с вопросами, на которые нужно ответить;

• приложение должно уметь работать в автономном режиме;

• при доступности интернета приложение должно передавать информацию на сервер для контроля и анализа.

Мы получили от заказчика прототип и доработали его согласно ТЗ – добавили в анкеты возможность сделать фото, записать текущие координаты, организовали обмен между мобильным приложением и сервером.

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

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

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

3. Помимо этого, для оперативного получения информации на сервере этот документ с большой табличной частью необходимо было постоянно передавать на сервер. Здесь мы уже столкнулись со взаимными блокировками, потому что в момент передачи объект блокируется, и если пользователь пытался внести какие-то новые ответы, все это колом вставало – мерчандайзер не мог продолжать работать.

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

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

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

 

Структура новой анкеты

 

Из нашего опыта проектирования взаимодействия клиентской и серверной части мы знаем, что:

• Желательно создавать такие структуры данных, чтобы вероятность одновременного использования одного и того же объекта в мобильном и настольном устройстве сводилась к минимуму. Например, если сотруднику нужно заполнить количество у товаров, не надо проставлять количество в табличную часть этого же задания – лучше на каждый товар создавать отдельную запись в регистре с нужным количеством. Или создавать для исполнения задания отдельный документ – это уже зависит от ситуации.

• Если задание может одновременно выполнять сразу несколько сотрудников, лучше заранее предусмотреть, что «Задание» – это один документ, а «Исполнение задания» – другой. Тогда вы просто на сервере получите несколько документов и там уже решите, что с этим делать. Мы в такой ситуации всегда определяем приоритет по очередности – кто документ первым отправил, тот и денежку получит.

• Большинство данных должно записываться только один раз – не надо постоянно перезаписывать документ. Например, если необходимо отменить задачу, лучше предусмотреть у нее статус «Отмена». А для удаления – статус «Неактивно» и так далее.

 

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

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

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

• Также у нас документ «Задание» с табличной частью «Вопросы», куда автоматически выводятся все активные вопросы для мерчандайзера.

• И есть справочник «Ответы», элементы которого создаются и изменяются мерчандайзером при выполнении задания в мобильном приложении.

На слайде вы видите пример простейшего вопроса, в котором указано, что:

• задачу нужно выполнить для каждого товара, указанного в матрице данной торговой точки;

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

 

Все врут!

 

 

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

• У нас были регулярные случаи, когда мерчандайзеры переводили время на телефоне и начинали выполнять задачу задним числом или наоборот, будущим.

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

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

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

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

• Вместе с универсальным временем я всегда записываю локальное время пользователя.

• Кроме этого, фиксирую время сервера, когда эта задача прилетела на сервер.

Все эти данные помогают проанализировать ситуацию, если что-то пошло не так.

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

 

Как я уже говорила, за сотрудниками нужен контроль во всем.

• Оказалось, что некоторые мерчандайзеры приступают к выполнению заданий, оставаясь дома. Чтобы этого избежать, мы стали контролировать текущее местоположение пользователя, сравнивая его текущие координаты с координатами торговой точки. Мы это назвали «контроль чекина» – пользователь не может начать выполнять визит, пока его текущее местоположение не совпадет с координатами торговой точки. Допустимой считалась погрешность в 300 метров – эта величина могла меняться в зависимости от требований конкретного клиента – он мог как увеличить допустимую погрешность, так и уменьшить ее.

• Одновременно мы столкнулись с проблемой фейковых координат, т.к. оказалось, что у многих мерчандайзеров на телефоне установлены программы наподобие Fake GPS, которые подменяют текущее местоположение. Запретить им устанавливать такие программы мы не могли, поэтому ввели еще один дополнительный контроль – при начале визита мерчандайзер должен сделать фото входа в торговую точку и фото чека, где видна дата, время, адрес точки.

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

 

Нормализация наименований и координат торговых точек

 

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

Клиенты присылали перечень торговых точек в произвольном виде – так, как они указаны у них в программе. Это могли быть как большие супермаркеты, так и небольшие магазины возле дома, или даже маленькие ларьки.

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

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

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

• На форму обработки с полем HTML выводилась Яндекс.Карта – мы передавали сервису Яндекса список адресов и получали их координаты.

• Кроме этого, мы реализовали интеграцию с сервисом DaData. Это платный сервис, зато с его помощью мы вместе с координатами точки получали еще и нормализованный адрес – это позволило нам быстро сливать дубли торговых точек разных клиентов.

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

 

Оценка качества визита

 

Для оценки качества визита мы создали специальное рабочее место, где система сама находила подозрительные визиты:

• Определялись нереалистичные значения времени и скорости перемещения между точками – эти параметры подделать достаточно сложно.

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

За фейковые визиты сотрудник не получал зарплату, и такие визиты исключались из отчетности перед клиентом.

 

На слайде пример результата оценки качества конкретного визита чек-менеджером. Здесь мы видим, что:

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

• Обнаружена часть фейковых фото, а часть фото размыта.

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

 

S3-хранилище для быстрой работы с тысячами фотографий

 

Перейдем к моему любимому – тысячи фото в 1С.

Работая в приложении, мерчандайзер постоянно фотографирует: при начале визита; при начале и завершении раскладки товара на полку; при завершении визита.

Когда все эти снимки отправлялись напрямую в базу 1С, это полностью подвешивало работу как сервера, так и всех мобильных приложений, которые в этот момент пытались передать свои фотографии.

На предыдущих своих докладах я уже рассказывала, что мы используем S3-хранилище Яндекса для хранения двоичных данных, в том числе и фотографий. Именно на проекте Open Group мы поняли, что при большом потоке одновременного получения информации передавать фотографии на сервер 1С или даже на FTP-сервер напрямую нельзя – для этой цели нужно искать какое-то принципиально иное решение, основанное на облачных технологиях Yandex Object Storage.

Скажу еще раз кратко о преимуществах технологии использования S3-хранилищ:

1. При передаче данных из мобильного приложения в облако вы используете только канал сотовой связи своего мобильного устройства.

2. Причем вам доступно столько каналов, сколько мобильных устройств. Например, у Яндекса очень широкие каналы связи на загрузку данных – пользователи не чувствуют вообще никаких зависаний.

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

4. Уменьшаются затраты на содержание собственного хранилища – теперь эту нагрузку уже берет на себя оператор, который оказывает вам услугу.

Если вы хотите протестировать S3-хранилище, я в дополнительных материалах написала подробную инструкцию, как там зарегистрироваться, настроить и организовать весь процесс.

 

Ход исполнения визитов и мониторинг дня

 

Мы реализовали фоновую отправку данных на сервер, добавили контроль геопозиции, сделали отправку фото в облако.

Все это позволило нам создать в 1С очень быстрый и наглядный интерфейс «Лента визитов», позволяющий отслеживать выполнение задач сотрудниками в реальном времени.

В «Ленте визитов» супервайзер видит:

• список всех визитов за период – их текущий статус и состояние;

• при необходимости можно посмотреть прогресс исполнения каждого визита;

• увидеть перемещение мерчандайзера на карте за текущий момент;

• и можно увидеть все фотографии, которые мерчандайзер сделал по текущему визиту.

Достаточно быстро было принято решение о создании кабинета для заказчика на платформе 1С с доступом через веб, где уже сам заказчик может в реальном времени отслеживать исполнение своих задач. Это приводит к большому доверию между заказчиками и исполнителями.

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

• необходимо выдать сотруднику задачу;

• проконтролировать исполнение этой задачи;

• практически всем необходим фотоотчет или сканы документов;

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

 

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

• Позволяет мониторить сразу большое количество задач и обращать внимание только на отклонения.

• Здесь супервайзер уже наглядно видит состояние выполнения всех своих задач на текущий период по всем его сотрудникам.

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

 

Мультиязычное мобильное приложение

 

 

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

Заказчиком стала турецкая компания, которая решила исследовать рынки таких стран, как Армения, Грузия, Азербайджан и еще несколько. Было решено использовать наших русскоязычных супервайзеров, а мерчандайзеров уже необходимо было набирать на местах. Встала задача перевода мобильного приложения на другие языки. Естественно, все это нужно было уже вчера, поэтому надо было это все быстро организовать.

1С поддерживает мультиязычность, это огромный плюс. Мы воспользовались инструкциями и в итоге перевели приложение. Что мы сделали?

• Создали все языки в конфигураторе.

• У строковых литералов проставили код НСтр().

• Все строки из конфигурации выгрузили в табличный документ.

• Создали в Google-таблицах документ с формулой автоматического перевода. Благо мы в приложениях используем не литературный язык, а технический, поэтому перевод получился достаточно четкий.

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

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

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

 

 

Вот так табличка выглядит в Google. Среди материалов к докладу вы найдете эту табличку с формулами автоматического перевода и описание, как ей воспользоваться.

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

 

 

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

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

 

Распознавание товара

 

Однажды у нашего клиента возникла блестящая идея сделать так, чтобы система могла распознавать товар, расположенный на полке. Как минимум это дало бы возможность проконтролировать работу мерчандайзера – проверить, правильно ли он расставил товар в соответствии с планограммой.

Так как 1С распознавать товар не умеет, мы воспользовались сторонними сервисами – изначально мы работали с Intelligence Retail, позже стали использовать сервис Mirum.

Общая логика работы следующая:

• Мы выгрузили из 1С список SKU конкретной категории товара, предварительно указав фотографию у каждой номенклатурной позиции.

• Передали это все в сервис – там произошло обучение системы.

• И только после этого уже начинается текущая работа по распознаванию товара на полках.

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

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

• для Android – возможность управления:размером и качеством фотографий;

• для iOS и Windows – управление только качеством.

 

Автокорзинка. Распознавание ценников

 

 

После различных экспериментов распознавания был реализован следующий процесс:

• Мерчандайзер во время визита делает несколько фото полок и отправляет их в облако.

• Сервер 1С забирает из облака ссылки на фотографии и передает их в сервис распознавания.

• Чтобы сервис мог возвращать список распознанных на каждой фотографии товаров, мы его заранее обучили. При этом мы столкнулись с проблемами распознавания некоторых видов крепкого алкоголя. Оказалось, что бутылки размера 0,25 и 1 литр выглядят одинаково – допустим, система понимает, что это ликер «Бейлис», но не может определить его объем. Чтобы решить эту задачу, мы добавили функцию распознавания ценников и заранее указали для каждой матрицы товаров диапазоны, соответствующие различным объемам бутылок. Это позволило дополнительно улучшить точность системы распознавания.

• Получив с сервиса список распознанного товара на полке, 1С может без труда посчитать так называемые фейсинги – это сколько товара сейчас находится на полке, сравнить этот список с планограммой клиента и выяснить разницу, какого товара не хватает.

• Этот список отправляется мерчандайзеру на телефон, тот идет на склад, берет этот товар на складе, возвращается, расставляет на полке и опять делает фотографию.

• Фото опять отправляется в распознавание, мерчандайзеру снова возвращается список разницы между полкой и планограммой, но здесь уже предлагается ввести причину отсутствия товара на складе или причину OOS – почему в итоге действительность не соответствует тому, что нужно.

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

 

Автоматическая полка

 

Компания Open Group очень амбициозная, и, как и все крупные игроки, старается смотреть вперед. В 2019 году они решили реализовать задачу «Автоматическая полка».

Суть этой задачи в том, что в магазине над потолком монтируется рельса, по которой ездит камера и периодически делает фотографии – причем в момент фотографирования можно как взять товар с полки, так и поставить его обратно. Эти снимки отправляются на сервер в 1С, распознаются и считаются различные варианты, что там находится – так называемый KPI.

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

Примерный вид процесса вы видите на слайде справа, а видео показывает то, как это демонстрировалось в Сколково в 2019 году. При этом сервер, который все обслуживал, был у нас в Екатеринбурге.

 

Результат на экране периодически обновляется.

• Здесь мы видим реалограмму – как действительно стоит товар, и как он распознан.

• Также мы видим важные параметры, такие как:

  • OSA – доступность товара на полке;

  • какую долю занимает товар нашего клиента, и какова доля остальных брендов;

  • и заодно мы можем автоматически мониторить товары и цены конкурентов.

 

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

 

Итог проекта

 

Клиент получил от нас значительно больше запланированного. Изначально планировалось, что мы буквально два месяца поработаем, передадим им на разработку, но в итоге у нас проект продлился около двух лет. В течение этих лет мы реализовали очень много функций, идей, чего только мы не делали с помощью 1С, чтобы посмотреть, как это будет выглядеть.

Причем до работы с нами у клиента уже было несколько вариантов мобильных приложений, разработанных на других языках, но они были только для Android. С помощью платформы 1С мало того, что мы могли быстро реализовывать все их идеи, мы также опубликовали приложение не только на Android, но и на iOS.

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

1. На тот момент мы не могли организовать интерфейс мобильного приложения в том виде, в каком они его видели.

2. Оказалось, что стоимость лицензирования всех мобильных и стационарных пользователей на платформе 1С с учетом лицензии КОРП оказалась выше, чем разработка нового приложения на открытых технологиях.

 

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

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

Основная суть приложения – это чат, в котором можно ознакомиться с реализацией следующих универсальных функций:

• Авторизация по смс или звонку, по связке логина и пароля, по QR-коду.

• Отправка данных в S3-хранилище.

• Обмен между мобильным приложением и сервером.

• Отправка и получение push-уведомлений.

Сейчас в шаблоне были доработаны следующие возможности:

• Я сделала отправку сообщения чата сразу на сервер, без регистрации его в план обмена.

• Улучшила отображение большого количества сообщений в поле чата.

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

• Реализовала ответ на сообщения, как это сделано во многих чатах.

Также я обновила дополнительные материалы – можете ими пользоваться.

 

Напоследок немного расскажу об опыте последнего года.

Как я говорила в предыдущем докладе, мы пользуемся облачными продуктами Atlassian – используем Confluence для управления разработкой и ведения проектной пользовательской документации, а наша служба поддержки пользуется порталом Jira Service Management.

Считаю, что нет никаких оснований отказываться от этих продуктов. Более того, за последний год мы освоили процесс непрерывного тестирования качества кода нашего продукта с использованием SonarQube и Atlassian Bitbucket – смогли автоматизировать выгрузку и настроить анализ кода с помощью статей с Инфостарта.

В заключение хочу еще раз отметить, что возможности разработки мобильного приложения на платформе 1С с каждым годом все больше совершенствуются, а его публикация упрощается. Без ошибок платформы, конечно, не обходится, но мы все равно движемся вперед.

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

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

 

Вопросы и ответы

 

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

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

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

Как вы сравниваете между собой фото на поиск дублей и похожих фото?

Мы сравнивали фото по размеру файла и по метаинформации.

Вы сказали, что лицензии для приложения на мобильной платформе 1С стоили дороже, чем разрабатывать на других языках. Не дали ли обратную связь в фирму «1С», чтобы они пересмотрели свои аппетиты, придумали новую версию лицензии по этому поводу?

Нет, обратную связь мы не давали.

Там проблема была не в том, что заказчик испугался затрат на лицензии. У них просто возникла очередная идея организовать в приложении что-то типа Uber – чтобы абсолютно любой человек, который хочет стать мерчандайзером, мог установить это приложение, увидеть доступные к посещению точки на карте, откликнуться: «Я хочу сейчас здесь поработать» и пойти работать.

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

Вы сказали, что разрабатывали это приложение два года. Какой у вас был состав команды?

Состав у нас был небольшой. В первый год я была единственным разработчиком, и у нас был аналитик, который все это анализировал. Здесь мы решили не раздувать, чтобы видеть все проблемы здесь и сейчас.

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

Какая конфигурация была на серверной части?

Мы какое-то время выбирали конфигурацию, в итоге остановились на «Комплексной автоматизации».

Вы говорили, что нет возможности запретить сотрудникам установку приложений по подмене геопозиции. Рассматривали ли вы технологии MDM, Mobile Device Management, когда на телефоне создается рабочий профиль, который администрируется IT-департаментом сотрудника?

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

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

Да, я это запомню.

Вы сказали, что заказчик сейчас разработал для себя какое-то другое приложение. А бэк остался ваш?

К сожалению, у нас нет этой информации. Бэк остался у них. Я знаю, что после того, как мы ушли, они его еще долго использовали и дорабатывали. На текущий момент у нас нет информации, что у них происходит.

Вы упомянули, что что-то не получилось. Каких элементов управления вам не хватило в мобильном приложении 1С?

Во-первых, вы видели, как это выглядит: полосочки, серый фон, не очень красиво. Мы начинали разрабатывать приложение в 2018-м году, а тогда в мобильной платформе даже WebKit еще не было – только после перехода на WebKit все стало более-менее красивое.

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

Вы говорили, что передавали мерчандайзерам координаты точек на мобильное устройство. При этом использовалась интеграция с навигаторами – например, 2ГИС или другими?

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

Поэтому просто передавались координаты, а сотрудник уже сам решал, как ему туда ехать.

Вы еще говорили, что контролировали координаты сотрудников – вы их постоянно собирали, когда он выполняет задание?

В момент чекина он обязательно должен передать свои текущие координаты – и их корректность уже проверялись на сервере. Поэтому в момент чекина связь должна была быть обязательно – таким было условие.

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.