En tweet spurte hvorfor det å melde seg av kan «ta dager». Spenn fast, skal jeg fortelle deg utrolig historien om hvordan det gjøres i Enterprise Development™...
Det er én bank. Du har sikkert hørt om det, og hvis du bor i Storbritannia, er det 10 % sjanse for at det er din bank. Jeg jobbet der som "konsulent" for en utmerket lønn.
Banken sender ut markedsføringsbrev. Det er en liten "avslutt abonnement"-lenke i bunnteksten på hver e-post. Noen ganger klikker folk på disse koblingene.
Å klikke på en lenke får en forhistorisk webserver til å spinne et sted i banken. Ærlig talt, det tok meg tre uker bare å finne ham.
Denne tjenesten sender en e-post til din interne innboks hver gang en lenke klikkes. Dette skjer flere hundre ganger om dagen.
Tidligere ble disse brevene sendt til en bestemt ansatt, men for fem år siden sluttet han.
Nå sendes brevet videre til distribusjonsgruppen. De kunne ikke endre mottakerens adresse fordi den var hardkodet, og de kunne ikke finne kildekoden fra tjenesten. Tjenesten er skrevet i Java 6.
Brev i postgruppen blir sjekket av to ansatte ved bankens offshoresenter i Hyderabad (i India). De jobber hardt og fullfører oppgavene sine Rått, men pokker, dette arbeidet er uutholdelig.
Jeg kommuniserte med dem via videokonferanse, og de hadde alle tegn på bedrifts-posttraumatisk syndrom. De kjempet mot dette tullet i løpet av årene og i løpet av denne tiden ingenting har ikke endret seg.
Når et brev kommer, må de kjøre et SQL-skript som avgjør om adressen som avmeldes tilhører bankklienten (da er protokollen en) eller ikke (da en annen).
Hvis mottakeren er en kunde, må de kjøre et annet SQL-skript som oppdaterer kundeposten i pre-ETL-miljøet. Alle endringer blir gjennomgått klokken 16:00 London-tid av et eget team i Skottland. Hvis endringene passerer verifisering, vil de bli brukt på den virkelige databasen i en annen dag klokken 16:00.
Hvis mottakeren ikke er en klient, legger de det til et Excel-regneark og sender det til markedsføringsteamet i Swindon før de går hjem.
Markedsføringsteamet, ved hjelp av teblader og andre okkulte praksiser, avgjør om klienten er "potensielt betydelig" (som, i henhold til interne forskrifter, "opptil 48 timer"). Hvis den ikke er det, legges adressen til i en annen tabell og sendes tilbake til India for å utføre en annen SQL-spørring.
Hvis markedsføring har identifisert en klient som "betydelig", blir de manuelt sendt et brev som "Er du sikker på at du virkelig vil avslutte abonnementet?" Det ser ut som det genereres automatisk, men det er det faktisk ikke.
Hvis de svarer "ja" (i utgangspunktet var det nødvendig å skrive "JA" med store bokstaver), sender teamet fra Swindon dem til India tredje tabellen og der blir det neste skriptet høytidelig utført.
Husker jeg feil tar det i snitt fire arbeidsdager. I gjennomsnitt avslutter omtrent 700 personer per dag, hvorav 70 % er "potensielt betydelige".
Forresten, disse to indianerne gikk over til utviklingsteamet vårt og ble statsminister for systemet som erstattet alt dette tullet. De var de snilleste, mest medfølende og hardtarbeidende menneskene jeg har hatt gleden av å jobbe med. Det var takket være dem at denne marerittbedriftsprosessen fungerte så "jevnt" i alle disse årene. Senere flyttet de til England og en av dem driver nå en avdeling med 40+ ansatte.
Oversetterens notat: ugle på KDPV - .
Kilde: www.habr.com