Veja o original, em inglês, aqui.

Não aderente por design

O departamento de suporte de TI na empresa onde Stephen S. trabalhava era divido em duas castas muito distintas: helpdesk admins e systems admins. E as diferenças entre estes dois grupos eram muitas.

Os helpdesk admins tinham turnos rotativos, e estavam lá 24×7 (e cada um deles ainda estava de sobre aviso 24×7 também), enquanto os system admins tinham um horário sólido das 9 às 5, e apenas um system admin de sobre aviso. Os helpdesk admins estavam sempre cumprindo seu dever, enquanto os systems admins muitas vezes compareciam à reuniões de fornecedores, com excelentes coffe-breaks, deixando os helpdesk admins para lutar pelas migalhas depois que partiam. E ainda havia uma diferença significativa na escala de pagamento. Os helpdesk admins eram os “peões” do TI da empresa, e enquanto a empresa fazia de tudo para manter os system admins felizes, pagando inclusive o transporte dos mesmos trabalho/casa e casa/trabalho.

A hora do morcego

No mundo do suporte de TI, 4:30 AM significa coisas diferentes para grupos diferentes. Para system admins, significava apenas mais uma hora de sono nas suas camas supergrandes e superconfortáveis, com seus travesseiros de luxo. Para Stephen e os outros helpdesk admins trabalhando à noite, essa hora significava que já havia passado metade do turno do cemitério. Olhos vermelhos e cansados, olhando seus emails, o telefone do suporte toca. “Help desk, Stephen falando”. Depois de dar suporte por tanto tempo, Stephen muitas vezes atendia seu telefone pessoal dessa mesma forma, sem querer.

“Olá Stephe, Brent Thomas do escritório de Nova York”, respondeu do outro lado da linha. “Acredito que travei minha conta no domínio, você poderia me ajudar?”

Uma tarefa simples, apenas para confirmar seu miserável status de somente um reles empregado de Help desk. “Claro, sem problemas”, respondeu Stephen.

Então ele navegou até a conta do usuário, mas estranhamente, ele não tinha mais permissões para resetar contas. Verificando um outro usuário que ele havia resetado um dia atrás, mesmo problema. Stephen não tinha mais acesso à nenhuma das contas!

“Ah, me desculpe, tenho um problema na minha ponta. Preciso contactar um dos nossos system admins.” Excelente, agora este cara não pode trabalhar, e *eu* estou parecendo não saber o que estou fazendo!

Às 4:32 da manhã, ele estava no telefone com o system admin de plantão. “… A-alô?” A voz do system admin estava sonolenta e ranzinza.

“Oi, aqui é Stephen do suporte de desktops, eu estou com um usuá-”

“O quê, você está com um problema que você não consegue resolver?” Longo suspiro.

“Não, só não consigo resetar a senha desse usuário.”

Agora um suspiro ainda maior. “Stephen”, ele disse, “ontem nós tivemos uma grande reunião. Para manter aderência aos nossos processos, todas as mudanças em contas de usuários devem ser gravadas como tickets”.

“Sim, e nós já estamos fazendo isso.” Stephen agora já estava rangendo os dentes. “Estou ligando porque não cons-”

“AINDA”, interrompeu o system admin, elevando seu tom de voz,  “os direitos para destravar (unlock) contas foram reservados somente aos system admins. Stephen, você só precisa fazer sua parte, grave o ticket, eu estou certo de que você consegue fazer isso.”

“OK, mas este usuário não será capaz de… Alô?” O system admin havia desligado o telefone.

Stephen bateu o telefone com força, fervendo de raiva. Ao abrir o ticket, ele digitou como se estivesse tentando dar uma surra no teclado, se certificando de incluir uma observação que ele estava seguindo instruções do system admin de plantão, e que ele não havia conseguido destravar a conta por si só. Stephen estava furioso que o diretor tenha feito uma decisão que parecia ser boa no papel, mas que para efeitos práticos simplesmente não faziam sentido algum.

Chamadas continuavam a chegar, solicitando mais resets de conta, à medida que o dia de trabalho começava do outro lado do país – com milhares de usuários para atender, os travamentos de conta começaram a se acumular. Stephen gravou cada um dos chamados como tickets de baixa prioridade (como mandava o procedimento), e os associou aos system admins. Com a agenda de trabalho fixa das 9 as 5 dos system admins, eles estariam chegando para trabalhar em pouco mais do que 4 horas.

O problema? Resets de conta eram para ser realizados mandatoriamente em 4 horas ou menos, caso contrário os chamados iriam estourar o SLA. Quando isso acontece, uma tempestade de documentações e reviews de processos para determinar porque isso aconteceu, como isso pode ser previnido, quais ações disciplinares devem ser tomadas, etc.

E para piorar a situação, mudanças ao domínio não se propagavam instantaneamente – os system admins não queriam forçar updates de domínio, e ao invés disso esperavam pela replicação programada a cada 4 horas. No pior caso, 9 horas sem conta, e um dia de trabalho perdido para um funcionário.

Os systems admins estavam andando em direção à uma armadilha criada por eles mesmos naquela manhã. Os usuários continuavam travados, e os chamados sem resolução por horas. Mais chamadas chegavam, e eram escalonadas para os system admins, libertando uma torrente de telefonemas, emails e reuniões.

Dois dias úteis depois, o processo havia mudado – o Help Desk tinha novamente o nível de administradores de domínio, requerido para realizar o reset das senhas, e a replicação de domínio havia sido mudada para cada 90 minutos. Emails inter-departamentos voavam de um lado para o outro sobre a aderência ao SLA e atualizações na política, e a gerência aprendeu que, enquanto Stephen talvez fosse somente um técnico de suporte de baixo nível, ele ainda poderia saber de uma ou duas coisas sobre o processo.

