मेलिंग लिस्टमधून सदस्यत्व रद्द करण्यासाठी अनेक दिवस का लागतात?

एका ट्विटने विचारले की सदस्यता रद्द करण्यास "दिवस" ​​का लागू शकतात. घट्ट बांधा, मी तुम्हाला सांगणार आहे अविश्वसनीय एंटरप्राइझ डेव्हलपमेंटमध्ये ते कसे केले जाते याची कथा™...

एक बँक आहे. तुम्ही कदाचित त्याबद्दल ऐकले असेल, आणि जर तुम्ही यूकेमध्ये रहात असाल, तर 10% शक्यता आहे आपले बँक मी तेथे उत्कृष्ट पगारासाठी "सल्लागार" म्हणून काम केले.

बँक विपणन पत्र पाठवते. प्रत्येक ईमेलच्या फूटरमध्ये एक लहान "सदस्यता रद्द करा" लिंक आहे. लोक कधीकधी या लिंक्सवर क्लिक करतात.

लिंकवर क्लिक केल्याने एक प्रागैतिहासिक वेब सर्व्हर फिरतो कुठेतरी बँकेत प्रामाणिकपणे, त्याला शोधण्यासाठी मला तीन आठवडे लागले.

प्रत्येक वेळी लिंक क्लिक केल्यावर ही सेवा तुमच्या अंतर्गत इनबॉक्समध्ये ईमेल पाठवते. हे दिवसातून अनेक वेळा घडते.

पूर्वी ही पत्रे विशिष्ट कर्मचाऱ्याला पाठवली जायची, पण पाच वर्षांपूर्वी तो निघून गेला.

आता पत्र वितरण गटाकडे पाठवले आहे. त्यांना प्राप्तकर्त्याचा पत्ता बदलता आला नाही कारण तो हार्डकोड केलेला होता आणि त्यांना सेवेतील स्त्रोत कोड सापडला नाही. सेवा Java 6 मध्ये लिहिलेली आहे.

हैद्राबाद (भारतात) बँकेच्या ऑफशोअर सेंटरमधील दोन कर्मचार्‍यांनी मेलिंग ग्रुपमधील पत्रे तपासली आहेत. ते कठोर परिश्रम करतात आणि त्यांचे कार्य पूर्ण करतात छान, पण अरेरे, हे काम असह्य आहे.

मी त्यांच्याशी व्हिडिओ कॉन्फरन्सद्वारे संवाद साधला आणि त्यांच्यात एंटरप्राइझ-पोस्ट-ट्रॉमॅटिक सिंड्रोमची सर्व चिन्हे होती. त्यांनी हा मूर्खपणा लढवला वर्षानुवर्षे आणि या काळात काहीही नाही बदलले नाही.

जेव्हा एखादे पत्र येते, तेव्हा त्यांनी SQL स्क्रिप्ट कार्यान्वित करणे आवश्यक आहे जे निर्धारित करते की सदस्यत्व रद्द केलेला पत्ता बँक क्लायंटचा आहे की नाही (नंतर प्रोटोकॉल एक आहे) किंवा नाही (नंतर दुसरा).

प्राप्तकर्ता ग्राहक असल्यास, त्यांना दुसरी SQL स्क्रिप्ट चालवणे आवश्यक आहे जे पूर्व-ETL वातावरणात ग्राहक रेकॉर्ड अद्यतनित करते. स्कॉटलंडमधील एका वेगळ्या टीमद्वारे लंडनच्या वेळेनुसार 16:00 वाजता सर्व बदलांचे पुनरावलोकन केले जाते. बदल सत्यापन उत्तीर्ण झाल्यास, ते वास्तविक डेटाबेसवर लागू केले जातील दुसर्या दिवसात 16:00 वाजता.

प्राप्तकर्ता क्लायंट नसल्यास, ते ते एक्सेल स्प्रेडशीटमध्ये जोडतात आणि घरी जाण्यापूर्वी स्विंडनमधील मार्केटिंग टीमला पाठवतात.

मार्केटिंग टीम, चहाची पाने आणि इतर गूढ पद्धती वापरून, क्लायंट "संभाव्यतः लक्षणीय" आहे की नाही हे निर्धारित करते (ज्यासाठी, अंतर्गत नियमांनुसार, "48 तासांपर्यंत"). तो नसल्यास, पत्ता दुसर्‍या टेबलमध्ये जोडला जातो आणि दुसरी SQL क्वेरी कार्यान्वित करण्यासाठी भारतात परत पाठविला जातो.

जर मार्केटिंगने क्लायंटला "महत्त्वपूर्ण" म्हणून ओळखले असेल, तर त्यांना व्यक्तिचलितपणे "तुम्हाला खात्री आहे की तुम्ही सदस्यता रद्द करू इच्छिता?" असे पत्र पाठवले जाते. असे दिसते की ते आपोआप तयार झाले आहे, परंतु प्रत्यक्षात तसे नाही.

जर त्यांनी "होय" उत्तर दिले (सुरुवातीला मोठ्या अक्षरात "होय" लिहिणे आवश्यक होते), तर स्विंडनची टीम त्यांना भारतात पाठवते. तिसऱ्या टेबल आणि तेथे पुढील स्क्रिप्ट गंभीरपणे अंमलात आणली जाते.

जर मला योग्यरित्या आठवत असेल तर ते सरासरी घेते चार कामाचे दिवस. सरासरी, दररोज सुमारे 700 लोक सदस्यत्व रद्द करतात, त्यापैकी 70% "संभाव्यपणे लक्षणीय" आहेत.

तसे, हे दोन भारतीय आमच्या डेव्हलपमेंट टीममध्ये बदलले आणि या सर्व मूर्खपणाची जागा घेणार्‍या व्यवस्थेचे पंतप्रधान झाले. ते सर्वात दयाळू, दयाळू आणि मेहनती लोक होते ज्यांच्यासोबत काम करण्याचा मला आनंद झाला. हे त्यांचे आभार होते की ही भयानक कॉर्पोरेट प्रक्रिया इतकी वर्षे "सुरळीतपणे" कार्य करते. नंतर ते इंग्लंडला गेले आणि त्यांच्यापैकी एक आता 40+ कर्मचाऱ्यांसह एक विभाग चालवतो.

अनुवादकाची टीप: KDPV वर घुबड - योल.

स्त्रोत: www.habr.com