মেইলিং লিস্ট থেকে আনসাবস্ক্রাইব করতে বেশ কয়েক দিন লাগে কেন?

একটি টুইট জিজ্ঞাসা করেছিল কেন সদস্যতা ত্যাগ করতে "দিন সময় লাগতে পারে।" আঁটসাঁট বাঁধা, আমি আপনাকে বলতে যাচ্ছি অবিশ্বাস্য এন্টারপ্রাইজ ডেভেলপমেন্ট™ এ কীভাবে এটি করা হয়েছে তার গল্প...

একটি ব্যাংক আছে। আপনি সম্ভবত এটি শুনেছেন, এবং আপনি যদি যুক্তরাজ্যে থাকেন তবে 10% সম্ভাবনা রয়েছে তোমার ব্যাংক. আমি সেখানে একটি চমৎকার বেতনের জন্য "পরামর্শদাতা" হিসাবে কাজ করেছি।

ব্যাংক বিপণন চিঠি পাঠায়. প্রতিটি ইমেলের ফুটারে একটি ছোট "আনসাবস্ক্রাইব" লিঙ্ক রয়েছে। লোকেরা মাঝে মাঝে এই লিঙ্কগুলিতে ক্লিক করে।

একটি লিঙ্কে ক্লিক করার ফলে একটি প্রাগৈতিহাসিক ওয়েব সার্ভার ঘুরতে থাকে কোথাও ব্যাংক. সত্যি বলতে, তাকে খুঁজে পেতে আমার তিন সপ্তাহ লেগেছে।

প্রতিবার একটি লিঙ্ক ক্লিক করার সময় এই পরিষেবাটি আপনার অভ্যন্তরীণ ইনবক্সে একটি ইমেল পাঠায়। এটি দিনে কয়েকশ বার ঘটে।

পূর্বে, এই চিঠিগুলি একটি নির্দিষ্ট কর্মচারীকে পাঠানো হয়েছিল, তবে পাঁচ বছর আগে তিনি চলে যান।

এখন চিঠিটি বিতরণ গ্রুপে পাঠানো হয়। তারা প্রাপকের ঠিকানা পরিবর্তন করতে পারেনি কারণ এটি হার্ডকোড করা ছিল এবং তারা পরিষেবা থেকে সোর্স কোড খুঁজে পায়নি। পরিষেবাটি জাভা 6 এ লেখা আছে।

মেইলিং গ্রুপের চিঠিগুলি হায়দ্রাবাদে (ভারতে) ব্যাঙ্কের অফশোর সেন্টারের দুই কর্মচারী চেক করেন। তারা কঠোর পরিশ্রম করে এবং তাদের কাজগুলি সম্পূর্ণ করে অসাধারণ, কিন্তু অভিশাপ, এই কাজ অসহ্য.

আমি তাদের সাথে ভিডিও কনফারেন্সের মাধ্যমে যোগাযোগ করেছি এবং তাদের মধ্যে এন্টারপ্রাইজ-পোস্ট-ট্রমাটিক সিন্ড্রোমের সমস্ত লক্ষণ ছিল। তারা এই ফালতু লড়াই করেছে বছরের পর বছর ধরে এবং এই সময়ে কিছু না পরিবর্তন হয়নি।

যখন একটি চিঠি আসে, তখন তাদের অবশ্যই একটি SQL স্ক্রিপ্ট চালাতে হবে যা নির্ধারণ করে যে ঠিকানাটি ব্যাংক ক্লায়েন্টের (তখন প্রোটোকল একটি) বা না (তারপর অন্য)।

প্রাপক একজন গ্রাহক হলে, তাদের অন্য একটি SQL স্ক্রিপ্ট চালাতে হবে যা প্রাক-ETL পরিবেশে গ্রাহকের রেকর্ড আপডেট করে। লন্ডনের সময় 16:00 এ সমস্ত পরিবর্তনগুলি স্কটল্যান্ডের একটি পৃথক দল দ্বারা পর্যালোচনা করা হয়। যদি পরিবর্তনগুলি যাচাইকরণ পাস করে, তবে সেগুলি বাস্তব ডাটাবেসে প্রয়োগ করা হবে অন্য দিনে 16:00 এ।

প্রাপক ক্লায়েন্ট না হলে, তারা এটিকে একটি এক্সেল স্প্রেডশীটে যোগ করে এবং বাড়িতে যাওয়ার আগে সুইন্ডনের মার্কেটিং টিমের কাছে পাঠায়।

বিপণন দল, চা পাতা এবং অন্যান্য গোপন অনুশীলন ব্যবহার করে, ক্লায়েন্ট "সম্ভাব্যভাবে উল্লেখযোগ্য" কিনা তা নির্ধারণ করে (যার জন্য, অভ্যন্তরীণ প্রবিধান অনুযায়ী, "48 ঘন্টা পর্যন্ত")। যদি তা না হয়, তাহলে ঠিকানাটি অন্য টেবিলে যোগ করা হয় এবং অন্য SQL কোয়েরি চালানোর জন্য ভারতে ফেরত পাঠানো হয়।

যদি বিপণন কোনও ক্লায়েন্টকে "গুরুত্বপূর্ণ" হিসাবে চিহ্নিত করে, তবে তাদের ম্যানুয়ালি একটি চিঠি পাঠানো হয় যেমন "আপনি কি সত্যিই সদস্যতা ত্যাগ করতে চান?" দেখে মনে হচ্ছে এটি স্বয়ংক্রিয়ভাবে তৈরি হয়েছে, কিন্তু আসলে তা নয়।

যদি তারা "হ্যাঁ" উত্তর দেয় (প্রথম দিকে বড় অক্ষরে "হ্যাঁ" লেখা দরকার ছিল), তাহলে সুইন্ডন থেকে দল তাদের ভারতে পাঠায়। তৃতীয় টেবিল এবং সেখানে পরবর্তী স্ক্রিপ্টটি অত্যন্ত আন্তরিকভাবে সম্পাদিত হয়।

আমি সঠিকভাবে মনে রাখলে, এটি গড়ে লাগে চার কার্যদিবস. গড়ে, প্রতিদিন প্রায় 700 জন সদস্যতা ত্যাগ করেন, যার মধ্যে 70% "সম্ভাব্যভাবে উল্লেখযোগ্য"।

যাইহোক, এই দুই ভারতীয় আমাদের ডেভেলপমেন্ট টিমে স্থানান্তরিত হয়েছিলেন এবং এই সমস্ত বাজে কথা প্রতিস্থাপনকারী সিস্টেমের জন্য প্রধানমন্ত্রী হয়েছিলেন। তারা ছিল সবচেয়ে দয়ালু, সহানুভূতিশীল এবং কঠোর পরিশ্রমী মানুষ যাদের সাথে কাজ করে আমি আনন্দ পেয়েছি। এটা তাদের ধন্যবাদ যে এই দুঃস্বপ্নের কর্পোরেট প্রক্রিয়া এত বছর "মসৃণভাবে" কাজ করেছে। পরে তারা ইংল্যান্ডে চলে যায় এবং তাদের একজন এখন 40+ কর্মচারী নিয়ে একটি বিভাগ চালায়।

অনুবাদকের নোট: কেডিপিভিতে পেঁচা - জোল.

উত্স: www.habr.com