{"id":7016,"title":"\u0423\u0433\u0430\u0434\u0430\u0439\u0442\u0435 \u0433\u043e\u0440\u043e\u0434\u0430 \u043f\u043e \u0437\u0432\u0443\u043a\u0443 \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u044e\u0449\u0435\u0433\u043e\u0441\u044f \u043f\u0438\u0432\u0430 \u0438 \u043f\u0435\u043d\u0438\u044e \u043a\u0438\u0442\u043e\u0432","url":"\/redirect?component=advertising&id=7016&url=https:\/\/vc.ru\/special\/sound&placeBit=1&hash=6ca24c77fedb0a01bd41595a6fbd498b5375a294c2e3b54a129aa318671b77a3","isPaidAndBannersEnabled":false}
Сервисы
Lamoda

Как мы решили комплексные проблемы склада Lamoda всего одним приложением

Один из основных способов взаимодействия сотрудников склада Lamoda с системой WMS (Warehouse Management System) — считывание штрихкодов сканером с мобильным приложением. Совсем недавно мы разработали новое внутреннее приложение для сканеров, а сам переход постарались сделать комфортным для пользователей. В итоге старая система отправилась в музей, а новую активно используют сотрудники.

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

Склад Lamoda — это 40 000 квадратных метров, где хранятся 10 миллионов товаров. Каждый день на смену выходит более 500 сотрудников, которые отправляют и пакуют около 200 000 товаров. Работа кипит круглые сутки, а единственный выходной в году — 1 января.

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

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

Почему мы отказались от старого приложения

Старая версия приложения для сканеров Lamoda была реализована в 2012 году и с тех пор принципиально не менялась. Как говорится: если работает — не трогай. Вот и не трогали ее практически 10 лет.

За это время технологии сильно устарели. Например, JavaServer Faces еще 10 лет назад казался оптимальным фреймворком, который сохраняет равновесие между функциональностью и скоростью. Сегодня новые разработчики его не изучают — есть куда более современные, удобные и функциональные фреймворки. А найти специалистов, которые разбираются в технических «динозаврах» на высоком уровне, практически нереально.

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

Алексей Баранов
системный архитектор в команде разработки склада

Разработка новой системы была неизбежна. В планах Lamoda — открытие второго склада, что влечет за собой новые технические требования. Баги старой системы требовали «костылей» и надстроек, которые еще больше ее утяжеляли. Да и править что-либо во фреймворке, в котором почти не разбираешься — плохая идея. Было проще и выгоднее создать новую современную систему, основанную на актуальном стеке технологий, чем пытаться допиливать морально и технически устаревшую программу.

Все, создаем новую систему: как это было

Первое и самое главное изменение — мы перешли с Java и «костылей» веб-технологий на Kotlin и Android-приложение. Это самое логичное решение, потому что в работе склада мы используем сканеры на базе Android.

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

Сканер в действии

Сканер — это специфический смартфон на Android. Вместо камеры встроен сканер, а стандартная батарея заменена промышленной — ее хватает на 12 часов непрерывной работы устройства.

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

Концерн Google, который контролирует всю экосистему Android, рекомендует использовать Kotlin при разработке Android-приложений. С этим языком мы раньше не работали, но возможности и плюсы явно перевешивали. В дальнейшем не пожалели об этом решении ни на секунду.

Разработка сразу пошла быстрее, чем на Java. По субъективным ощущениям — примерно в 1,5–2 раза.

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

Сканер на руке сборщика

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

Мы были очень удивлены, когда узнали, что у нас работают супергерои, которые способны сканировать по 5 товаров в секунду — 0,2 секунды на один товар. Это практически вплотную подбирается к техническим возможностям сканера.

Изначально мы не планировали настолько сильно улучшать скорость отклика. Но 5 товаров в секунду — это очень сильно. Мы до сих пор не представляем, как это возможно в реальной работе. Чтобы лишь примерно повторить такую скорость при тестировании, нам приходилось просто класть коды товаров рядом и «пролетать» по ним сканером.

Такие улучшения в скорости отклика требовали и изменений в функциональности. Настолько быстрая работа не позволяет обращать внимание на визуальные оповещения на сканере. Опытные сотрудники склада на экран не смотрят вовсе.

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

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

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

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

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

