Isang tweet ang nagtanong kung bakit ang pag-unsubscribe ay maaaring "magtagal ng mga araw." Magsick up ng mahigpit, sasabihin ko na sa iyo hindi kapani-paniwala ang kwento kung paano ito ginagawa sa Enterprise Developmentβ’...
May isang bangko. Marahil ay narinig mo na ito, at kung nakatira ka sa UK, mayroong 10% na posibilidad na iyong bangko. Nagtrabaho ako doon bilang isang "consultant" para sa isang mahusay na suweldo.
Nagpapadala ang bangko ng mga sulat sa marketing. Mayroong maliit na link na "unsubscribe" sa footer ng bawat email. Minsan nag-click ang mga tao sa mga link na ito.
Ang pag-click sa isang link ay nagiging sanhi ng pag-ikot ng isang prehistoric web server kahit saan sa bangko. Sa totoo lang, inabot ako ng tatlong linggo para lang mahanap siya.
Ang serbisyong ito ay nagpapadala ng email sa iyong panloob na inbox sa tuwing may naki-click na link. Nangyayari ito ng ilang daang beses sa isang araw.
Dati, ang mga liham na ito ay ipinadala sa isang partikular na empleyado, ngunit limang taon na ang nakalilipas ay umalis siya.
Ngayon ang liham ay ipinapasa sa pangkat ng pamamahagi. Hindi nila mapalitan ang address ng tatanggap dahil naka-hardcode ito, at hindi nila mahanap ang source code mula sa serbisyo. Ang serbisyo ay nakasulat sa Java 6.
Ang mga liham sa mailing group ay sinusuri ng dalawang empleyado ng offshore center ng bangko sa Hyderabad (sa India). Nagsusumikap sila at tinatapos ang kanilang mga gawain kahanga-hanga, ngunit sumpain, ang gawaing ito ay hindi mabata.
Nakipag-usap ako sa kanila sa pamamagitan ng video conference at mayroon silang lahat ng mga palatandaan ng enterprise-post-traumatic syndrome. Nilabanan nila ang kalokohang ito sa paglipas ng mga taon at sa panahong ito wala hindi nagbago.
Kapag may dumating na liham, dapat silang magsagawa ng SQL script na tumutukoy kung ang address na ina-unsubscribe ay pagmamay-ari ng kliyente ng bangko (kung gayon ang protocol ay isa) o hindi (pagkatapos ay isa pa).
Kung ang tatanggap ay isang customer, kailangan nilang magpatakbo ng isa pang SQL script na nag-a-update sa tala ng customer sa pre-ETL na kapaligiran. Ang lahat ng mga pagbabago ay sinusuri sa 16:00 oras sa London ng isang hiwalay na koponan sa Scotland. Kung ang mga pagbabago ay pumasa sa pag-verify, ilalapat ang mga ito sa totoong database sa ibang araw sa 16:00
Kung ang tatanggap ay hindi isang kliyente, idinaragdag nila ito sa isang Excel spreadsheet at ipapadala ito sa marketing team sa Swindon bago umuwi.
Tinutukoy ng marketing team, gamit ang mga dahon ng tsaa at iba pang mga okultismo, kung ang kliyente ay "posibleng makabuluhan" (kung saan, ayon sa mga panloob na regulasyon, "hanggang 48 oras"). Kung hindi, ang address ay idaragdag sa isa pang talahanayan at ibabalik sa India upang magsagawa ng isa pang SQL query.
Kung natukoy ng marketing ang isang kliyente bilang "mahalaga", manu-mano silang pinadalhan ng sulat tulad ng "Sigurado ka bang gusto mo talagang mag-unsubscribe?" Mukhang ito ay awtomatikong nabuo, ngunit sa katunayan ito ay hindi.
Kung sumagot sila ng "oo" (sa una ay kinakailangan na isulat ang "OO" sa malalaking titik), pagkatapos ay ipinapadala sila ng koponan mula sa Swindon sa India pangatlo table at doon ang susunod na script ay taimtim na isinasagawa.
Kung tama ang pagkakaalala ko, ito ay tumatagal sa karaniwan apat na araw ng trabaho. Sa karaniwan, humigit-kumulang 700 tao ang nag-a-unsubscribe bawat araw, kung saan 70% ay "posibleng makabuluhan."
Siyanga pala, ang dalawang Indian na ito ay lumipat sa aming development team at naging mga PM para sa sistemang pumalit sa lahat ng kalokohang ito. Sila ang pinakamabait, pinaka-mahabagin at masipag na mga tao na nasiyahan akong magtrabaho kasama. Ito ay salamat sa kanila na ang bangungot na proseso ng korporasyon na ito ay nagtrabaho nang "smoothly" sa lahat ng mga taon na ito. Nang maglaon ay lumipat sila sa England at ang isa sa kanila ay nagpapatakbo na ngayon ng isang departamento na may 40+ na empleyado.
Tala ng tagasalin: kuwago sa KDPV - .
Pinagmulan: www.habr.com