In één tweet werd gevraagd waarom het afmelden ‘dagen kon duren’. Doe je gordel stevig om, ik ga het je vertellen ongelooflijk het verhaal van hoe het werkt in Enterprise Development™...
Er is één bank. Je hebt er waarschijnlijk wel eens van gehoord, en als je in Groot-Brittannië woont, is de kans 10% dat het zo is. uw bank. Ik werkte daar als “consultant” voor een uitstekend salaris.
De bank verstuurt marketingbrieven. Er is een kleine link ‘uitschrijven’ in de voettekst van elke e-mail. Mensen klikken soms op deze links.
Als u op een link klikt, gaat er een prehistorische webserver draaien ergens in de bank. Eerlijk gezegd kostte het me drie weken om hem te vinden.
Deze dienst stuurt elke keer dat er op een link wordt geklikt een e-mail naar uw interne inbox. Dit gebeurt honderden keren per dag.
Voorheen werden deze brieven naar een specifieke medewerker gestuurd, maar vijf jaar geleden is hij vertrokken.
Nu wordt de brief doorgestuurd naar de distributiegroep. Ze konden het adres van de ontvanger niet wijzigen omdat het hardgecodeerd was, en ze konden de broncode van de service niet vinden. De dienst is geschreven in Java 6.
Brieven in de mailinggroep worden gecontroleerd door twee medewerkers van het offshore-centrum van de bank in Hyderabad (in India). Ze werken hard en voltooien hun taken иенно, maar verdomd, dit werk is ondraaglijk.
Ik communiceerde met hen via een videoconferentie en ze vertoonden alle tekenen van een posttraumatisch ondernemingssyndroom. Zij hebben tegen deze onzin gevochten voor jaren en gedurende deze tijd niets is niet veranderd.
Wanneer er een brief binnenkomt, moeten ze een SQL-script uitvoeren dat bepaalt of het adres waarvan het abonnement wordt afgemeld, toebehoort aan de bankklant (dan is het protocol het ene) of niet (dan het andere).
Als de ontvanger een klant is, moet deze een ander SQL-script uitvoeren dat de klantrecord bijwerkt in de pre-ETL-omgeving. Alle wijzigingen worden om 16:00 uur Londense tijd beoordeeld door een afzonderlijk team in Schotland. Als de wijzigingen de verificatie doorstaan, worden ze toegepast op de echte database op een andere dag om 16:00 uur.
Als de ontvanger geen klant is, wordt deze aan een Excel-spreadsheet toegevoegd en naar het marketingteam in Swindon gestuurd voordat hij naar huis gaat.
Het marketingteam bepaalt met behulp van theebladeren en andere occulte praktijken of de cliënt ‘potentieel significant’ is (waarvoor, volgens interne regelgeving, ‘tot 48 uur’). Als dit niet het geval is, wordt het adres aan een andere tabel toegevoegd en teruggestuurd naar India om nog een SQL-query uit te voeren.
Als marketing een klant als ‘significant’ heeft geïdentificeerd, wordt er handmatig een brief gestuurd in de trant van ‘Weet je zeker dat je je echt wilt afmelden?’ Het lijkt alsof het automatisch wordt gegenereerd, maar dat is in werkelijkheid niet het geval.
Als ze “ja” antwoorden (aanvankelijk was het nodig om “JA” in hoofdletters te schrijven), dan stuurt het team uit Swindon ze naar India derde tabel en daar wordt het volgende script plechtig uitgevoerd.
Als ik het mij goed herinner, duurt het gemiddeld vier werkdagen. Gemiddeld schrijven ongeveer 700 mensen zich per dag af, waarvan 70% ‘potentieel belangrijk’ is.
Deze twee Indiërs stapten trouwens over naar ons ontwikkelingsteam en werden premier van het systeem dat al deze onzin verving. Zij waren de vriendelijkste, meest medelevende en hardwerkende mensen met wie ik heb mogen samenwerken. Het was aan hen te danken dat dit nachtmerrieachtige bedrijfsproces al die jaren zo “soepel” heeft gewerkt. Later zijn ze naar Engeland verhuisd en één van hen runt nu een afdeling met ruim 40 medewerkers.
Noot van de vertaler: uil op KDPV - .
Bron: www.habr.com