Как все работает сейчас и планы на будущее складского приложения Lamoda

С внедрением нового приложения процессы работы изменились.... никак. Абсолютно.

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

Это было стартовое требование, заложенное в самом начале разработки. Сейчас с программой работает более 500 человек в сумме и около 200 одномоментно. И они даже не почувствовали, что что-то поменялось. KPI остался на прежнем уровне. Разве что стало удобнее из-за новых видов оповещений и ускоренного отклика.

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

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

Возможность автономной работы сканера снижает важность стабильной интернет-связи. По сути хороший сигнал нужен только в ключевых точках, а не по всему складу. Устройство накапливает отсканированные товары и отправляет на облако пулом данных, когда находит сеть. Для этого подойдет протокол JSON-RPC Over HTTP.

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

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

И если бета-версию приложения мы старались сделать внешне похожей на старую, то сейчас, когда все работает стабильно, мы приступаем к улучшению UI и UX. Целей сразу несколько:

  • Сделать работу со сканером максимально интуитивно понятной. Это позволит новым сотрудникам обучаться всем особенностям работы с системой на протяжении нескольких дней.
  • Упростить ряд часто используемых процессов (сборка заказов, размещение товаров), сделать их более быстрыми и простыми.
  • Добавить абсолютно новые фичи. Например, меню, основанное на участке пользования, чтобы сотруднику не приходилось долго искать свой участок для сборки или размещения товаров. Всего таких участков 5, и каждый размером с футбольное поле, где много-много полок, в которых легко заблудиться. Таким образом, система сама проведет расчет и построит максимально короткий путь — уже только с этой фичей мы планируем снизить затраты времени на поиск участка минимум на 15–20%.

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

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

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

Интересно, что масштабировать систему будет элементарно. Фактически она уже готова к использованию на новом складе в Софьино.

Краткая выжимка опыта разработки складской системы Lamoda

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

  1. Даже идеально откалиброванная система потребует полной переделки через 10 лет. Просто потому что технологии и инструменты разработки не стоят на месте, а активно развиваются. Когда мы завершили создание старой системы в 2012 году, про Kotlin слышали только его создатели, а сейчас это топовый язык для написания Android-приложений.
  2. Не стоит бояться использовать актуальные технологии, которыми вы не владеете. Ни один из наших разработчиков не использовал Kotlin ранее. Во всем приходилось разбираться по ходу дела. Но результат получился отличным.
  3. Использование всех технических возможностей устройств. Наша предыдущая версия системы складского учета не использовала даже половины возможностей сканеров. В новой мы реализовали ряд фич, о которых раньше могли только мечтать: оповещения вибрацией и звуком или время отклика сканера меньше 0,2 секунды.
  4. Не стоит недооценивать своих сотрудников. Если честно, мы не ожидали, что среди работников склада есть супергерои, которые сканируют по 5 товаров в секунду. Из-за этого пришлось совершенствовать систему на ходу.
  5. Простота и интуитивность приложения. В идеале сотрудник, который впервые видит сканер, должен научиться им пользоваться уже в первый рабочий день.
  6. Четкое разграничение функций на обязательные, второстепенные и полезные. К обязательным относятся базовые функции склада: размещение товара, компоновка заказов, учет полок и наименований. К второстепенным — все более редкие, но нужные, вроде кросс-докинга и поиска пропавших товаров. К просто полезным — все остальные, которые улучшают работу, но не влияют на основную функциональность.
  7. UX и UI крайне важны, но только когда базовая функциональность работает как часы. Мы приступили к улучшению пользовательского опыта только после длительных тестов новой системы. До этого мы просто скопировали интерфейс со старой версии. И только сейчас, спустя полгода тестов, начинаем его улучшать.
  8. Необязательно нанимать новых разработчиков — все возможно и своими силами. Разработкой нашего приложения занимались два специалиста на фуллтайм примерно год. Время от времени мы привлекали сторонних специалистов, но не закладывали на это чрезмерные бюджеты.

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

