Un chío preguntou por que cancelar a subscrición podería "levar días". Abróchate ben, estou a piques de dicircho incrible a historia de como se fai en Enterprise Development™...
Hai un banco. Probablemente xa escoitou falar del, e se vives no Reino Unido, hai un 10 % de posibilidades de que sexa o teu banco. Traballei alí como "consultor" por un excelente salario.
O banco envía cartas de mercadotecnia. Hai unha pequena ligazón para cancelar a subscrición no pé de cada correo electrónico. A xente ás veces fai clic nestas ligazóns.
Facer clic nunha ligazón fai que un servidor web prehistórico xire nalgún lugar no banco. Sinceramente, tardei tres semanas en atopalo.
Este servizo envía un correo electrónico á túa caixa de entrada interna cada vez que se fai clic nunha ligazón. Isto ocorre varios centos de veces ao día.
Anteriormente, estas cartas enviábanselles a un empregado concreto, pero hai cinco anos marchou.
Agora a carta envíase ao grupo de distribución. Non puideron cambiar o enderezo do destinatario porque estaba codificado e non puideron atopar o código fonte do servizo. O servizo está escrito en Java 6.
As cartas do grupo de correo son revisadas por dous empregados do centro offshore do banco en Hyderabad (na India). Traballan duro e completan as súas tarefas incrible, pero carallo, este traballo é insoportable.
Comuniqueime con eles por videoconferencia e tiñan todos os signos da síndrome postraumática empresarial. Loitaron contra este despropósito durante anos e durante este tempo nada non cambiou.
Cando chega unha carta, deben executar un script SQL que determina se o enderezo que se está dando de baixa pertence ao cliente do banco (daquela o protocolo é un) ou non (despois outro).
Se o destinatario é un cliente, debe executar outro script SQL que actualice o rexistro do cliente no ambiente pre-ETL. Todos os cambios son revisados ás 16:00 hora de Londres por un equipo separado en Escocia. Se os cambios pasan a verificación, aplicaranse á base de datos real noutro día ás 16:00.
Se o destinatario non é un cliente, engádeo a unha folla de cálculo de Excel e envíano ao equipo de marketing en Swindon antes de volver a casa.
O equipo de marketing, utilizando follas de té e outras prácticas ocultas, determina se o cliente é "potencialmente significativo" (para o que, segundo a normativa interna, "ata 48 horas"). Se non o é, entón o enderezo engádese a outra táboa e envíase de volta á India para executar outra consulta SQL.
Se o marketing identificou un cliente como "importante", envíaselle manualmente unha carta como "Estás seguro de que realmente queres cancelar a subscrición?" Parece que se xera automaticamente, pero de feito non o é.
Se responden "si" (inicialmente era necesario escribir "SI" en maiúsculas), entón o equipo de Swindon envíanos á India terceiro táboa e alí execútase solemnemente o seguinte script.
Se non recordo mal, leva unha media catro días hábiles. De media, unhas 700 persoas danse de baixa ao día, das cales o 70% son "potencialmente significativas".
Por certo, estes dous indios trasladáronse ao noso equipo de desenvolvemento e convertéronse en PMs do sistema que substituíu todo este despropósito. Foron as persoas máis amables, compasivas e traballadoras coas que tiven o pracer de traballar. Foi grazas a eles que este proceso corporativo de pesadelo funcionou tan "sen problemas" todos estes anos. Máis tarde mudáronse a Inglaterra e un deles agora dirixe un departamento con máis de 40 empregados.
Nota do tradutor: curuxa en KDPV - .
Fonte: www.habr.com