Viename tviteryje buvo klausiama, kodėl prenumeratos atsisakymas gali „užtrukti kelias dienas“. Tvirtai prisisekite, aš tau pasakysiu neįtikėtinas istorija apie tai, kaip tai daroma Enterprise Development™...
Yra vienas bankas. Tikriausiai esate apie tai girdėję, o jei gyvenate JK, yra 10 % tikimybė, kad tavo bankas. Ten dirbau „konsultantu“ už puikų atlyginimą.
Bankas siunčia rinkodaros laiškus. Kiekvieno el. laiško poraštėje yra nedidelė nuoroda „atsisakyti prenumeratos“. Žmonės kartais paspaudžia šias nuorodas.
Spustelėjus nuorodą vienas priešistorinis žiniatinklio serveris sukasi kažkur banke. Sąžiningai, man prireikė trijų savaičių, kol jį radau.
Ši paslauga siunčia el. laišką į jūsų vidinį gautųjų aplanką kiekvieną kartą, kai paspaudžiama nuoroda. Taip nutinka kelis šimtus kartų per dieną.
Anksčiau šie laiškai buvo siunčiami konkrečiam darbuotojui, tačiau prieš penkerius metus jis išėjo.
Dabar laiškas persiųstas platinimo grupei. Jie negalėjo pakeisti gavėjo adreso, nes jis buvo užkoduotas, ir jie negalėjo rasti šaltinio kodo iš paslaugos. Paslauga parašyta Java 6.
Laiškus siuntimo grupėje tikrina du banko ofšorinio centro Hyderabade (Indijoje) darbuotojai. Jie sunkiai dirba ir atlieka savo užduotis nuostabu, bet po velnių, šis darbas nepakeliamas.
Bendravau su jais per vaizdo konferenciją ir jie turėjo visus įmonės potrauminio sindromo požymius. Jie kovojo su šia nesąmonė per metus ir per šį laiką niekas nepasikeitė.
Kai gaunamas laiškas, jie turi vykdyti SQL scenarijų, kuris nustato, ar atsisakomas adresas priklauso banko klientui (tuomet protokolas yra vienas), ar ne (tada kitas).
Jei gavėjas yra klientas, jis turi paleisti kitą SQL scenarijų, kuris atnaujina kliento įrašą išankstinėje ETL aplinkoje. Visus pakeitimus 16:00 Londono laiku peržiūri atskira komanda Škotijoje. Jei pakeitimai bus patvirtinti, jie bus pritaikyti tikrajai duomenų bazei kitą dieną 16:00 val.
Jei gavėjas nėra klientas, jie prideda jį prie „Excel“ skaičiuoklės ir prieš išvykdami namo išsiunčia rinkodaros komandai Svindone.
Rinkodaros komanda, naudodama arbatos lapus ir kitas okultines praktikas, nustato, ar klientas yra „potencialiai reikšmingas“ (tam, pagal vidaus taisykles, „iki 48 valandų“). Jei ne, adresas įtraukiamas į kitą lentelę ir siunčiamas atgal į Indiją, kad būtų vykdoma kita SQL užklausa.
Jei rinkodara nustatė, kad klientas yra „reikšmingas“, jam rankiniu būdu išsiunčiamas laiškas, pvz., „Ar tikrai norite atsisakyti prenumeratos?“ Atrodo, kad jis sugeneruotas automatiškai, bet iš tikrųjų taip nėra.
Jei jie atsako „taip“ (iš pradžių reikėjo rašyti „TAIP“ didžiosiomis raidėmis), tada komanda iš Svindono siunčia juos į Indiją trečias lentelę ir ten iškilmingai vykdomas kitas scenarijus.
Jei gerai pamenu, tai trunka vidutiniškai keturios darbo dienos. Vidutiniškai per dieną prenumeratos atsisako apie 700 žmonių, iš kurių 70 % yra „potencialiai reikšmingi“.
Beje, šie du indai perėjo į mūsų kūrėjų komandą ir tapo sistemos, kuri pakeitė visas šias nesąmones, PM. Jie buvo maloniausi, gailestingiausi ir darbštiausi žmonės, su kuriais man teko dirbti. Būtent jų dėka šis košmariškas įmonės procesas veikė taip „sklandžiai“ visus šiuos metus. Vėliau jie persikėlė į Angliją, o vienas iš jų dabar vadovauja skyriui, kuriame dirba daugiau nei 40 darbuotojų.
Vertėjo pastaba: pelėda KDPV - .
Šaltinis: www.habr.com