{ "author_name": "Lamoda", "author_type": "editor", "tags": [], "comments": 59, "likes": 66, "favorites": 121, "is_advertisement": false, "subsite_label": "services", "id": 276579, "is_wide": true, "is_ugc": false, "date": "Tue, 03 Aug 2021 11:00:19 +0300", "is_special": false }
0
59 комментариев
Популярные
По порядку
Написать комментарий...

 И они даже не почувствовали, что что-то поменялось. KPI остался на прежнем уровне.

Ну я даже не знаю. Улучшать систему спустя 10 лет и даже никак не поднять KPI? У вас технический директор зачем на работу ходит, можно узнать?

16

Зачем, зачем! За зарплатой и премией конечно же))

16

Вы правы в том, что KPI должен изменяться. На тот момент у нас было две задачи: сохранить качество проделанной работы и удобство использования программы сотрудниками. Как и описано в тексте: «в идеале сотрудник, который впервые видит сканер, должен научиться им пользоваться уже в первый рабочий день».

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

3

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

–5

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

21

Возможно KPI ушло в прибыль компании: варианта всегда два: 1. повысить нормативы работяг. 2. Больше платить при тех же нормативах :). В общем все отлично, просто диалоги про героев немного цинично звучат, им в подарок только повышение скорости считывания за 0,2 сек на товар и головняк на тестировании, тут прям хочется добавить из анекдота: ну и это ещё не все: теперь супер приз….😂👍. В остальном так и написано: переписали, и дальше планы, сокращать издержки на обслуживание, молодцы ! Единственный момент по поводу сроков, это мой опыт: у любого проекта есть косвенные затраты, поэтому последовательное тестирование функций (равно повышение стоимости накладных) в плане оптимального проекта не самый лучший сценарий.

1

спасибо, кэп

0

Так пора еще дальше смотреть - сразу на Dart переписывать, готовиться к Fuchsia

0

Предлагаешь по 10 товаров в секунду сканировать? Эффективный менеджер что ли?

9

Даже 6 товаров - это уже +20%.

0

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

1

Соня, Вы статью читали? Коробки в ряд ложатся и сканируются по 5 штук. Так и получается 0.2 сек. на коробку. Я так понимаю, быстрее пока софт не может.

0

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

Я так понимаю, быстрее пока софт не может.

Цитирую:
Это практически вплотную подбирается к техническим возможностям сканера. Изначально мы не планировали настолько сильно улучшать скорость отклика.

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

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

0

 им пришлось пробегать мимо коробок со сканером

Ну вы уж цитировали бы тогда статью, а не придумывали:
 нам приходилось просто класть коды товаров рядом и «пролетать» по ним сканером

Уж если раньше рабочие по 5 товаров в секунду сканировали, то уж новый-то софт можно было б оптимизировать на бОльшее количество.

0

Представляю задачу переписать мобилку для wms.
То что у вас не упала производительность на старте - это уже огонь, молодцы :)

1

Наверно измерения остались, а показатели должны вырасти, иначе зачем все затевать? 

0

Ахахаха, ну это у вас сарказм такой, конечно. Но, по ходу, вопрос оценили всерьез)))
5 (ска, 5!!!) сканирований в секунду, пхахахаха!!!
П*ц.
Они теперь послушают вас и сделают показатель на 3 в секунду базовым))

0

"Разработка сразу пошла быстрее, чем на Java. По субъективным ощущениям — примерно в 1,5–2 раза." - откровенная брехня.
Да синтаксис Kotlin более краток, есть своя реализация стримов. Но 70% времени разработчик тратит на понимание того, как его решение повлияет на работу системы, дизайн, чтение кода, понимание зависимостей, тестирования и т.д.

"Для этого подойдет протокол JSON-RPC Over HTTP." - вообще непонятно для чего такое тут писать. Транспорт в системе в обещем случае должен быть абстрагирован и что там гоняется под капотом интересовать должно максимум архитектора.
"Возможность автономной работы сканера снижает важность стабильной интернет-связи.
"По сути хороший сигнал нужен только в ключевых точках, а не по всему складу." А почему бы не натыкать вай фай точек? они же не стоят как-то дорого.
Конечно оффлайн работа нужна, но этому подходу 100 лет в обед.

