аналитика
Что делать, когда все ошиблись
Как мы внедряли новую систему, какие собрали ошибки и как всё исправили
Основная задача IT-департамента прямо сейчас — перевести весь CDEK со старой системы, которой уже почти 16 лет, на новую. Старая система называется ЭК-4, новая — ЭК-5. Изменения коснулись технической части и интерфейса.
Я расскажу, как мы начинали внедрять новую систему, какие собрали ошибки и как всё исправили.
Юлия Черепова
Я расскажу, как мы начинали внедрять новую систему, какие собрали ошибки и как всё исправили.
Юлия Черепова
Внедрение ЭК-5 на ПВЗ
Сначала новую систему внедряли на ПВЗ — маленьких отделениях, куда люди приносят и где забирают свои посылки. Сотрудник ПВЗ совмещает в себе несколько ролей: общается с клиентом, создает заказ, принимает груз от курьера/клиента, выполняет складские операции по приходу и расходу груза, отправляет груз, выдает груз курьеру/клиенту.
Всё это происходит в небольшом помещении офиса с диванчиком, водичкой и примерочной. Весь день такого пользователя проходит у монитора, он внимательно изучает всю информацию на экране.
Всё это происходит в небольшом помещении офиса с диванчиком, водичкой и примерочной. Весь день такого пользователя проходит у монитора, он внимательно изучает всю информацию на экране.
ПВЗ
За первый год мы перевели на ЭК-5 1200 офисов из 1500. Масштаб проблемы вскрылся, когда мы поехали внедрять ЭК-5 на крупном якоре в Барнауле. Мы догадывались, что ПВЗ и Якорь — разные сущности и интерфейс придется доработать. Успокаивала уверенность product owner'а. Но как вы догадываетесь, что-то пошло не так, иначе не было бы вот этой статьи.
Внедрение ЭК-5 на якорях
Якоря — большие склады, куда стекаются все посылки с ПВЗ и от курьеров. У нас 600 якорей — по одному почти в каждом городе.
С раннего утра и до поздней ночи на склады приезжают огромные фуры, которые нужно разгрузить, а затем загрузить в них другой груз. Главный пользователь на крупных складах — кладовщик, которому нужно разгрузить и загрузить такую машину за полчаса-час. Он практически не подходит к монитору и использует товарный сканер, как в супермаркете.
С раннего утра и до поздней ночи на склады приезжают огромные фуры, которые нужно разгрузить, а затем загрузить в них другой груз. Главный пользователь на крупных складах — кладовщик, которому нужно разгрузить и загрузить такую машину за полчаса-час. Он практически не подходит к монитору и использует товарный сканер, как в супермаркете.
Якорь
Основная задача системы — показать, что конкретный груз принят и показать, куда его нужно везти дальше. В какой документ он добавился и прочие детали ему не важны, так всю аналитическую работу за него выполняет специальный менеджер.
С новой системой мы приняли машину за четыре часа, когда в старой — на это уходил один час.
В чём мы просчитались
Функциональная разница ПВЗ и якорей
Основная функциональная потребность у сотрудников мелких и крупных ПВЗ — приход и расход груза, но нефункциональные требования совершенно отличаются:
- сотрудники ПВЗ постоянно смотрят на экран. Могут позволить себе более размеренный рабочий день, так как грузопоток гораздо меньше, чем на крупных складах, и им важно понимать в какой документ попал груз;
- кладовщики на якорях работают в 15 метрах от монитора и все что им нужно — быстро и чётко улавливать информацию принят груз или нет. Принят — понять, куда его отправить. Нет — понять, что с ним делать дальше.
«Сырой» интерфейс
Интерфейс рассчитан на работу одного пользователя
Чтобы быстрее принять машину, у кладовщиков на якоре должна быть возможность одновременно с разных компьютеров сканировать груз в один документ.
Непонятные ошибки
При каждой ошибке кладовщики бежали к монитору и искали ту, которая относится к их накладной. Ошибки выводились мелким шрифтом в логе и без номера накладной.
Непонятно, куда отправлять
Следующий офис выводился шрифтом, абсолютно нечитаемым с 10-15 метров.
Отсутствие консолидированной информации по приходу машин
Все заказы разбивались по разным документам и кладовщики не понимали, всё ли принято.
По итогам запуска завели около 30 тикетов. И мы сами не понимали, какая проблема основная — так много всего не работало.
Чтобы быстрее принять машину, у кладовщиков на якоре должна быть возможность одновременно с разных компьютеров сканировать груз в один документ.
Непонятные ошибки
При каждой ошибке кладовщики бежали к монитору и искали ту, которая относится к их накладной. Ошибки выводились мелким шрифтом в логе и без номера накладной.
Непонятно, куда отправлять
Следующий офис выводился шрифтом, абсолютно нечитаемым с 10-15 метров.
Отсутствие консолидированной информации по приходу машин
Все заказы разбивались по разным документам и кладовщики не понимали, всё ли принято.
По итогам запуска завели около 30 тикетов. И мы сами не понимали, какая проблема основная — так много всего не работало.
Причины проблем
И на этом месте опытный аналитик или UX-дизайнер, скорее всего, уже вынесет вердикт «явная проблема с выявлением требований». И будет прав.
Чтобы уложиться в срок, сначала привлекли аналитиков на аутсорсе. Ребята честно постарались вникнуть в работу системы, но, видимо, что-то не получилось. А потом на половине работ проект вернулся обратно в CDEK IT. Это сейчас в CDEK IT работает 40 аналитиков. В момент же проектирования новой системы их было 7 на 40 модулей.
Сбор и выявление требований ограничился интервьюированием бизнес-оунера — мы посчитали, что его экспертизы будет достаточно, ведь он сам когда-то начинал кладовщиком якоря.
Чтобы уложиться в срок, сначала привлекли аналитиков на аутсорсе. Ребята честно постарались вникнуть в работу системы, но, видимо, что-то не получилось. А потом на половине работ проект вернулся обратно в CDEK IT. Это сейчас в CDEK IT работает 40 аналитиков. В момент же проектирования новой системы их было 7 на 40 модулей.
Сбор и выявление требований ограничился интервьюированием бизнес-оунера — мы посчитали, что его экспертизы будет достаточно, ведь он сам когда-то начинал кладовщиком якоря.
Как исправляли ошибки
Нужно было срочно что-то делать. До конца года осталось меньше трёх месяцев, а мы собрали гору доработок и хотелок «с полей», которые необходимо реактивно разрабатывать, а потом еще тестить и внедрять.
Применили инструменты аналитика
Итоговые юзер стори звучали следующим образом
«Я, как сотрудник ПВЗ, хочу...»
«Я, как кладовщик якоря, хочу...»
«Я, как сотрудник ПВЗ, хочу...»
- иметь возможность сразу присвоить номер полки принятому грузоместу, чтобы не делать двойную работу в будущем, так как у меня небольшой склад и я сразу понимаю, куда нужно положить груз
- в течение дня сканировать все заказы в один интерфейс, чтобы не переключаться между экранами и понимать, какие заказы я обработала за свою смену
«Я, как кладовщик якоря, хочу...»
- понимать в какой город груз едет дальше и каким видом транспорта, чтобы верно распределить груз по соответствующим мешкам
- видеть результат выполнения операции (успешно оприходовано или нет) с расстояния 15 метров, чтобы сканировать груз не отходя от машины
- понимать сколько заказов мне нужно принять по данной отправке и сколько принято по факту, чтобы в случае отсутствия груза снять с себя ответственность
Улучшили атрибуты качества продукта
Первое, что изменили — увеличили количество пользователей, работающих в одном интерфейсе с одного до четырёх.
Работали «в полях» и подключили всю команду
Мы продолжали ездить в поля, писать требования для новой роли кладовщика, про которую раньше почему-то никто не думал, а ведь он основной, и якори обеспечивают 90% логистики.
А когда бизнес-оунер давил на сроки и ограниченность в ресурсах, то требования отстаивали не только аналитики, но и наш техлид, тестировщик и специалист по внедрению. Мы аргументировали, почему такой вариант удобнее предыдущего, рассказывали как на самом деле ведут себя с системой кладовщики. И это сработало.
Теперь кладовщик видел всё что он сканирует, понимал приходовалось грузоместо или нет. Если была ошибка, то ее было видно с другого конца склада, стало понятно и видно, куда груз должен ехать дальше, документы формировались автоматически и не нужно было ручками нажимать на кнопку «Сформировать документ!».
А когда бизнес-оунер давил на сроки и ограниченность в ресурсах, то требования отстаивали не только аналитики, но и наш техлид, тестировщик и специалист по внедрению. Мы аргументировали, почему такой вариант удобнее предыдущего, рассказывали как на самом деле ведут себя с системой кладовщики. И это сработало.
Теперь кладовщик видел всё что он сканирует, понимал приходовалось грузоместо или нет. Если была ошибка, то ее было видно с другого конца склада, стало понятно и видно, куда груз должен ехать дальше, документы формировались автоматически и не нужно было ручками нажимать на кнопку «Сформировать документ!».
Выводы
Мы успешно пилотировали систему в Барнауле и еще на 400 якорях. Осталось 200.
Когда мы получили этот вариант интерфейса, поняли, что он очень похож на интерфейс старой версии. Мы поняли, что система не только «старая», она еще и «опытная» — в ней собран опыт сотрудников последних 20 лет. Было весьма опрометчиво и непрофессионально не брать это в расчет на этапах проектирования системы.
А всем, кто проектирует большую систему хотим посоветовать:
Когда мы получили этот вариант интерфейса, поняли, что он очень похож на интерфейс старой версии. Мы поняли, что система не только «старая», она еще и «опытная» — в ней собран опыт сотрудников последних 20 лет. Было весьма опрометчиво и непрофессионально не брать это в расчет на этапах проектирования системы.
А всем, кто проектирует большую систему хотим посоветовать:
- переиспользуйте опыт старой системы
- составляйте портреты пользователей
- берите с собой в поля других членов команды
- трекайте метрики
- никому не верьте и всё проверяйте
Обязательно проводите время в полях и участвуйте в процессе как можно больше. Это должно стать одним из основных способов сбора требований
IT-департаменту в том виде, что он есть сейчас — с большим штатом аналитиков, тестировщиков, разработчиков и менеджеров, примерно три года. И всё это время мы очень быстро растём. Я не верю, что мы больше не будем ошибаться. Но в чём я точно не сомневаюсь — что каждая ошибка даёт ценный опыт и помогает избежать последующих.
- Автор — Юлия ЧереповаРуководитель проектов
Отдел разработки логистического блока информационных систем CDEK IT
