Ένα tweet ρώτησε γιατί η κατάργηση της εγγραφής μπορεί να «διαρκέσει μέρες». Κουμπώστε σφιχτά, θα σας πω απίστευτος η ιστορία του πώς γίνεται στο Enterprise Development™...
Υπάρχει μία τράπεζα. Πιθανότατα το έχετε ακούσει και αν ζείτε στο Ηνωμένο Βασίλειο, υπάρχει 10% πιθανότητα να είναι δική σας τράπεζα. Δούλεψα εκεί ως «σύμβουλος» με εξαιρετικό μισθό.
Η τράπεζα στέλνει επιστολές μάρκετινγκ. Υπάρχει ένας μικρός σύνδεσμος «κατάργηση εγγραφής» στο υποσέλιδο κάθε email. Οι άνθρωποι μερικές φορές κάνουν κλικ σε αυτούς τους συνδέσμους.
Κάνοντας κλικ σε έναν σύνδεσμο προκαλείται περιστροφή ενός προϊστορικού διακομιστή ιστού κάπου στην ΤΡΑΠΕΖΑ. Ειλικρινά, μου πήρε τρεις εβδομάδες μόνο για να τον βρω.
Αυτή η υπηρεσία στέλνει ένα email στα εσωτερικά εισερχόμενά σας κάθε φορά που γίνεται κλικ σε έναν σύνδεσμο. Αυτό συμβαίνει αρκετές εκατοντάδες φορές την ημέρα.
Παλαιότερα οι επιστολές αυτές στάλθηκαν σε συγκεκριμένο υπάλληλο, αλλά πριν από πέντε χρόνια έφυγε.
Τώρα η επιστολή προωθείται στην ομάδα διανομής. Δεν μπορούσαν να αλλάξουν τη διεύθυνση του παραλήπτη επειδή ήταν κωδικοποιημένη και δεν μπορούσαν να βρουν τον πηγαίο κώδικα από την υπηρεσία. Η υπηρεσία είναι γραμμένη σε Java 6.
Οι επιστολές στην ομάδα αλληλογραφίας ελέγχονται από δύο υπαλλήλους του υπεράκτιου κέντρου της τράπεζας στο Hyderabad (στην Ινδία). Δουλεύουν σκληρά και ολοκληρώνουν τα καθήκοντά τους ofigenno, αλλά φτου, αυτό το έργο είναι ανυπόφορο.
Επικοινώνησα μαζί τους μέσω τηλεδιάσκεψης και είχαν όλα τα σημάδια του επιχειρηματικού-μετατραυματικού συνδρόμου. Πολέμησαν αυτή την ανοησία με τα χρόνια και σε αυτό το διάστημα τίποτα δεν έχει αλλάξει.
Όταν φθάνει ένα γράμμα, πρέπει να εκτελέσουν μια δέσμη ενεργειών SQL που καθορίζει εάν η διεύθυνση που καταργείται ανήκει στον πελάτη της τράπεζας (τότε το πρωτόκολλο είναι ένα) ή όχι (τότε άλλο).
Εάν ο παραλήπτης είναι πελάτης, πρέπει να εκτελέσει μια άλλη δέσμη ενεργειών SQL που ενημερώνει την εγγραφή πελάτη στο περιβάλλον πριν από το ETL. Όλες οι αλλαγές εξετάζονται στις 16:00 ώρα Λονδίνου από μια ξεχωριστή ομάδα στη Σκωτία. Εάν οι αλλαγές περάσουν την επαλήθευση, θα εφαρμοστούν στην πραγματική βάση δεδομένων σε μια άλλη μέρα στις 16:00.
Εάν ο παραλήπτης δεν είναι πελάτης, το προσθέτει σε ένα υπολογιστικό φύλλο του Excel και το στέλνει στην ομάδα μάρκετινγκ στο Swindon πριν πάει στο σπίτι.
Η ομάδα μάρκετινγκ, χρησιμοποιώντας φύλλα τσαγιού και άλλες απόκρυφες πρακτικές, καθορίζει εάν ο πελάτης είναι «δυνητικά σημαντικός» (για τον οποίο, σύμφωνα με τους εσωτερικούς κανονισμούς, «έως 48 ώρες»). Εάν δεν είναι, τότε η διεύθυνση προστίθεται σε άλλον πίνακα και αποστέλλεται πίσω στην Ινδία για να εκτελέσει ένα άλλο ερώτημα SQL.
Εάν το μάρκετινγκ έχει αναγνωρίσει έναν πελάτη ως "σημαντικό", του αποστέλλεται μη αυτόματα μια επιστολή όπως "Είστε βέβαιοι ότι θέλετε πραγματικά να καταργήσετε την εγγραφή σας;" Φαίνεται ότι δημιουργείται αυτόματα, αλλά στην πραγματικότητα δεν είναι.
Εάν απαντήσουν "ναι" (αρχικά ήταν απαραίτητο να γράψουν "ΝΑΙ" με κεφαλαία γράμματα), τότε η ομάδα από το Swindon τους στέλνει στην Ινδία τρίτος πίνακα και εκεί εκτελείται πανηγυρικά το επόμενο σενάριο.
Αν θυμάμαι καλά παίρνει κατά μέσο όρο τέσσερις εργάσιμες ημέρες. Κατά μέσο όρο, περίπου 700 άτομα διαγράφουν την εγγραφή τους την ημέρα, εκ των οποίων το 70% είναι «δυνητικά σημαντικό».
Παρεμπιπτόντως, αυτοί οι δύο Ινδοί μεταφέρθηκαν στην ομάδα ανάπτυξης μας και έγιναν PM για το σύστημα που αντικατέστησε όλες αυτές τις ανοησίες. Ήταν οι πιο ευγενικοί, οι πιο συμπονετικοί και εργατικοί άνθρωποι με τους οποίους είχα τη χαρά να συνεργαστώ. Χάρη σε αυτούς ήταν που αυτή η εφιαλτική εταιρική διαδικασία λειτούργησε τόσο «ομαλά» όλα αυτά τα χρόνια. Αργότερα μετακόμισαν στην Αγγλία και ένας από αυτούς τώρα διευθύνει ένα τμήμα με 40+ υπαλλήλους.
Σημείωση του μεταφραστή: κουκουβάγια στο KDPV - .
Πηγή: www.habr.com