On 12 Aug 2023 at 01:18:20 CEST, "Marcin Debowski" <a...@I...zoho.com>
wrote:

> On 2023-08-03, Maciej Łebkowski <m...@l...name> wrote:
> Pomysł, aby w danych kontaktowych akceptować zagraniczne numery a potem
> twierdzić, że są nieprawdziwe co de facto wymusza polskie to Twój, czy
> następców? :)

Oczywiście, że następców ;)

A tak bardziej serio: wydaje mi się, że istnieje duży chaos komunikacyjny
(potocznie zwany: ,,Agile") w organizacjach tej wielkości. Zespół IT
obsługujący obecnie te serwisy to pewnie jakieś 300-400 osób, rozsianych
po tuzinie większych i mniejszych zespołów.

Hipotetycznie:
Ktoś zauważył potrzebę dokładniejszej weryfikacji numerów, ale nie zastanowił
się nad migracją istniejących danych, które nie spełniają nowych norm. Taki
scenariusz wydaje mi się bardzo prawdopodobny.

Ale pomyłka to jedno. Brak obserwacji tego, co się dzieje potem na serwisie,
żeby tę pomyłkę zidentyfikować to drugie. A trzecie, czy gdyby komuś takiego
buga faktycznie zgłosić, to czy byłaby szansa na poprawę. Bo to też może
wymagać komitetu, współpracy pomiędzy zespołami o różnych priorytetach.

Któregoś razu *wewnętrznie* zgłosiłem problem dotyczący bookowania, czyli
głównego produktu firmy. Przez kolejne tygodnie, a potem miesiące, ticket
był odbijany pomiędzy kolejnymi osobami, spośród których żadna nie miała
nawet bladego pojęcia kto może skutecznie zdiagnozować problem.

Innym razem, jako użytkownik, wyszukałem *na mapie* lekarza w mojej okolicy.
Kliknąłem pinezkę oddaloną kilkaset metrów od mojego domu, następnie niebieski
guzik umawiania wizyty, wybrałem termin, etc. Ku mojemu zdziwieniu, okazało
się, że to był tylko ,,chłyt marketingowy" (albo błąd po prostu): lekarz
faktycznie pracował w tym miejscu, ale wizyty dostępne miał w innym mieście,
oddalonym o 300km notabene, a serwis chciał trochę ,,uprościć" proces ;)

Widziałem też sytuację, w której dodanie umówionej wizyty do kalendarza
(eg. import pliku .ical) miesza strefy czasowe i pokazuje ją o złej godzinie.
Myślę, że to dość kluczowa funkcja, żeby przypomnienie o wizycie nie kłamało.

Krótko: myślę, że większe grzechy mają na sumieniu ;)


> Plus kwiatki w stylu:
>
> [...snip...]
>
> To jest oczywiście filtrowanie po IP z kłamliwym komunikatem.


Prawdopodobnie, ale jak sam widzisz, to akurat komunikat CloudFronta,
ciężko byłoby oczekiwać sensownych i spójnych komunikatów od 3rd party.
Poza tym, z tego co rozumiem taka blokada nie jest z powodów ,,biznesowych"
jak np. często spotykane geo-blocki na europe z powodów GDRP, ale raczej
techniczna -- wycięcie nieobsługiwanych rynków dla zwiększenia bezpieczeństwa
być może? Ciężko mi spekulować, nie mam wystarczającej wiedzy na ten temat.

Robiłem za to blokowanie ,,back in the day", skierowanie przeciwko botom
scrapującym bazę. Nikt wtedy nie martwił się tym, co będzie widniało w
zablokowanych requestach. Nie miałbym zatem oczekiwań, że teraz, w tej
skali, ktoś będzie zastanawiał się takimi szczegółami.

Ludzie na górze ogarniają big picture (jakieś górnolotne mierniki typu
współczynniki konwersji, ilości bookingów, etc), a osoby na dole realizują
zlecone zadania, bez brania większej odpowiedzialności za efekt końcowy,
w tym tego typu szczegóły.

Such is life, I guess.

--
Winning popularity contests since '85