даже в пиковых нагрузках как 500*5=2500 запросов в секунду, не такая уж и большая цифра. Тем более, что средняя скорее всего будет сильно меньше.
200 000 товаров, если по каждому товару отправляется даже по 100 сообщений(что завышено скорее всего на  порядок), то пик как раз и будет в ~2500 в секунду, реально с 200к товаров, апдейтов наверное 2-3млн.

Вся система in-house, клиенту можно выставить любой дубовый gateway, а внутри заиспользовать бинарные протоколы, которые вполне переваривают такие данные.
Кроме того оперативных данных не так много и заказы сделанные даже пол года назад, можно сложить в архив и забыть про них.

9

Какая в итоге основная wms на складе? С которой общаются терминалы. Тоже самописная?

5

Да, основная WMS тоже самописная :)

2

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

10

Вячеслав, это хорошая идея для следующего материала :)

4

Очень интересно будет почитать, напишите пожалуйста :)
У вендоров много всяких wms есть, но у крупных компаний часто самописка, хотелось бы знать почему так :)

2

Велосипеды, велосипеды.

0

Для таких больших компаний проще написать свое решение, реализующее все "хотелки". К тому же не сомневаюсь, что там работают разработчики не хуже чем те, которые пилят "отраслевые решения".

2

Конечно! Ведь никто до Ламоды системой управления палетам не занимался! Аналоговнет! Примерно как Яндекс сейчас пишет свою систему под +- то же самое))

2

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

0

Именно так и было. "ООО Купишуз" в начале пути полностью соответствовало своему названию и по форме, и по стратегии. Там просто неоткуда было взяться ERP и промышленным системам. Они бы тогда тупо никогда не запустились. А спустя Х лет проект по переезду на новую систему влёгкую может стать последним в карьере ПМа (и не только), который его возглавит.

Текущая WMS будет жить пока Ламода нормально относится к своему настоящему активу - команде, и пока будет сохраняться "преемственность" поколений разрабов в команде, без резких "команда WMS вышла из чата".

4

Я люблю Ламоду, удобно и выбор неплохой. Но пару косяков испортило впечатление.

Один раз не смог купить пуховик — на складе забыли приклеить qr-код. Никакого способа, кроме перезаказа не было, а пуховик был последним. 

Второй раз положил вещь со скидкой в корзину, а приехала она без скидки. Обратил на это внимание после покупки только. Поддержка не помогла. 

Ну и коробки от обуви у вас почти всегда раздраконенные в хлам. 

0

 Ну и коробки от обуви у вас почти всегда раздраконенные в хлам.

Зато на Котлине переписали сканеры. У Вас свои проблемы - у разработчиков свои.

6

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

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

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

Проверьте, пожалуйста, вашу почту, на которую оформляете заказы 😊

2

Ламода ИТ молодцы, как всегда. 

Пара комментариев все же есть.

Даже идеально откалиброванная система потребует полной переделки через 10 лет

Это решается через Application Lifecycle Management. С ним подобные вещи перейдут в разряд плановых бытовых процессов.

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

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

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

1

Назвать статью надо было "Как потратить 5 миллионов на зп двум разработчикам за год и нихрена по сути не изменить".

Лучше бы эти 5 млн премиями на склад закинули, хотя бы 1 месяц работники бы работали быстрее)

0

Вопрос про автономную работу сканеров - если часть времени сканер недоступен, то как потом происходит синхронизация остатков в реальном времени ?

0

Сейчас сканеры работают только онлайн. «Остатки» и прочее хранятся на уровне сервера

1

Да, про данные на сервере понятно.

Я имел ввиду синхронизацию данных после выхода сканера из офлайна.

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

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

1

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

1

Работник работает по заданию, если товар 1шт. и больше нет WMS не даст задание собрать 2 или 1 одному работнику и 1 другому. Особенно если адресное хранение. Система говорит не только что взять и в каком количестве, но и откуда, чтобы оптимизировать маршрут сборки по складу.

0

Почему бы и нет) В Беларуси на некоторых складах просто остаток в минус уходит)

0

на некоторых складах учет маркером на картонке ведут, это не показатель =)

1

Я не считаю это нормой, это просто пример насколько все может быть смешно)