Tradução: “apenas para provar que você é um humano, por favor responda o desafio de matemática a seguir”

O novo website do HBSP era moderno. Construído sobre um sistema de buscas avançado (pelo menos para a época), o site re-desenhado também contava com comunidades online (foruns) e uma seção chamada “Ideas @ Work”, que permitia que usuários baixassem transmissões de aúdio de grandes pensadores da área de negócios espalhados pelo mundo. E, o melhor de tudo era que, apesar de um rápido cronograma de desenvolvimento, mudanças no escopo, e todos os penduricalhos, o site realmente funcionava. E no início da era pontocom, não eram muitos os sites que podiam alegar isso.

Um dos maiores fatores para o sucesso do site do HBSP era o processo extenso de teste e garantia de qualidade. Analistas desenvolveram todos os tipos de casos de teste para cobrir virtualmente todo e qualquer aspecto do site. Eles trabalharam muito próximos ao departamento de logística do HBSP, para garantir que os testes – testes de busca, gerencia de conta, pedidos, etc. – fossem executados. E não somente executados, mas executados com frequência.

Essa estratégia agressiva de testes garantia que o site funcionaria conforme planejado por anos e mais anos. Isso é, até aquele fatídico dia em 2002. Naquele dia, um dos casos de teste falhou: o caso de teste “Busca de um só resultado”.

O caso de teste “Busca de um só resultado” era parte de um trio de casos de teste para testar a lógica do sistema de busca. Como o caso de teste “Busca de nenhum resultado”, onde o testador digitava um termo como “asdfasdf” para produzir nenhum resultado, e o caso de teste “Busca com vários resultados”, onde o testador entrava com um termo como “gerência” para produzir páginas e mais páginas de resultado. No caso de testes problematico em questão – “Busca de um só resultado” – o testador digitaria um termo – mais especificamente o termo “macaco” – para verificar que o sistema retornaria somente um único resultado.

E durante três longos anos, “macaco” retornava exatamente um único resultado: o artigo Who’s Got the Monkey?, por William Oncken Jr. Escrito em 1974, o artigo de Oncken é para os gerentes que “se veêm sem tempo, enquanto seus subordinados vão ficando sem trabalho”. É bom deixar claro que os macacos, neste caso, são somente uma analogia ao trabalho, e não para quem os gerentes devem terceirizar o trabalho. Aparentemente, Oncken não estava tão a frente do seu tempo.

Pois naquele dia de 2002, “macaco” retornou dois resultados. O primeiro, conforme esperado, era o artigo Who’s Got the Monkey?. O segundo resultado era o “Who’s got the monkey now?”, que era um upgrade do artigo original. O óbvio ululante era aparente: basta atualizar o caso de testes. Entretanto, o time de testes da HBSP resolveu investigar mais o assunto.

Como parte da estratégia agressiva de testes mencionada anteriormente, o time de logística do HBSP preenchia o seu tempo livre executando os casos de testes. Primeiro eles rodavam o “Busca de nenhum resultado”, depois o “Busca com vários resultados”, e por fim o “Busca de um resultado só”. Depois, eles adicionavam esse único resultado – Who’s got the monkey – ao carrinho de compras, criavam uma nova conta e submetiam a compra. É obvio que o último passo – a expedição do pedido – não era executado – todo mundo sabia que compras para “Sr Teste Teste” e “Rua 123 Teste” não eram para ser expedidas. Isso é, tudo mundo menos o departamento de Marketing.

Quando o departamento de Marketing da HBSP analisou as tendências de vendas, eles notaram uma tendência bastante interessante. O Who’s got the monkey, de 1974, era um grande Best-Seller! E como qualquer departamento de Marketing faria, eles pegaram a estória e correram. HBSP criou panfletos e outras melhorias para o trabalho de Oncken. Eles inclusive embalaram pequenos macacos de plástico, como os macacos “oficiais” do Who’s got the monkey. E finalmente, em algum ponto de 2002, a versão atualizada e revisada do artigo Who’s got the monkey foi postada no sistema de vendas online da HBSP, e terminou sendo indexado no sistema de buscas, que no final das contas terminou fazendo com que o caso de testes “Busca de um resultado só” falhasse.

Artigo traduzido a partir do original, em inglês, I’ve got the monkey now.

Veja um exemplo da capacidade que têm os jornalistas estagiários do departamento de jornalismo do Terra:

(clique para ver maior)

Racker, segundo o dicionário inglês-inglês da universidade de Princeton, é "uma pessoa que é responsável por colocar bolas de sinuca ou bilhar em um rack". Rack é um termo em inglês que denomina qualquer tipo de suporte (rack para TV, Vídeo, bolas de sinuca/bilhar, etc). Imagine como esses rackers representam o perigo e a ruína para os incautos usuários de internet! Quando vi isso, postei aqui imediatamente, antes que eles corrijam.

Na realidade, o que o energumeno do jornalista estagiário quis dizer foi que o BBB8 é utilizado agora como tema de golpes de phishing scam. Leia um artigo meu artigo sobre esses golpes aqui.

"Isso é para você ver a capacidade do RH da empresa onde eu trabalho. Tivemos uma campanha contra DST, e olha só como eles me entregaram a camisinha".

Clique na foto para ver maior. Para os mais desavisados, chamo atenção para o detalhe:

Vejam onde o ser pensante do RH grampeou a camisinha. Será que ele(a) é virgem?! WTF?!