Một dòng tweet hỏi tại sao việc hủy đăng ký có thể “mất nhiều ngày”. Hãy thắt dây an toàn nhé, tôi sắp nói với bạn điều này đáng kinh ngạc câu chuyện về cách nó được thực hiện trong Enterprise Development™...
Có một ngân hàng. Bạn có thể đã nghe nói về nó và nếu bạn sống ở Vương quốc Anh thì có 10% khả năng đó là của bạn ngân hàng. Tôi đã làm việc ở đó với tư cách là “nhà tư vấn” với mức lương rất cao.
Ngân hàng gửi thư tiếp thị. Có một liên kết “hủy đăng ký” nhỏ ở chân trang của mỗi email. Mọi người đôi khi nhấp vào các liên kết này.
Nhấp vào liên kết sẽ khiến một máy chủ web thời tiền sử quay ở đâu đó trong ngân hàng. Thành thật mà nói, tôi phải mất ba tuần mới tìm được anh ấy.
Dịch vụ này sẽ gửi email đến hộp thư đến nội bộ của bạn mỗi khi nhấp vào liên kết. Điều này xảy ra hàng trăm lần một ngày.
Trước đây, những bức thư này được gửi đến một nhân viên cụ thể, nhưng anh ta đã rời đi cách đây XNUMX năm.
Bây giờ bức thư được chuyển tiếp đến nhóm phân phối. Họ không thể thay đổi địa chỉ của người nhận vì nó đã được mã hóa cứng và họ không thể tìm thấy mã nguồn của dịch vụ. Dịch vụ này được viết bằng Java 6.
Những bức thư trong nhóm gửi thư được kiểm tra bởi hai nhân viên của trung tâm hải ngoại của ngân hàng ở Hyderabad (Ấn Độ). Họ làm việc chăm chỉ và hoàn thành nhiệm vụ của mình đáng kinh ngạc, nhưng chết tiệt, công việc này thật không thể chịu nổi.
Tôi đã liên lạc với họ qua hội nghị truyền hình và họ có tất cả các dấu hiệu của hội chứng hậu chấn thương doanh nghiệp. Họ đã chiến đấu với điều vô nghĩa này qua nhiều năm và trong thời gian này không Không thay đổi.
Khi một lá thư đến, họ phải thực thi một tập lệnh SQL để xác định xem địa chỉ bị hủy đăng ký có thuộc về khách hàng ngân hàng hay không (khi đó giao thức là một) hay không (sau đó là một giao thức khác).
Nếu người nhận là khách hàng, họ cần chạy một tập lệnh SQL khác để cập nhật bản ghi khách hàng trong môi trường tiền ETL. Tất cả các thay đổi sẽ được xem xét vào lúc 16:00 giờ Luân Đôn bởi một nhóm riêng biệt ở Scotland. Nếu những thay đổi vượt qua quá trình xác minh, chúng sẽ được áp dụng cho cơ sở dữ liệu thực vào một ngày khác trong 16: 00.
Nếu người nhận không phải là khách hàng, họ sẽ thêm vào bảng tính Excel và gửi cho nhóm tiếp thị ở Swindon trước khi về nhà.
Nhóm tiếp thị, sử dụng lá trà và các phương pháp huyền bí khác, xác định xem khách hàng có “có tiềm năng quan trọng” hay không (theo quy định nội bộ, “tối đa 48 giờ”). Nếu không, địa chỉ sẽ được thêm vào bảng khác và gửi trở lại Ấn Độ để thực hiện một truy vấn SQL khác.
Nếu bộ phận tiếp thị đã xác định một khách hàng là “quan trọng”, họ sẽ được gửi một lá thư theo cách thủ công như “Bạn có chắc chắn thực sự muốn hủy đăng ký không?” Có vẻ như nó được tạo tự động nhưng thực tế không phải vậy.
Nếu họ trả lời “có” (ban đầu phải viết “CÓ” bằng chữ in hoa), thì đội từ Swindon sẽ gửi họ đến Ấn Độ ngày thứ ba table và ở đó tập lệnh tiếp theo được thực thi một cách long trọng.
Nếu tôi nhớ không lầm thì trung bình phải mất bốn ngày làm việc. Trung bình có khoảng 700 người hủy đăng ký mỗi ngày, trong đó 70% là “có khả năng quan trọng”.
Nhân tiện, hai người Ấn Độ này đã chuyển sang nhóm phát triển của chúng tôi và trở thành Thủ tướng cho hệ thống thay thế tất cả những điều vô nghĩa này. Họ là những người tốt bụng nhất, giàu lòng nhân ái nhất và làm việc chăm chỉ nhất mà tôi rất hân hạnh được làm việc cùng. Nhờ có họ mà quy trình kinh doanh ác mộng này đã diễn ra rất “suôn sẻ” trong suốt những năm qua. Sau đó, họ chuyển đến Anh và một trong số họ hiện đang điều hành một bộ phận với hơn 40 nhân viên.
Ghi chú của người dịch: cú trên KDPV - .
Nguồn: www.habr.com