0

Где можно посмотреть ваше приложение ?)

0

Исходниками поделиться не готовы

0

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

0

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

0

Про Котлин было странно. Ну типа в чем проблема на нем написать новое приложение было?

В штате точно есть разработчики которые на нем писали.

0

Пишут, что не было разрабов:
 С этим языком мы раньше не работали

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

0

Вот именно странно. Они делают приложения для доставки и ТД.

0

До этого у нас не было потребности в том, чтобы писать приложения на Kotlin. Поэтому в штате не было разработчиков, которые писали бы на этом языке. Когда мы поняли, что Kotlin для этой задачи подходит лучше всего — подтянули экспертизу. А нанимать новых котлинистов не было необходимости, так как основная разработка и поддержка ведется на Java :)

0

А мобильные приложения для клиентов и курьеров разве не на котлине пишите?

0

Да, на Kotlin, но этим занимаются другие отделы. Lamoda — большая компания. В рамках этой статьи речь идет о разработке именно склада.

0

Просто написано было, как будто в других отделах не было разработки на котлине. 

0

Комментарий удален

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

0

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

0

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

0

У нас есть полное покрытие сетью склада. Проблемы нет :)

0

видимо такая же проблема, как и внимательно прочитать текст, в котором написано что это покрытие уже есть)

0

Комментарий удален

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

0

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

0
Читать все 59 комментариев
Правительство обязало мессенджеры регистрировать пользователей по паспортным данным с марта 2022 года Статьи редакции

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

М.Видео обманул меня с предзаказом Apple Watch Series 7

Печали пост. Как только 8 октября открылся предзаказ на Apple Watch Series 7, поспешил на сайты apple.com, М.Видео и еще несколько маркетплейсов.

Как не попасть в карьерную ловушку тимлида: личный опыт

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

Как OTUS стал платформой для самореализации. История преподавателя

Наш преподаватель, специалист по Data Science, решил поделиться своей историей преподавания. Он рассказал, как пришел в эту сферу, с какими трудностями столкнулся на пути к преподаванию и что ему помогает. А еще поделился советами, как поддерживать внимание студентов и сделать занятия полезными и увлекательными.

«М.Видео» не привёз часть заказа и клиент не может ничего сделать уже несколько недель

TL;DR;
Заказал и оплатил 02 октября два товара в М.видео, в доставку 06 октября привезли один товар и не привезли сетевой фильтр. Три недели попыток хоть как-то решить проблему официально и неофициально безуспешны, за это время не было даже попытки позвонить например мне. Обращение без ответа, операторы врут, фильтра у меня нет, денег у меня…

Cloud CDN: что это такое, как устроено и кому нужно. Разбираем на примере бургеров

Cloud CDN — это сеть быстрой доставки статического контента в формате услуги облачного провайдера. Объяснить, как работает технология, проще всего на примере — сравнить Cloud CDN с популярным продуктом, который выглядит плюс-минус одинаково вне зависимости от того, заказали вы его в Москве, Питере или Нью-Йорке. Знакомьтесь: классический бургер.…

Исследование: сотрудники хотели бы иметь комнату отдыха, бесплатный сок, а работодатели уже готовы покупать ЗОЖ-снеки

Онлайн-сервис доставки продуктов и товаров СберМаркет и исследовательское агентство Research Me спросили сотрудников, как они хотели бы питаться в офисе и что в нем видеть. В опросе приняли участие более 1500 работающих людей по всей России. Сервис также спросил работодателей – В2В-клиентов СберМаркета: что они покупают в офис, что точно никогда…

Я устал жить на автомате и сделал бота в Telegram, который напоминает сколько мне осталось жить

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

Пример календаря жизни. @life_table_bot
ПСБ запустил личный кабинет для предпринимателей. Там можно следить онлайн за каждым своим терминалом

Сервис предоставляется бесплатно.

Реклама в газетах и CRM: как мы массово нанимаем синих воротничков в швейное производство

У нас в Кофтёнышах, 80% сотрудников — это производственный персонал: швеи, упаковщицы, мастера, а 20% — коммерческий и административный: дизайнеры, маркетологи, менеджеры интернет-магазина.

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

null