一則推文詢問為什麼取消訂閱可能「需要幾天」。 繫緊安全帶，我要告訴你 極佳的 在 Enterprise Development™ 中如何實現這一點的故事...
有一家銀行。 您可能聽說過，如果您住在英國，那麼有 10% 的可能性是 ваш 銀行。 我在那裡擔任“顧問”，薪水很高。
銀行發出行銷信函。 每封電子郵件的頁腳都有一個小的「取消訂閱」連結。 人們有時會點擊這些連結。
點擊連結會導致一台史前網頁伺服器旋轉 某處 在銀行裡。 老實說，我花了三個星期才找到他。
每次點擊連結時，此服務都會向您的內部收件匣發送一封電子郵件。 這種情況每天會發生數百次。
此前，這些信件是發送給特定員工的，但他五年前離開了。
現在這封信已轉發給通訊組。 他們無法更改收件人的地址，因為它是硬編碼的，而且他們無法從服務中找到原始程式碼。 該服務是用 Java 6 編寫的。
郵寄組的信件由該銀行位於海得拉巴（印度）的離岸中心的兩名員工進行檢查。 他們努力工作並完成任務 奧沙耶尼諾但該死的，這工作實在難以忍受。
我透過視訊會議與他們溝通，他們具有企業創傷後症候群的所有跡象。 他們與這種無意義的行為作鬥爭 多年 並在這段時間裡 沒什麼 沒有改變。
當一封信到達時，他們必須執行一個 SQL 腳本來確定取消訂閱的地址是否屬於銀行客戶端（那麼協議就是一個）或不屬於（那麼協議就是另一個）。
如果接收者是客戶，他們需要執行另一個 SQL 腳本來更新 ETL 前環境中的客戶記錄。 所有更改均由蘇格蘭的獨立團隊於倫敦時間 16:00 進行審核。 如果變更通過驗證，則會套用到真實資料庫 改天 在16:00。
如果收件人不是客戶，他們會將其添加到 Excel 電子表格中，並在回家之前將其發送給斯溫頓的行銷團隊。
行銷團隊使用茶葉和其他神秘實踐來確定客戶是否「具有潛在重要性」（根據內部規定，「長達 48 小時」）。 如果不是，則將該位址新增至另一個表格並傳送回印度以執行另一個 SQL 查詢。
如果行銷人員將客戶識別為“重要”，則會手動向他們發送一封類似“您確定真的要取消訂閱嗎？”的信件。 看起來像是自動產生的，但實際上不是。
如果他們回答「是」（最初需要用大寫字母寫「是」），那麼斯溫頓的團隊就會將他們送到印度 第三 表中，下一個腳本將被鄭重執行。
如果我沒記錯的話，平均需要 四個工作天。 平均每天約有 700 人取消訂閱，其中 70% 是「潛在重要的」。
順便說一句，這兩個印度人調到了我們的開發團隊，並成為了系統的 PM，取代了所有這些廢話。 他們是我有幸共事過的最善良、最富同情心和最勤奮的人。 多虧了他們，這個惡夢般的公司流程這些年來才運作得如此「順利」。 後來他們搬到了英國，其中一人現在管理著一個擁有 40 多名員工的部門。
譯者註：KDPV 上的貓頭鷹 - .
來源： www.habr.com