Az egyik tweet azt kérdezte, miért tarthat napokig a leiratkozás. Csatold be szorosan, mindjárt elmondom hihetetlen a történet arról, hogyan történik ez az Enterprise Development™-ben...
Egy bank van. Valószínűleg hallott már róla, és ha az Egyesült Királyságban él, 10% az esélye, hogy Ön bank. Ott dolgoztam „tanácsadóként”, kiváló fizetésért.
A bank marketing leveleket küld. Minden e-mail láblécében található egy kis „leiratkozás” link. Az emberek néha rákattintanak ezekre a linkekre.
A hivatkozásra kattintva egy őskori webszerver megpörög valahol a bankban. Őszintén szólva három hétbe telt, mire megtaláltam.
Ez a szolgáltatás minden alkalommal e-mailt küld a belső postaládájába, amikor egy hivatkozásra kattintanak. Ez naponta több százszor megtörténik.
Korábban ezeket a leveleket egy konkrét alkalmazottnak küldték, de öt éve távozott.
Most a levelet továbbítják a terjesztési csoportnak. Nem tudták megváltoztatni a címzett címét, mert az keménykódolt volt, és nem találták meg a forráskódot a szolgáltatásból. A szolgáltatás Java 6-ban íródott.
A levelezőcsoportba tartozó leveleket a bank Hyderabadban (India) működő offshore központjának két alkalmazottja ellenőrzi. Keményen dolgoznak és teljesítik feladataikat fantasztikus, de a fenébe, ez a munka elviselhetetlen.
Videókonferencián keresztül kommunikáltam velük, és a vállalati poszttraumás szindróma minden jele megvolt rajtuk. Megküzdöttek ezzel a hülyeséggel éveken át és ez idő alatt semmi nem változott.
Levél érkezésekor egy SQL parancsfájlt kell végrehajtaniuk, amely meghatározza, hogy a leiratkozott cím a banki klienshez tartozik-e (akkor az egyik protokoll) vagy sem (akkor másik).
Ha a címzett ügyfél, akkor egy másik SQL-szkriptet kell futtatnia, amely frissíti az ügyfélrekordot az ETL előtti környezetben. Minden változtatást londoni idő szerint 16:00-kor egy külön csapat vizsgál át Skóciában. Ha a változtatások átmennek az ellenőrzésen, a rendszer alkalmazza őket a valódi adatbázisra egy másik napon 16:00 órakor.
Ha a címzett nem ügyfél, hozzáadja egy Excel-táblázathoz, és hazautazás előtt elküldi a swindoni marketingcsapatnak.
A marketing csapat tealevelek és egyéb okkult gyakorlatok segítségével megállapítja, hogy az ügyfél „potenciálisan jelentős-e” (amire a belső szabályozás szerint „legfeljebb 48 óra”). Ha nem, akkor a címet hozzáadja egy másik táblához, és visszaküldi Indiába egy másik SQL-lekérdezés végrehajtásához.
Ha a marketing egy ügyfelet „jelentősnek” minősített, akkor manuálisan egy levelet küldenek neki: „Biztosan le szeretne iratkozni?” Úgy tűnik, hogy automatikusan generálódik, de valójában nem az.
Ha igennel válaszolnak (eleinte nagybetűvel kellett IGEN-t írni), akkor a swindoni csapat Indiába küldi őket. harmadik táblázatot, és ott ünnepélyesen végrehajtják a következő szkriptet.
Ha jól emlékszem, átlagosan tart négy munkanap. Naponta átlagosan körülbelül 700 ember iratkozik le, ennek 70%-a „potenciálisan jelentős”.
Egyébként ez a két indián átigazolt a fejlesztőcsapatunkhoz, és PM-ek lettek annak a rendszernek, amely ezt a sok hülyeséget felváltotta. Ők voltak a legkedvesebb, legegyüttérzőbb és legszorgalmasabb emberek, akikkel volt szerencsém együtt dolgozni. Nekik köszönhető, hogy ez a rémálom vállalati folyamat ilyen „zökkenőmentesen” működött ezekben az években. Később Angliába költöztek, és egyikük ma már 40+ alkalmazottat foglalkoztató részleget vezet.
A fordító megjegyzése: bagoly a KDPV-n - .
Forrás: will.com