메일링 리스트에서 구독을 취소하는 데 며칠이 걸리는 이유는 무엇입니까?

한 트윗에서는 구독 취소가 "며칠이 걸릴 수 있는" 이유를 물었습니다. 버클을 꽉 채우세요, 곧 말하겠습니다 믿을 수 없는 Enterprise Development™에서 어떻게 이루어졌는지에 대한 이야기...

은행이 하나 있습니다. 아마 들어본 적이 있을 것입니다. 영국에 살고 있다면 그럴 가능성이 10%입니다. ваш 은행. 나는 그곳에서 좋은 급여를 받기 위해 "컨설턴트"로 일했습니다.

은행은 마케팅 서신을 발송합니다. 각 이메일의 바닥글에는 작은 "구독 취소" 링크가 있습니다. 사람들은 때때로 이러한 링크를 클릭합니다.

링크를 클릭하면 하나의 선사 시대 웹 서버가 회전합니다. 어딘가에 은행에서. 솔직히 그 사람을 찾는 데만 XNUMX주가 걸렸어요.

이 서비스는 링크를 클릭할 때마다 내부 받은 편지함으로 이메일을 보냅니다. 이런 일이 하루에 수백 번씩 일어납니다.

이전에는 특정 직원에게 이 편지를 보냈으나 XNUMX년 전 그는 회사를 떠났다.

이제 편지가 배포 그룹으로 전달됩니다. 수신자의 주소가 하드코딩되어 있어서 변경할 수 없었고, 서비스에서 소스 코드도 찾을 수 없었습니다. 서비스는 Java 6으로 작성되었습니다.

메일링 그룹의 편지는 하이데라바드(인도)에 있는 은행 역외 센터의 직원 두 명이 확인합니다. 그들은 열심히 일하고 임무를 완수한다 대박, 하지만 젠장, 이 작업은 참을 수 없습니다.

나는 화상회의를 통해 그들과 소통했고 그들은 기업 외상후 증후군의 징후를 모두 갖고 있었습니다. 그들은 말도 안되는 소리와 싸웠습니다 몇 년 동안 그리고 이 시간 동안 무 변경되지 않았습니다.

편지가 도착하면 구독 취소 중인 주소가 은행 클라이언트에 속하는지(프로토콜이 하나인지) 아닌지(다른 프로토콜) 여부를 결정하는 SQL 스크립트를 실행해야 합니다.

수신자가 고객인 경우 ETL 이전 환경에서 고객 레코드를 업데이트하는 다른 SQL 스크립트를 실행해야 합니다. 모든 변경 사항은 스코틀랜드의 별도 팀에서 런던 시간 16시에 검토됩니다. 변경 사항이 확인을 통과하면 실제 데이터베이스에 적용됩니다. 다른 날에 16 : 00.

수신자가 고객이 아닌 경우 Excel 스프레드시트에 추가하여 집에 가기 전에 Swindon에 있는 마케팅 팀에 보냅니다.

마케팅 팀은 찻잎 및 기타 오컬트 관행을 사용하여 고객이 "잠재적으로 중요한"지 여부를 결정합니다(내부 규정에 따라 "최대 48시간"). 그렇지 않은 경우 주소가 다른 테이블에 추가되고 다른 SQL 쿼리를 실행하기 위해 인도로 다시 전송됩니다.

마케팅에서 고객을 "중요"하다고 식별한 경우 "정말로 구독을 취소하시겠습니까?"와 같은 편지가 수동으로 전송됩니다. 자동으로 생성되는 것처럼 보이지만 실제로는 그렇지 않습니다.

그들이 "예"라고 대답하면(처음에는 "YES"를 대문자로 써야 함) Swindon 팀이 이를 인도로 보냅니다. 제삼 테이블이 있고 거기에서 다음 스크립트가 엄숙하게 실행됩니다.

내 기억이 맞다면 평균적으로 걸리는데 XNUMX일(영업일 기준). 하루 평균 약 700명이 구독을 취소하는데, 그 중 70%가 '잠재적으로 의미 있는' 구독자입니다.

그런데 이 두 인도인은 우리 개발팀으로 옮겨 이 모든 말도 안되는 일을 대체하는 시스템의 PM이 되었습니다. 그들은 내가 함께 일하는 즐거움을 누린 사람들 중 가장 친절하고, 동정심 많고, 열심히 일하는 사람들이었습니다. 이 악몽 같은 기업 프로세스가 수년 동안 그토록 "순조롭게" 작동할 수 있었던 것은 그들 덕분이었습니다. 나중에 그들은 영국으로 이사했고 그 중 한 명은 현재 40명이 넘는 직원이 있는 부서를 운영하고 있습니다.

번역자 주: KDPV의 올빼미 - 욜.

출처 : habr.com