Comments 30
Спасибо за статью, очень интересно!
Планируется ли отказ от уведомлений через всякие в контакты, воцаппы и тп? Почему нельзя использовать традиционные каналы?
А традиционные каналы - это какие? И чем Вам watsapp не угодил, можете кейс написать?
Традиционные это те, которые я сам указал для связи. Но сдэк берёт и без спроса отправляет уведомление не на емейл, а на непонятный вконтакт. Хорошо, что я туда случайно зашёл и увидел
Я там таких блокирую и отправляю жалобу на спам.
А когда жду посылку, трекаю её в отдельном приложении.
У сдэка есть моя почта и телефон, но уведомления присылает только на email и в приложение. Вот только для авторизации в приложении через телефон прислали код в вайбер, а не смс, но это просто способ сэкономить.
Сейчас историю вайбера посмотрел - с июля 2022 года не получаю там уведомления о заказах. Может потому что приложение установлено тогда было?
Я бы уточнил - хотелось бы указать через что меня уведомлять, а не "через что нам удобнее, через то и уведомим".
Например, мне тоже удобнее не через VK получать уведомления, а, к примеру, как PUSH в приложение CDEK
Вы указали, что была по итогу создана подробная статья для стандартизации подходов. Есть возможность её опубликовать в открытом источнике и поделиться?
Опубликовать эту статью в открытом доступе вряд ли возможно.
Однако я сейчас, в том числе, работаю над тем, чтобы унифицировать подходы к работе с датой и временем в приложениях на Java, PHP и Python в компании (т.е. именно в контексте использования в логике сервисов, а не только обмена данными).
Уже сейчас понятно, что задача не тривиальная. Например, в PHP, кроме типа DateTimeImmutable, представляющего собой аналог ZonedDateTime в Java, отсутствуют типы локальных даты и времени, что усложняет расчеты. В Python, хотя и существуют типы date, time и datetime, но из-за необязательности указания таймзоны, работа с ними также иногда приводит к ошибкам.
Вообще, я заметил, что любая неоднозначность в трактовке, почти гарантированно приводит к ошибкам. Вот один из примеров, когда стандартное представление даты и времени со смещением все равно ведет к двусмысленности: 2024-03-21T19:56:30+05:00. Казалось бы, что может пойти не так? Но один из разработчиков воспринял дату и время слева от плюса как будто они указаны в нулевом смещении UTC (т.е. что смещение +5 часов нужно прибавить дополнительно), а другой, что дата и время уже указаны в смещении +5 часов (а это верный вариант).
Поэтому я мог бы написать статью на Хабре, о том, как вести расчеты с датой и временем (на всех трёх языках программирования), как хранить такие данные в БД PostgreSQL и MySQL и некоторых NoSQL базах данных: ElasticSearch, MongoDB. Ну и, конечно, привести примеры распространенных ошибок, которые совершают разработчики.
Как вам идея?
Вообще, я заметил, что любая неоднозначность в трактовке, почти гарантированно приводит к ошибкам. Вот один из примеров, когда стандартное представление даты и времени со смещением все равно ведет к двусмысленности:
2024-03-21T19:56:30+05:00. Казалось бы, что может пойти не так? Но один из разработчиков воспринял дату и время слева от плюса как будто они указаны в нулевом смещении UTC (т.е. что смещение +5 часов нужно прибавить дополнительно), а другой, что дата и время уже указаны в смещении +5 часов (а это верный вариант).
Ээээ… Мне кажется, это не проблема двухсмысленности. Уж “2024-03-21T19:56:30+05:00” трудно воспринять как-то по другому. Это нулевые знания конкретного разработчика в форматах времени-даты
Планируется ли в CDEK отказ от глупости предъявления паспорта при получении заказа и, вместо этого, подтверждение получения посылки через смс?
Опишу ситуацию: Сестра сделала заказ на сайте Максидома нескольких товаров и попросила его забрать меня. Доставка у них только через CDEK, оплата при получении, указывается имя заказавшего и мобильный номер телефона. На телефон приходит смс, что заказ прибыл в пункт CDEK. Кодов для получения, как в других сервисах доставки, у CDEK, почему-то нет.
Прихожу в пункт выдачи, называю номер заказа, собираюсь оплатить и забрать.
Говорят: давайте паспорт.
А смысл? ФИО у меня другое, чем у сестры. Говорю, давайте оплачу да пойду, или ей позвоните подтвердите, телефон указан в заказе.
Говорят: Нет, выдаем только по паспорту, правила компании. Или пусть она установит приложение, введет туда свои паспортные данные, там проверят, потом она сможет в приложении сгенерировать код, который сможет сообщить вам, и вы по этому коду сможете получить неоплаченный заказ из магазина. Занавес. Другие сервисы доставки сообщают в смс код получения или высылают его при получении в пункте выдачи.
Я бы понял, если бы это были личные документы, но извините, получать неоплаченный цветочный горшок по предъявлению паспорта и регистрации персональных данных в приложении - это "ту мач".
А как СДЭК должен узнать что сестра вам разрешила получать её посылку? Вдруг вы решили получить её посылку втайне от неё?
А откуда бы я узнал пункт выдачи и № заказа, который приходит ей в смс? И откуда я узнал бы код получения, если бы СДЭК отправлял его на имеющийся в заказе её номер телефона при получении в отделении СДЭК?
И еще раз повторю - это _неоплаченная_ посылка с _магазинными_ товарами из Maxidom, а не пакет с документами.
так же, как на той же Почте России сделано - оригинальному получателю присылается код подтверждения, он его сообщает тому, кто сейчас в отделении получает посылку и тем самым подтверждает, что ему разрешили забрать посылку.
Для этого правда надо сперва подключить ПочтаID (получение без паспорта) или как она там называется путём написания заявления, но и у CDEK для этого есть CDEK ID же
Да, только для CDEK ID надо сдать свои паспортные данные, которые будут храниться где-то в какой-то БД, и где им приделают ноги.
Но что мешает CDEK просто выслать Код получения в СМС по указанному в заказе номеру, если это банальная магазинная покупка? Ни Яндекс, ни Озон, ни Wildberries, ни Почта, ни прочие платформы не додумались до такой фигни с паспортами.
И да, от заказа пришлось отказаться, он отправился обратно в магазин. С таким сервисом и политикой, СДЕК походу лишится клиентов.
Ответ очевиден - так можно собрать больше информации. И плевать им на вашу безопасность.
Да, только для CDEK ID надо сдать свои паспортные данные
У Почты РФ аналогично, если что. По крайней мере, его проверяли в момент, когда я заявление писал. А вот писал ли я реально паспортные данные в заявлении не помню за давностью времён
Озвученный вами Ozon/Wildberries привязываются к вашему номеру телефона - да, не паспорт, но тоже кладётся "в какую-то БД".
И суть моего коммента выше была не в том, как привязаться (второй абзац), а в первом абзаце
Для оплаченных заказов, по-моему, тоже правила безопасности у CDEK странные. Ситуация: оплаченный заказ в интернет-магазине из соседнего города, доставка CDEK должна быть самой быстрой из возможных вариантов. Заказываю доставку в постамат, удобно для меня расположенный. Через несколько дней, судя по трекингу, заказ почти доехал до постамата, но "курьер не смог его доставить", и заказ уезжает в ПВЗ, который мне не удобен ни по расположению, ни по времени работы. Звоню в поддержку, объясняю ситуацию, оператор соглашается, что произошла какая-то ошибка и меняет место назначения снова на нужный мне постамат. И так, если не ошибаюсь, 7 (семь) раз. Т.е. каждый раз заказ якобы привозили в постамат, происходило что-то непредвиденное, и его упорно доставляли в ПВЗ. После моих звонков опять меняли пункт назначения на постамат и все повторялось. Почему так происходит, никто объяснить не мог. Никаких проблем, принципиально не позволяющих положить посылку в постамат (т.е. размер и содержимое), не было. Версии операторов были разные - постамат сломался, постамат вообще убрали, моя ошибка при оформлении, ошибка магазина при оформлении, курьер что-то перепутал (ага, 7 раз). Постамат все это время был доступен для выбора на сайте, если что. Оформлен заказ был правильно и отправлен магазином правильно. В конце концов, после примерно трех недель скитаний, когда срок хранения подходил к концу, оказалось, что лимит на изменение пункта доставки для заказа исчерпан и теперь ни в какой постамат доставлять не получится, только идти и забирать в ПВЗ. Т.е. да, мной-то никакие изменения не выполнялись, это проблемы СДЭК-а, но "к сожалению, по-другому никак". В весьма раздраженном настроении в выходной топаю в этот ПВЗ, в котором выясняется, что без внесения моих паспортных данных в их базу заказ мне не отдадут, потому что таковы правила для оплаченных заказов. Т.е. нужно не просто показать паспорт на месте, а именно сохранить паспортные данные. И это для заказа, который должен был быть получен в постамате по коду из сообщения и который так и не привезли в нужное место. Не только мне, кстати, не привезли, сотрудники ПВЗ сказали, что не в курсе проблемы с постаматом, но очень много заказов перенаправляют к ним. Мне проще и быстрее было самовывозом забрать из магазина, еще и бесплатно. В общем, понимаю, что мои паспортные данные уже есть в самых разных базах, но после стольких недель выяснений и часов общения с поддержкой (впервые в жизни все минуты по тарифу были израсходованы) впредь не хотелось вообще никак со СДЭК-ом пересекаться и тем более оставлять информацию о себе. Из магазина к тому времени уже звонили и спрашивали, почему не забираю, и были в курсе ситуации. В итоге без копирования паспорта заказ мне не отдали, он вернулся в магазин, а оттуда уже приехал курьер - в назначенное время и место, безо всяких проволочек.
Почему оплаченный заказ по регламенту можно положить в постамат и получить по коду, но нельзя по такому же коду выдать в ПВЗ - большой вопрос.
Планируется ли в CDEK отказ от глупости предъявления паспорта при получении заказа и, вместо этого, подтверждение получения посылки через смс?
Так СDEK ID же. Регистрируетесь, после этого можно получать посылку называя номер и код. Я уже забыл когда последний раз паспорт показывал в сдеке
Лично я иногда показываю - в некоторых магазинах/маркетах использую не основной номер телефона, а при оформлении заказа нельзя указать иного получателя. В итоге, заказ не привязывается в моему CDEK ID, так как привязаться может только по номеру телефона, а не по паспортным данным. А в отделении паспорт показываешь и получаешь такой заказ :)
Никто не любит стандарты - ни пользователи, ни продажники, ни поддержка, ни программисты, особенно когда уже что то накриативили. Хороший пример с +7 и 8, особенно когда номер используется как логин.
Мне довелось участвовать в интернациализации телефонии одного продукта , так на это ушло года 3 в 3 или 4 релизах; и хотя требование о её введении было с самого верха нашей конторы, практически все пытались откосить от участия - внедрения. БД забита старыми номерами, пользователям неудобны номера с плюсом, операторы не поддерживают международную нумерацию (хотя сами могут прислать звонок в таком формате), какая то библиотека не парсит +, клиент имеет базу номеров с 8, тестеры не знают как сгенерировать номерной план, часть клиентов вообще не хочет что то у себя менять. Поддержка требует сделать чтобы нормально работало как раньше, продажники её поддерживают и эскалируют в менеджмент, тот их тоже поддерживает, пока не вспоминает про требование трёхлетней давности. Телефонисты предлагают сделать всё на их сисках и больше ничего не ломать.
Поэтому да - стандартов следует придерживаться изначально при выработке требований и спецификаций, и чтобы это проходило быстрей и мягче, кому то изначально хорошо бы их изучать и суммировать в мурзилке по внедрению.
Абсолютно согласен, что идеальный вариант, когда стандарты приняты до реализации бизнес‑процесса или хотя бы начала разработки. Но такое редко случается. Обычно выработка единого подхода происходит, когда уже накоплено определенное количество ошибок и явных проблем с текущими решениями (ну то есть когда уже всем очевидно, что что‑то идёт не так). И поэтому стандарты приходится внедрять в уже существующие процессы. А это всегда больно.
Понятно, что к формулировке стандарта нужно подходить очень аккуратно, чтобы не навредить. Не нужно подходить к стандартизации с точки зрения «у вас тут не красиво/не правильно», обязательно нужно взвешивать плюсы и минусы принимаемых решений и четко понимать их необходимость, решаемые задачи и отрицательный эффект (который нужно постараться минимизировать). Стандарты должны быть спроектированы так, чтобы быть удобными тем, кто их использует (включая клиентов, пользователей системы, менеджеров и технических специалистов). Это сделать не просто, но, в принципе, возможно. Для этого важно собрать качественную обратную связь от всех заинтересованных.
Я придерживаюсь такого подхода: выявление проблемы, поиск вариантов её решения (такого, чтобы постараться учесть все накопленные ошибки), обсуждение с заинтересованными лицами (с теми, на кого стандарт повлияет), а затем внедрение (вот это самое сложное и я полностью понимаю боли, которые вы озвучили во втором абзаце, про интернационализацию телефонии). Причем, если нет общего стандарта для индустрии (например ISO), то я стараюсь выбрать лучший вариант из существующих в компании решений (желательно, наиболее эффективный, но в крайнем случае подойдет и общеиспользуемый) и разрабатывать требования на его основе.
Ну а что касается нелюбви к стандартам, то здесь, на мой взгляд, корень проблемы только в том, что неудобно это обычно тем, на кого неожиданно сваливается дополнительная работа. И это, по моему опыту, хорошо решается озвучиванием проблем, которые имеются, задач, которые решаются с помощью стандарта и перечисление плюсов, которые мы получим в итоге. А нелюбовь уходит, как только начинают использоваться очевидные, однозначные подходы, основанные на выверенных и понятных стандартах.
Честно говоря, с учетом специфики работы компании СДЭК с данными клиентов, эта статья кажется форменным издевательством.
Ваш комментарий не похож на начало конструктивного диалога, но тем не менее, я попытаюсь ответить, поскольку максимально серьезно отношусь к этой проблеме.
Первое, что хотелось бы сказать, что это не специфика работы компании CDEK. Например в 2022–2023 годах в России зафиксировано более 400 случаев yтечек из многих компаний, в том числе и банковского сектора, который, казалось бы, не должен вообще допускать такого. Во‑вторых, я считаю, что систему характеризует не факт ошибки, а реакция на неё. Мы проанализировали и свой кейс и проблемы наших коллег по индустрии, сделали соответствующие выводы и приняли соответствующие решения. Сейчас мы ежедневно работаем, в том числе над тем, чтобы максимально снизить вероятность таких событий в будущем.
В сумме с выдачей по паспорту и навязыванием СДЭК id выглядит как двойное издевательство и лицемерие.
И не надо рассказывать про защиту пользователей - давно существуют одноразовые ключи, 2FA, криптография - и всё без дополнительного сбора персональной информации (которая утекает террористам) и навязывания ненужных экосистем.
Так что анти человеческие практики применяются вашей компанией целенаправленно. Зачем клиентам при получении какой-то фигни увеличивать базу, которая будет передана террористам - непонятно.
Вывод напрашивается очевидный - не пользоваться услугами и максимально бойкотировать использование вашей компании.
Хорошо, что закон про оборотные штрафы приняли, но мне лично кажется, что в случае таких массовых сливов или какое-то звено руководства работает с террористами, или административной ответственности категорически недостаточно.
Согласен полностью с вами, вообще если уж углубляться то в чём смысл? Куча транспортных компаний и так нормально работает и получателей не путает. Ну вот в тех же Деловых линиях подобного нет и вполне удобно. Лучше бы на оборудование и логистику такие усилия направили
Деловые линии требуют документ удостоверяющий личность.
Во всех случаях необходим – документ, удостоверяющий личность непосредственно получающего груз лица.
С учётом печальной ситуации, которая произошла в CDEK, Ваши ответы звучали, как из другой Вселенной или о другой компании.
Это не злорадство. В моих словах некоторый страх.
27.05.2024, 10:57 В работе СДЭК произошел крупный сбой
Клиенты СДЭК больше суток не могут получить и отправить посылки. В работе сервиса произошел сбой из-за технических проблем. В компании заявили РБК, что не обрабатывают заказы в ручном режиме во избежание ошибок.
О приостановке обработки заказов СДЭК сообщил вчера, 26 мая, пообещав, что 27 мая его пункты выдачи заказов продолжат работу в штатном режиме. С чем связан сбой, неизвестно. На момент написания новости сайт СДЭК все еще не работал — на его главной странице отображается уведомление «Ведутся технические работы».
«Мы активно заняты решением возникшей ситуации и находимся на заключительном этапе ее исправления. С завтрашнего дня работа наших пунктов выдачи заказов уже будет восстановлена, и мы продолжим нашу работу в штатном режиме»,— заверили в компании.
Что-то долго восстанавливают - и до бэкапов добрались злыдни?
От хаоса к порядку. Как мы внедряем стандарты в CDEK