Multicultural Communication (Comunicação Multicultural)

I was invited to participate in 2 webinars about the Agile environment method of IT analysis referring to "forget about practices, work on culture", and that led me to remember some more difficulties I came across in my professional life which I believe may be useful to share with the company which invited me. 

It Is About Communication

I confess that I have difficulties understanding certain English accents. In this case, I particularly refer to Samar's (fictional name) one, since I have already taken part in a LIVE with him speaking and he was the most difficult to understand, I almost regret to say. Actually, it is rather the Indian accent in general, which has irritated the clients so much that most call centers in Australia brought back their offices to onshore.

It may not be polite to say that, but perhaps people with accents should try speaking a little slower or to use other tricks. I have a defective Latin accent myself, of course, so I have learnt some tricks which I actually do not know if they have been working because people do not give feedback, perhaps because it's a sensitive area which touches egos and they do not want to hurt me. But they should. Perhaps the Americans are not so educated, so they say... Extending a little bit only in terms of samples, the worst are Scotch, metropolitan Londoners and Australia's countrymen's accents, but there are a million others.

Related to that, I recall that many people are just like me in terms of talking and listening in a multicultural environment which is a global tendency. Having worked in multicultural teams a lot in Australia, I know that there are a number of people who pretend to be understanding a lecture or a presentation but they are not, and we only discover that after sometime during the work and some mistakes.

 

Everyone feels ashamed of admitting it, mainly afraid of being considered dumb or incompetent, which is not my case. They prefer to keep quiet with the appearance of an intellectual statue so the others think they understood everything without a problem. Let alone making silly questions, which I am not ashamed of doing. It is not true, unfortunately they did not understand perhaps crucial concepts. Most people of course say "it was clear and easy", but when you put them into practice, you notice that they are not aware of some things, which have been treated in previous presentations. Was it your fault during the presentation or their fault for not asking enough? Both.

Well, sometimes I feel ashamed to interrupt people and ask them to repeat what they said, because I would do that a lot. I believe that many people share this feeling as well. I had an Australian National CEO in Australia who would constantly say "please, speak slowly and explain again because I am slow and did not pick up". He turned out to be my hero from then on.

So, I believe that this may be one of the most important bottlenecks to remove when we need to build a truly understanding and levelled team and we have to deal with these particular subtle and sensitive areas that deeply touches our souls as office mates in a company culture. We already talked about aspects like character and personality, now it is time to talk about communication taken for granted. And I did not even talk about writing... so many people just do not know how to communicate correctly, not even by writing... That is the time we need to remember everyday that we are in a professional environment, not at home.

Team Building Activity

Once I was escalated to lead a team building activity. I took it seriously, because they had organized silly activities like go-kart, mini-golf or paint-ball so far which irritated me and I did not participate, only for nibbles, beverages and getting together into superficial conversations, when they existed.

In my case, I researched and found a very interesting "game" which was one that took part in a park. We would have an activity, i.e. a game, then people would be free to spend the rest of the hours eating, talking, resting in the shadowed grass by the lake or playing soccer (as they actually did).

The game was the Labyrinth Team Building Game which is a head-scratching challenge where teams work together quickly and effectively to make their way through a maze of puzzles and obstacles.

Labyrinth Benefits

• Enhance communication and collaboration skills
• Build trust in the workplace
• Illustrate the value of individual member roles
• Demonstrate the importance of time management and deadlines
• Improve problem solving skills

The event coordinator welcomes the group and puts everyone into teams randomly. Delegates can expect to face a range of puzzles and challenges that will test their ingenuity, problem solving and communication skills. Team work is absolutely essential to complete the challenges within the best time line. Teams will face all sorts of barriers on their way through the labyrinth. Bridges will need to be built, gates unlocked and webs negotiated.

The activity required preparing a track which was built with board boxes and all sorts of pre-prepared obstacles. We would enter from one side and get off by the other side. In the middle, there would be a tortuous labyrinthic path which the participant should walk until reaching the end of the track. The groups included 2 people: 1 to walk and the other to tell this one what to do, because the walker would be blind folded!

The walker should follow what the commander would say and so get safe to the end. The winner would be the couple who would finish in the best time with fewer mistakes. It was very fun, but unfortunately the results were not appreciated as they should have. Not even the director took the importance of the activity seriously.

Highlights

The perfection of the communication - one would say words, and the other would understand perfectly to execute the steps exactly as the commander said in a quick manner. Well, this showed that not only people had difficulties to express themselves rationally as well as the other part would not understand very well what was said and do the wrong thing. The highlight was not on who was the wrong one, but the effectiveness of the method of communication.

The behaviours - some would be in a rush to be the quicker which would compromise the perfection, make them stumble, kick and even fall, while others would be too careful to proceed, afraid of doing something wrong, and delaying the results. Those in a rush would give no time for the commander to correct their trajectory, and those too slow would demonstrate not to rely on the commander's words. The best would be one who would understand perfectly the well set and clear commands.

Results

In the end, two couples were winners under protests because the director chose the quicker one regardless of the errors in profusion, but the next quickest but more correct revolted. The winners would earn some monetary fringe benefits.

That would assess knowledge to be used back in the office, but nobody ever talked about that again, just like they treated the go-karting and paintballs, activities which served only to get together people who, otherwise, would never spend some time together outside the work hours. The other activities were BBQs, lunches and dinners, nothing actually professional like my proposal. It was really disappointing to realise that my work was not valued as it should.

Taking that to work, the winners would be those who deliver on time, regardless of correctness, quality and integrity. Those more responsible who would care about that would be punished because of eventual delay or trajectory correction on the project's timelines. That represents the culture of the company. Once the users said they preferred a delay than a defective system. They were ignored because the global Forbes company had a reputation of always delivering on time, no matter what, even letting corrections to be done afterwards, which can be very expensive.

This goes totally against the Agile concept which does not follow a pre-approved and tight Waterfall project!... It is another concern for the company who invited me I am sharing with!

Cheers.

Em Português (Portuguese)

Fui convidado a participar de 2 webinars sobre o método de análise de TI do ambiente Agile referente a "esqueça as práticas, trabalhe a cultura", e isso me levou a lembrar mais algumas dificuldades que encontrei na minha vida profissional que acredito serem úteis para compartilhar com a empresa que me convidou.

É Sobre Comunicação

Confesso que tenho dificuldades em entender certos sotaques ingleses. Nesse caso, me refiro particularmente ao Samar (nome fictício), pois já participei de uma LIVE com ele falando e ele foi o mais difícil de entender, quase lamento dizer. Na verdade, é mais o sotaque indiano em geral, que irritou tanto os clientes que a maioria dos call centers na Austrália trouxe de volta seus escritórios para dentro de casa.

Pode não ser educado dizer isso, mas talvez as pessoas com sotaque devam tentar falar um pouco mais devagar ou usar outros truques. Eu também tenho um sotaque latino defeituoso, é claro, então aprendi alguns truques que na verdade não sei se estão funcionando porque as pessoas não dão feedback, talvez porque seja uma área sensível que toca os egos e eles não querem me machucar. Mas eles deveriam. Talvez os americanos não sejam tão educados, assim dizem... Estendendo um pouco apenas em termos de amostras, os piores são os sotaques escoces, metropolitano londrino e do interior da Austrália, mas há um milhão de outros.

Relacionado a isso, lembro que muitas pessoas são como eu no que diz respeito a falar e ouvir em um ambiente multicultural que é uma tendência global. Tendo trabalhado muito em equipes multiculturais na Austrália, sei que há um número de pessoas que fingem estar entendendo uma palestra ou uma apresentação, mas não estão, e só descobrimos isso depois de algum tempo durante o trabalho e alguns erros.

Todo mundo sente vergonha de admitir, principalmente medo de ser considerado burro ou incompetente, o que não é o meu caso. Eles preferem ficar calados com a aparência de uma estátua intelectual para que os outros pensem que entenderam tudo sem problemas. Muito menos fazer perguntas bobas, que não me envergonho de fazer. Não é verdade, infelizmente eles não entenderam conceitos talvez cruciais. A maioria das pessoas, claro, diz "foi óbvio e fácil", mas quando você as coloca em prática, percebe que elas não estão cientes de algumas coisas, que foram tratadas em apresentações anteriores. Foi culpa sua durante a apresentação ou culpa deles por não perguntarem o suficiente? Ambos.

Bom, às vezes eu tenho vergonha de interromper as pessoas e pedir que repitam o que disseram, porque eu faria isso muitas vezes. Acredito que muitas pessoas também compartilham desse sentimento. Eu tive um CEO nacional australiano na Austrália que dizia constantemente "por favor, fale devagar e explique novamente porque sou lento e não atendi". Ele se tornou meu herói a partir de então.

Então, acredito que este pode ser um dos gargalos mais importantes a serem removidos quando precisamos construir uma equipe verdadeiramente compreensiva e nivelada para implementar o método Agile e temos que lidar com essas áreas particulares sutis e sensíveis que tocam profundamente nossas almas como colegas de escritório na cultura de uma empresa. Já falamos sobre aspectos como caráter e personalidade em outras LIVES, agora é hora de falar sobre comunicação tida como certa. E eu nem falei do ato de escrever... tanta gente simplesmente não sabe se comunicar direito, nem escrevendo em Inglês, apesar de nativas... Esse é o momento que a gente precisa lembrar todos os dias que estamos em um ambiente profissional, não em casa.

Atividade de Team Building

Uma vez fui escalado para liderar uma atividade de team building. Levei a sério, porque até então tinham organizado atividades bobas como kart, minigolfe ou paintball que me irritavam e eu não participava, apenas para petiscos, bebidas e conversas superficiais, quando existiam.

No meu caso, pesquisei e encontrei um "jogo" muito interessante que era aquele que se jogava num parque. Teríamos uma atividade, ou seja, um jogo, então as pessoas ficariam livres para passar o resto das horas comendo, conversando, descansando na grama sombreada à beira do lago ou jogando futebol (como realmente faziam).

O jogo foi o Labyrinth Team Building Game (Jogo Labirinto de Formação de Times), que é um desafio de coçar a cabeça, onde as equipes trabalham juntas de forma rápida e eficaz para atravessar um labirinto de quebra-cabeças e obstáculos.

Benefícios do Labirinto

• Melhorar as habilidades de comunicação e colaboração
• Construir confiança no local de trabalho
• Ilustrar o valor das funções dos membros individuais
• Demonstrar a importância da gestão do tempo e dos prazos
• Melhorar as habilidades de resolução de problemas

O coordenador do evento dá as boas-vindas ao grupo e coloca todos em equipes aleatoriamente (sorteados). Os participantes podem esperar enfrentar uma série de quebra-cabeças e desafios que testarão sua engenhosidade, resolução de problemas e habilidades de comunicação. O trabalho em equipe é absolutamente essencial para completar os desafios dentro do melhor cronograma. As equipes enfrentarão todos os tipos de barreiras em seu caminho pelo labirinto. Pontes precisarão ser construídas, portões desbloqueados e teias negociadas.

A atividade exigiu a preparação de uma pista construída com caixas de papelão e todo tipo de obstáculos pré-preparados. Entramos por um lado e saímos pelo outro. No meio, havia um tortuoso caminho labiríntico que o participante deveria percorrer até chegar ao final da pista. Os grupos incluíam 2 pessoas: 1 para percorrer o caminho e a outra para dizer a esta o que fazer, pois o caminhante estaria com os olhos vendados!

O caminhante deve seguir o que o comandante diz e assim sentir-se seguro até o fim. O vencedor seria a dupla que terminasse no melhor tempo com menos erros. Foi muito divertido, mas infelizmente os resultados não foram apreciados como deveriam. Nem mesmo o diretor levou a sério a importância da atividade.

Destaques

A perfeição da comunicação - um dizia palavras, e o outro entendia perfeitamente para executar os passos exatamente como o comandante dizia de forma rápida. Pois bem, isso mostrou que não só as pessoas tinham dificuldades para se expressar racionalmente como a outra parte não entendia muito bem o que era dito e fazia a coisa errada. O destaque não estava em quem estava errado, mas na eficácia do método de comunicação.

Os comportamentos - alguns teriam pressa em ser o mais rápido o que comprometia a perfeição, os faria tropeçar, chutar e até cair, enquanto outros teriam muito cuidado para prosseguir, com medo de fazer algo errado e atrasar os resultados. Os apressados ​​não dariam tempo para o comandante corrigir sua trajetória, e os muito lentos demonstrariam não confiar nas palavras do comandante. O melhor seria aquele que entendesse perfeitamente os comandos bem definidos e claros.

Resultados

No final, duas duplas foram vencedoras sob protestos porque o diretor escolheu a mais rápida, independentemente dos erros em profusão, mas a próxima mais rápida, porém mais correta, revoltou-se. Os vencedores ganharam alguns benefícios monetários.

Isso avaliaria o conhecimento para ser usado no escritório, mas nunca mais ninguém falou sobre isso, assim como trataram o kart e paintball, atividades que serviam apenas para reunir pessoas que, de outra forma, nunca passariam algum tempo juntas fora as horas de trabalho. As outras atividades eram churrascos, almoços e jantares, nada realmente profissional como a minha proposta. Foi realmente decepcionante perceber que meu trabalho não foi valorizado como deveria.

Levando isso para o trabalho, os vencedores seriam aqueles que entregassem no prazo, independentemente da correção, qualidade e integridade. Os mais responsáveis ​​que se importassem com isso seriam punidos por eventual atraso ou correção de trajetória nos cronogramas do projeto. Isso representava a cultura da empresa. Uma vez os usuários disseram que preferiam um atraso do que um sistema defeituoso. Eles foram ignorados porque a empresa global Forbes tinha a reputação de sempre entregar no prazo, não importa o que aconteça, mesmo deixando as correções serem feitas depois, o que podia sair muito caro.

Isso vai totalmente contra o conceito Agile que não segue um projeto Waterfall (Cascata) pré-aprovado e estanque!... É outra preocupação para a empresa que me convidou e com a qual estou compartilhando!

Abraços.

Qualidade do Jeitinho Brasileiro VI

Todos nós somos iguais

Como mais um episódio da série Jeitinho Brasileiro, gostaria de acrescentar aqui outras implicações, não propriamente do "jeitinho brasileiro no exterior", porém mais pelo lado do "Espiritismo brasileiro no exterior".

Porque o Espiritismo respeita as pessoas e nos ensina a tratar todo mundo igual, do mesmo jeito, não importando raça, cor, credo, cultura nem vestimenta. Me gabo de conseguir fazer isso sem esforço já faz muito tempo desde que deixei os cueiros e de achar que pobre era outra raça no Brasil, logo ao entrar na adolescência como um conservador branco, racista e reacionário (direitista) cheio de titica-de-galinha na cabeça e uma jactância de quem já se considerava adulto aos 14 anos.

Pois bem, aqui no exterior, e no meu trabalho, de vez em quando aparece um bicho papão anglo do cliente que todo mundo fala mal dele como intragável e intolerante. 

Grumpy, o anão Zangado de Branca de Neve

Geralmente são os caras que lidam mais de perto com os contratados como nós, são caras especialistas que conhecem o trabalho e o sistema muito bem e muito mais do que os outros que geralmente são bonzinhos e tolerantes por causa disso, com muitos anos de conhecimento e experiência, e o principal fator do cara ser antipático é porque ele com frequência discute com os contratados que geralmente não conhecem tanto o ambiente quanto ele, o que o faz detectar quando os outros estão mentindo ou inventando desculpas, o que o irrita profundamente. A constância das tentativas de ludribiá-lo com meias-verdades anos após anos acabam formando sua fama de "grumpy" (enfezado), que espanta todo mundo.

É quando chega o brasileiro "espiritualizado" com seu "jeitinho" à tira-cólo e entra em cena. Seu princípio de vida é o da transparência, ou seja, ele diz o que sabe e o que não sabe sem medo de represálias ou de falsas avaliações porque acredita na honestidade de princípios. É o preto-no-branco, ele é ele mesmo, autêntico, mata a cobra branca e mostra o pau preto (ou seria o contrário?).

Daí, este brasileiro vai descobrindo que o bicho papão, de animal selvagem, não tem nada, que ele não consegue se indispor com o apregoado antipático, e ao contrário, parece que sempre é muito bem recebido e merece boas e autênticas explicações, com direito a piadinhas e tudo, sobre seja o que forem suas indagações, vindas de um real especialista que conhece do negócio, sabe das coisas e sabe explicar também. O cara conhece o negócio dele e sabe como levantar... polêmicas.

Então, quando alguém relembra de novo a antipatia do sujeito numa reunião, o brasileiro diz, humildemente, ué, comigo ele nunca foi antipático, muito pelo contrário. 

Olhos em brasa lhe fitam de cima abaixo a dizerem em silêncio, quem é este mexicano insolente, mal-educado, atrevido, prepotente, ensimesmado, arrogante, orgulhoso, indômito, emproado, túmido, empafiado, snob, ventoso, topetudo, desdenhoso, esnobe, rompante, ostensivo, metido, jupiteriano, inflado, prepotente, convencido, jactancioso, fátuo, entufado, amaneirado, nojento, pedante, presumido, assoberbado, sobranceiro, pretensioso, presunçoso que se atreve a nos desdizer em público, na frente de todo mundo?

Ora, ele sempre é legal comigo, desculpem, perdoem, clemência...

O barbudo velho Karl Marx

Certa vez fui exposto a uma clara altercação com um destes sujeitos considerados crápulas emproados e aterradores. Fui jogado numa sala fechada a fim de discutir um assunto altamente polêmico em que ele não se convencia de jeito nenhum que estávamos fazendo a coisa certa. 

Sem me alterar, porque para mim todo ser humano é sempre igual, é só esperar o efeito do ecstasy passar, depois que ele, bem enfezado, expôs o problema no quadro-negro-branco com seus riscos e arabescos irritados e do alto de seu porte gordo e imenso, ocupante de um grande espaço físico no meio daquela barba branca de Papai Noel, comecei a minha explicação humildemente, riscando aqui e ali, porém assertivamente alfa e sem titubeio, porque eu sabia do que estava falando.

Discussão vai, discussão vem, tendo suas várias tentativas de me derrubar nalfragado, e a fera vai amansando. Vai enxergando a razão das coisas, ligando os pontos com sensatez, enquanto, para todas as questões levantadas por ele em cima do seu mal humor, eu tinha uma resposta clara e lógica na ponta da língua para arrotar, de quem sabia das coisas... também. 

Se atreva a provar que estou errado...

O bate-boca não durou muito, e logo o leão está manso, e chega até a esboçar um sorriso e dizer uma piadinha no final. Quando acabamos, ele fica de acordo com meus argumentos e reconhece que não havia pensado a coisa sob aquele ângulo... pra esquerda. 

E assim eu provo mais uma vez que não existe bicho papão no trabalho, apenas chefes que se irritam com as tentativas dos subordinados de enganarem eles achando que chefes não trabalham e não sabem de nada, aquela velha crença dos perdedores.

Mas é verdade, todo mundo que é sensato e tem fama de intragável, comigo amansa. 

Qualidade do Jeitinho Brasileiro IV

Continuação...

Esqueci as mais importantes vitórias do "Jeitinho Brasileiro" em nossa equipe de trabalho.

Um pouco de teoria chata.

Dentro do SLDC (System Development Life Cycle - Ciclo de Vida do Desenvolvimento de Sistema) tínhamos os seguintes "deliverables" (produtos a entregar):

• US - User Specifications (Especificações do Usuário)
• IA - Investigation Analysis (Análise e Investigação)
• DD - Detailed Design (Desenho Detalhado)
• P&UT - Program and Unit Test (Programa e Teste da Unidade)
• AT - Assembly Test (Teste de Interfaces)
• RT - Regression Test (Teste de Regressão)
• PT - Partido dos Trabalhadores, digo, Product Test (Teste de Integração)

Todos passos caracterizados por um "deliverable" (documento a ser entregue) ao cliente para aprovação, todos dependendo do passo anterior sem o que não podia-se prosseguir. Tudo muito metódico e científico.

Este era o padrão da empresa e de todas as empresas que trabalham com IT (IT-Information Technology - TI-Tecnologia da Informação). É um padrão criado para o desenvolvimento de projetos baseado na prática, é claro. Um padrão que não serve para Suporte à Produção.

Um concerto para consertar sua mente e seu humor

O Desenvolvimento parte do nada para entregar uma coisa nova. O Suporte à Produção parte do que já existe para entregar um conserto. O Desenvolvimento cria à vontade, o Supporte à Produção remenda o que já foi mal-criado.

Para o Desenvolvimento é mais fácil lidar com estimativas de custos e recursos necessários à execução do projeto novo, mas para o Suporte à Produção é necessário conhecer-se a fundo o que existe para ter-se uma noção exata dos custos e recursos necessários para remendar. Dificilmente alguém consegue este nível de conhecimento, exceto os funcionários com mais de 15 anos na empresa (e ainda existem alguns), quando os sistemas e ambientes são muito complexos.

O Suporte à Produção investiga um problema existente e descobre a raiz da causa (root cause) e ponto final. Quem vai descobrir a solução ou como resolver o problema é o Desenvolvimento. Eventualmente podemos fazer isso também, mas em muito menor escala.

Filme IA, Inteligência Artificial, que não é o documento sobre o qual
estou falando

Mas o documento IA (Investigation and Analysis - Análise e Investigação) era um produto para todo mundo. Este documento descreve o problema, a solução e determina as estimativas de custos e recursos necessários (pessoas) a fim de viabilizar a implementação da solução. Este documento também responde a cerca de 150 perguntas ou mais, relativas ao que mais é preciso atualizar junto com a solução, como por exemplo, atualizar:

• Manual do Usuário
• Manual Técnico
• Online Help Page (Página de Ajuda Online)
• Especificações do Módulo
• Definições e Descrições de Telas
• SQLs de Leitura ou Modificação dos Dados
• SQLs dinâmicos (montados quando executados através de parâmetros)
• Scripts
• Verificadores de Dados
• Desenho do Sistema
• Definições de Objetos de Interação com Usuário
• Desenho e Esquema de Tabelas de Banco de Dados
• Necessidades de Tipos de Testes
• Montagem da Documentação Geral do Módulo
• Desenho Detalhado da Solução
• Conversão de Dados
• Documentação do Sistema em Alto Nível
• Documentação do Sistema em Detalhes
• Etc

Estas dezenas de documentos eram espalhadas pela rede (network) de modo que ninguém sabia ao certo onde estava cada um dos tais documentos a fim de estudá-los e avaliar se eles necessitavam ser atualizados ou não. Alguns documentos eram armazenados em ferramentas de desenho de sistema, fora da network. Isso nos fazia perder um tempo enorme procurando. Por mais que se escrevesse um guia de como achar os documentos, de um ano para o outro eles já haviam mudado de lugar, de formato, de versão, era um caos total. Uns pecam por falta, outros pecam por excesso...

Mapa da Mina

Veja aqui como resolvi o problema da multi-documentação, com meu Indiocy (nome fictício)...

http://conypre.blogspot.com.au/2014/12/estilista-frustrado.html

Não Ria

Ora, se não estamos acostumados a desenvolver, também não temos noção de como estimar custos e pessoas e não precisávamos de toda aquela informação àquela altura do campeonato. Porém, tínhamos a obrigação de inventar e convencer porque o documento era assim e era o único a servir para dar o diagnóstico do problema.

Quando entrei na empresa dei de cara com a necessidade de entregar estes tipos de documentos sob o ponto de vista do Suporte à Produção para o qual fui contratado devido ao nível de minha experiência. Acontece que, mesmo com toda a minha experiência, era difícil para mim avaliar quantas pessoas seriam necessárias para sanar um problema, e também quantas horas seriam gastas naquela instalação e naquele ambiente informático com aquele nível de especialistas. Eu mal conhecia os caras, quanto mais saber sobre a competência deles.

Minhas primeiras experiências foram desastrosas. Pela minha experiência, X dias e Y pessoas resolveriam um problema. Na prática, acabamos por furar todos os prazos estipulados porque tudo era sempre muito mais complicado na Austrália do que eu já havia visto na minha vida. As mínimas tarefas eram complicadíssimas. Por exemplo, atualizar um manual, que devia levar dois dias, acabava levando 10 dias. Um teste que deveria durar algumas horas, durava 3 dias. Um conserto numa linha de código que deveria durar 10 minutos, acabava varando noite adentro.

Arrancando os cabelos...

Depois de arrancar alguns fios de cabelos (eu ainda tenho cabelos), comecei a ladainha das reclamações bem brasileiras. Mas isso não pode ser, isso está errado, isso é impossível de fazer, vocês são uns exploradores, tem milhares de documentos inúteis, e saí desfiando o rosário. De tanto eu falar e ter razão, o chefe resolveu quebrar a rigidez das normas e procedimentos vigentes em toda a empresa global, e inserir um novo "deliverable" no meio da corrente de documentos. Ele reconhecera a necessidade e eu participei da criação daquele documento, inclusive escrevendo um guia de preenchimento.

Este novo documento chamou-se RIA (Result of Investigation and Analysis - Resultado de Investigação e Análise, nome fictício, não ria). Este novo documento era uma IA sem a parte das estimativas. Foi um alívio para todo mundo. Não era preciso mais arrancar-se os cabelos e a tarefa foi passada para quem tinha mais experiência na área de planejamento. Nossa experiência se resumia à investigação de problemas existentes e identificação da raiz deles.

De modo que sou o pai biológico do RIA (não ria), que foi criado por outro pai com "recursos maiores" para isso. Realmente, ele é mais alto... Este documento tem-se provado muito útil e fundamental, além de ter agilizado o processo de identificação das raízes do problema, o que facilita o processo de desenrolar uma solução. É um tal de RIA pra cá, RIA pra lá, o tempo inteiro e todo dia, o RIA virou uma estrela sem tatuagem de estrela. Os analistas de Desenvolvimento não precisavam mais estudar as causas, e nós do Suporte à Produção não precisávamos mais inventar estimativas irreais.

Davi e Golias, não ria...

Uma simples mudança que demorou para ser implementada porque ia de encontro aos procedimentos estanques inventados pela teoria de sistemas das universidades mundiais. Ainda hoje, ao argumentar que o RIA modificou os tais procedimentos com o chefe, uma vitória minha, ele diz que tal documento não faz parte do SLDC, e realmente não faz. Faz mas não faz. Ele é fundamental no ciclo, mas porque não veio da universidade, então ele não existe.

Enfim, mais uma briga vencida pelo jeitinho brasileiro do David contra o elefante branco Golias. Só faltou eu lhe arrancar a cabeça...

Dados armazenados

Validação de Dados

Aprendi na escola que os dados deviam ser armazenados numa biblioteca chamada repositório de dados (eu falei repositório, não supositório) com tudo relativo a cada dado para ser facilmente acessível, mas em toda a minha carreira profissional jamais vi tal coisa na prática. Será que existe em algum lugar? 

Só no Suporte à Produção é que a gente descobre a importância de saber o que pode ser armazenado num item de dado ou não, e sob que condições. Geralmente isso pode ser encontrado nas especificações do programa ou no código do programa, o que não é exatamente fácil de se achar durante investigações para achar a razão dos problemas. Apesar de toda a documentação regulamentar acerca dos dados no nosso time, não é fácil consultar-se. O mesmo acontece com as relações entre os dados no banco de dados relacional. Precisamos saber se, quando modificamos um dado, quais são as implicações nos outros dados relacionados, e em que circunstâncias podemos modificar um dado ou não, sem ter sido através do sistema.

Pois bem, também construi tabelas de fácil acesso para os dois casos, e fui catalogando as regras de validação fora das especificações de cada programa, num lugar próprio dos dados, sob o ponto de vista dos dados, pois computação não passa de um jogo de dados... a isso eu chamo de Administração de Dados, mas isso não é o que este termo significa. Este termo significa criar bancos de dados, copiar, criar tabelas, destruí-las, administrar a perfórmance do banco de dados, mas gerência de conteúdo dos dados não faz extamente parte do menu deles. 

No Brasil trabalhei num banco que realmente tinha uma administração de dados sob o ponto de vista dos negócios. De lá pra cá nunca mais vi tal coisa, embora ela faça parte da teoria que se aprende nas universidades.

Dessa forma foi fácil construir modelos de procedimentos sem ferir a integridade das relações entre os dados que são muito sensíveis. A alternativa era um quadro impresso com 1 metro e meio de largura, por 1 metro de altura, mostrando todos os diagramas e ligações entre as chaves das tabelas através de quadrados e linhas. Tenta perseguir aquelas linhas sem se rasgar todo e cair no chão batendo e dizendo "eu odeio Dilma"...

Multiplique este diagrama 10 vezes e coloque na parede. Dá um
bom enfeite e faz a gente parecer inteligente...

PRFF

Em contrapartida ao RIA, vejam o que a empresa saltou como solução para um probleminha.

A PRFF é um formulário de revisão que é preenchido toda vez que um documento é revisado. Os erros detectados são escritos lá e, quando resolvidos, dados baixa. Posteriormente tal formulário serve para obter-se estatísticas de perfórmance, percentuais de erros e acertos que, teoricamente, denotam o grau de especialização dos funcionários. Tal formulário foi introduzido "globalmente" e tivemos que nos submeter à sua soberania.

Pois sabem o que aconteceu?

Os super-diretores cairam de pau no nosso diretor porque o formulário não estava dando os resultados esperados por eles e suas equipes de auditoria. 

E por quê?

Porque não é possível que vocês tenham esse nível tão baixo de erros durante as revisões. Vocês estão sonegando informações, são corruptos...

Silêncio profundo...

Mas meu senhor, isso tudo é verdade.

Mentira, seu percentual de erros deve ser muito maior, conta
essa história direito

Não senhor, vocês estão mentindo e escondendo o jogo. E foi um bafafá pra lá e pra cá até eles serem convencidos de que a gente realmente não errava... que nossas estatísticas de erros estavam muito abaixo da média mundial, e que não era mentira, era tudo verdade.

Uma das coisas que havia reduzido muito os erros de revisão foram os modelos com comandos para solucionar incidentes. Como os documentos gerados pelo modelo eram padrão e já haviam sido testados, então não precisavam ser revisados, mas apenas os dados adaptados à situação, o que tornava tudo muito fácil e preciso. Portanto, os documentos extras, fora dos modelos, eram os únicos a sofrerem revisões e conterem possíveis erros.

Acabaram se convencendo de que éramos os super-homens e nos colocaram num pedestal como uma das melhores equipes de Suporte à Produção jamais conseguidas pela empresa mundial.

O Time do Tigre

No ano passado me lançaram de paraquedas na liderança de um time de urgência a fim de reduzir o tremendo número de problemas pendentes no sistema que já estava dando na telha, até por minha própria culpa de ter descoberto e denunciado muitos problemas com sintomas diferentes e mesmas causas. Aquela fila de problemas não eram reais, era preciso dar um pau nela, e ninguém melhor do que eu para resolver o problema.

Então me deram subordinados insubordinados, ou seja, mal treinados, sem especialização, para eu treiná-los "on the go" ("no uso").

Fox Tiger (Raposa Tigre), de LouieLorry, DeviantArt

Sucesso, meus camaradas. Posso trabalhar até com o diabo que consigo fazer dele gente. Afinal, sou brasileiro, famoso por resolver qualquer parada, se você não sabia disso. Meus colaboradores me surpreenderam.

Em quatro meses reduzimos de 730 problemas para 72. Nem mesmo eu estava acreditando. Acabamos com todos os problemas de duas áreas, banco de dados e arquitetura, o resto eram problemas do aplicativo e só sobraram os piores, os mais difíceis de terem descobertas as causas. São com estes que estou trabalhando agora...

Portanto, se você não anda funcionando bem, eu dou um jeito em você... grawwr!

Continua...

Qualidade do Jeitinho Brasileiro V

Continuação...

Hoje houve desdobramentos enquanto eu terminava esta série de posts. 

Numa reunião de alto nível, nos foi repassado que, dos pontos tocados em como trabalhar com a maior perfeição, o Gerenciamento de Incidentes passou com nota quase 100. Segundo a responsável, ela recebeu congratulações das diretorias via email logo cedo.

Também nos foi repassado que uma das minhas iniciativas de controle de incidentes, a qual foi lembrada que eu havia apresentado e sugerido aos outros times utilizarem o mesmo esquema há três anos atrás porque estava funcionando às mil maravilhas, e havia sido ignorado, agora vai ser imposta para todos seguirem obrigatoriamente. Uiiii, essa doeu...

Um jovem novato, herdeiro do meu reino, treinado pela minha treinada, está a organizar reunião com os outros times a fim de re-apresentar a ferramenta pra eles, que agora vão ter que se submeter. O pessoal de arquitetura e banco de dados costuma ser avesso à documentação, são mais como "free-ranges" (galinhas criadas no terreiro).

Não sei nem como o autor da medida foi lembrado em público, deve ter sido um deslize, porque a cultura deles não é muito boa em reconhecer trabalho bem feito nas origens, só nos resultados, nos lucros, no dinheiro. 

Certa vez me deram um prêmio de fim de ano, mas ao invés de ressaltar exatamente estas tais medidas, o motivo foi o número record e impressionante de incidentes resolvidos por mim em um ano, baseado no que foi registrado. Tenho pena deles, porque a outra metade não havia sido registrada já que a resolução havia sido através de instrução, ou seja, aquilo era só a metade do que eu merecia e mesmo assim foi impressionante, e eu só havia conseguido aquilo justamente pela metodologia que implantei à revelia. Foram cerca de 340 incidents resolvidos naquele ano, mas nos 6 anos na área, o total sobe para mais de 3.000, e ainda sou o campeão de um belo campeonato.

Eles, por exemplo, são incapazes de reconhecerem que aquela gerência só está trabalhando assim, à beira dos 100% dos pontos de qualidade, por causa das minhas iniciativas e das minhas soluções implantadas por mim mesmo quando eu era o tal gerente, o qual treinou esta pessoa que tem assumido esta função nos últimos dois anos. 

A gerenta atual foi treinada para usar as minhas metodologias e ferramentas que hoje estão começando a fazer sucesso publicamente por causa do reconhecimento vindo de fora, de mais alto nível baseado nos resultados, mas poucos se lembram de parabenizar-me por ter pensado e executado as soluções. Afinal, para eles, dobrar-se à minha excelência brasileira, controvertida e contestadora, fora do padrão, para muitos é reconhecer que eles tem sido uns... assholes, dickheads (procurem no dicionário). Já ouvi indiretas do tipo "conseguiu mas por meios não ortodoxos" ou coisa parecida.

A Última Tentação de Cristo, filme de 1988, de Martin Scorsese com 
Willem Dafoe e Harvey Keitel

Quando você agrada os pobres e desafia os ricos, definitivamente você não tem IBOPE. A gente tem que dar uma de Jesus Cristo mesmo, morrer pelado na cruz.

Mas de todo jeito, fez bem ao meu ego vir a saber que tudo isso está acontecendo, e muito mais ainda está por vir, se bem que acho que não estarei mais lá no dia em que uma estrela cair do céu e eles resolverem reconhecer minha contribuição ao longo dos anos. Meu tipo de trabalho só dá resultados depois de anos consertando cada detalhe fora de lugar, imperceptivelmente.

Sim, estou meio "arretado" hoje porque foi um dia muito "busy", cheio de reuniões com decisões minhas a serem tomadas, convencimento aos incrédulos, e ainda tendo que lidar com as demandas, pois quando as pessoas começam a acreditar num projeto, elas vão longe e se mostram cheias de desejo.

Público cheio de desejo do Black Sabbath na praça da Apoteose,
no Rio de Janeiro. Foto Julio Cesar Guimarães/UOL

Não dá para contar tudo, eu nem me lembro, mesmo que tenha escrito um compêndio que um dia, quem sabe, poderá se tornar um livro.

O que mais me irritou hoje foi a briga de egos com o meu chefe. Já contei algumas coisas sobre o seu jeito, e hoje eu abri o verbo porque houve chance. Espero que isso já faça parte da nova maneira "direta e pessoal" de avaliar os recursos humanos, depois que a empresa acabou de abandonar o método de avaliação irritante que executava até então.

Enfim, ainda existem revoluções após outras a acontecerem antes do Armagedom, mas o que eu desejava até aqui, consegui. 

Gargalo não é galo cantando e gargalhando...

Só podíamos pensar no futuro assim, seriamente, positivamente, e com entusiasmo, se resolvêssemos nossos principais gargalos a fim de nos dar tempo livre para sonharmos acordados. Isso está acontecendo.

Só podemos nos divertir quando estamos de barriga cheia, caso contrário só pensamos em comida.

Isso é tudo o que deu pra lembrar, mas com certeza teve e terá mais...

Conclusão com Jeitinho

Estes são apenas alguns exemplos do que um brasileiro pode ser capaz de fazer no exterior, ganhando todo mundo com nossa "miscigenação", tolerância, e um jeitinho cativante.

O "jeitinho brasileiro" não tem nada de malandragem. Quem assim o proclama tem complexo de inferioridade e quer desprezar a cultura nacional. 

É intriga da oposição, vamos valorizar o que é nosso, aprimorá-lo e vendê-lo. 

Mas com decência como nesta música de Lucas Lucco, Homem É Tudo Igual:

https://www.youtube.com/watch?v=DIVTPKlD7bU

Um retrato dos machos brasileiros jovens de hoje, mas o recado não é esse, o recado é outro quando Lucas diz, "homem é tudo igual até achar a mulher ideal", e mais quando diz "mas eu sou diferente, hein?". E prestem atenção no detalhe dos "erres" deste sujeito. Apesar das baixarias que ele tem lançado, das tatuagens exageradas e dos selfies, ainda dou crédito a este rapaz por causa destes pequenos detalhes que para mim denotam caráter.

The End

Qualidade do Jeitinho Brasileiro III

Continuação...

Avaliação: Fora do Normal, Muito Boa, Satisfatória, Razoável e
Insatisfatória

Múltipla Escolha

Nosso "jeitinho brasileiro" também introduziu partes nas pesquisas onde as pessoas podiam expressar suas opiniões ao invés de apenas selecionarem opções estanques de múltipla escolha. 

Tais opções em geral nunca cobrem o universo e muita gente se sentia obrigada a optar por uma coisa com a qual não concordava só porque sua opção não estava presente, resultando em falsos resultados e falsas decisões baseadas em falsas pesquisas. Pareciam até as pesquisas sobre a quantidade de ativistas protestando nas ruas brasileiras contra o governo ou sobre a aprovação do governo, feita com 300 pessoas das elites. 

Os quadros de textos com a opinião de cada um aumentaram muito mais o trabalho dos pesquisadores (que devem ter ficado com ódio de mim), mas só então os resultados começaram a retratar a realidade da empresa, e as decisões começaram a ser mais lógicas. Passou-se a enumerar-se os pontos mais frequentes escritos pelas pessoas, sumarizando-os, a fim de serem atacados em sequência e, de preferência, sanados.

É engraçado como todo mundo concorda com minhas opiniões mas parecem incapazes de verbalizá-las como eu. E nessa língua maldita...

Os Jovens

Jovens com muita bola e a boca no trombone como os 
protestadores das ruas brasileiras

Uma coisa ficou evidente: o que mais reclamaram foi de falta de treinamento. A empresa encoraja o auto-treinamento da pessoa lhe disponibilizando cursos online, mas os cursos são tantos que as pessoas se perdiam quando tentavam selecionar os mais acertados, além de perderem mais tempo procurando do que estudando. 

Era preciso lhes orientar. Então um grupo atacou este problema e passou um ano tentando construir uma tabela de cursos indicados. Não conseguiu. 

Foi quando chegou a minha vez de dar meu precioso pitaco, que foi o seguinte: minha gente, quem clama por treinamento são os jovens, os récem-contratados. Eles nunca estão satisfeitos com nada. Não adianta dar-lhes um mapa da mina porque nunca vai ser o bastante para eles, eternos insatisfeitos, loucos para ganhar promoções rapidamente, que se não vierem, eles mudam de empresa. Há problemas mais sérios que devem ser endereçados antes de se perder tanto tempo com estes fedelhos que andam ganhando a parada de botarem a boca no trombone.

Fui preso porque pensavam que eu estava dando uma de homofóbico... brincadeirinha.

Como Você Responderia a Esta Pergunta?

Lhe convidam para um banquete da empresa, mas para evitar problemas de saúde, lhe pedem para dizer se você tem alergia a alguma coisa, de modo a eles evitarem lhe expor a risco de vida e evitar-lhes sofrerem um processo milionário. Então eles fazem uma pesquisa ao mesmo tempo em que você atende ao convite assim.

Vocé é alérgico a:

• Lactose
• Peixe
• Lagosta
• Castanhas
• Nenhuma das opções acima

Você é alérgico a amendoim, o que responderia? Qualquer resposta aqui seria falsa e lhe deixaria em risco de vida, mas sua opção tinha que ser "Nenhuma das acima". Uma pesquisa mais inteligente seria:

• Outros, especifique

Um elefante alérgico gay incomoda muito mais. (Amendoim não,
sou alérgico!! Favor não me alimentar). Sou delicado e 
não só como você...

Você então escreveria "amendoim". Se eles não pensaram nisso, pensarão na próxima pesquisa e descobrirão que muita gente tem muitos outros tipos de alergia como jamais eles poderiam imaginar. Esta semana soube de alguém alérgica a maçã.

Na primeira pesquisa assim, as respostas seriam extraídas do computador imediatamente. No segundo caso, seria preciso examinar cada respondente pois eles podiam não usar as mesmas palavras para dizerem as mesmas coisas e a inteligência artificial dos computadores ainda não chegou a este ponto de sabedoria. 

Eles poderiam escrever mandioca, macaxeira, aipim ou inhame, cará, taro, ou mexerica, laranja-cravo, mandarina, vergamota, jeruk keprok, يوسفي, 橘子, significando a mesma coisa. Ou seja, os resultados não seriam imediatos e os funcionários teriam que analisar e gastar tempo para produzirem um diagnóstico mais preciso. Imagine que estas pesquisas são contratadas a outras empresas, e o dinheiro fácil que elas ganhavam até então, para darem resultados imprecisos. Agora têm que suar mais...

Excesso de Recursos Difíceis

Outra falha do elefante: contratava várias empresas para cada uma construir um sistema diferente e independente para folha de ponto, requisições de férias, contracheques, treinamento, etc, e nenhum era compatível com o outro, ou seja, nós, funcionários e seus usuários, atirávamos pedra pra todo lado de ódio cada vez que precisávamos utilizá-los e eles não funcionavam, entupindo o callcenter da empresa com reclamações para ouvidos moucos e passando os dias emburrados.

Os Insaciáveis

Tempos atrás a empresa lançou várias formas de informar os funcionários, gerando o que considero hoje um excesso de "spam" em nosso email empresarial. Chegou a um ponto em que meu chefe, por exemplo, só aperta o "delete" o tempo todo, e com isso perde muitos convites para eventos que voaram na orgia das deleções. Eu falei orgia de deleções, não orgia de delações... 

Mas me diga uma coisa, trocar vantagens por delações não é corrupção?

Mesmo assim, como resultados das pesquisas, os funcionários diziam continuar insatisfeitos com o nível de informação que recebiam. Ora, para mim, um profissional experiente, era excesso de informação. Mas sei que para os jovens, nunca nada é o bastante porque eles tem sede de crescimento, eles têm urgência de incrementarem seus currículos, de obterem promoções. Eu era assim também, mudava de emprego quando demoravam para me promoverem.

Excesso de informação que só os jovens conseguem lidar,
ao descartarem muita coisa séria sem sequer tomarem
conhecimento

Acontece que, ao perguntarem aos funcionários o que eles gostariam que a empresa fizesse para eles estarem satisfeitos, uma das coisas que sempre diziam era que tinham interesse em saberem os rumos da empresa, tendo acesso ao máximo de informação possível. 

A empresa os atendeu, mas segundo as pesquisas, eles continuavam insatisfeitos. A empresa já não sabia mais o que fazer. Foi quando eu disse que, exigir informação era coisa de jovem e haviam muitos jovens na empresa, mas atender às suas ânsias não os ia fazer ficarem satisfeitos. Era preciso entendê-los melhor.

Daí me prenderem por apresentar sintomas de jovemfobia... brincadeirinha.

Excesso de Informação

O resultado foi que as informações passaram a ter mais conteúdo sério e outras atitudes foram tomadas para antender às ânsias dos funcionários, entre elas um excesso de comemorações de dias como o da mulher, festividades e feriados multi-culturais e engajamento no movimento LGBT, além de promoção de vários eventos esportivos entre os funcionários, oferta de promoções e ingressos de eventos e shows com desconto, concursos de fotografia e invenções, competições e mais uma pá de abobrinhas, coisas triviais que me enchem o saco, mas com as quais os tais jovens ficam embevecidos nesta cultura que idolatra a trivialidade, tanto é que uma das instituições australianas é a tal noite de "trivia", uma espécie de bingo muito difundido principalmente entre os aposentados. 

Ora, seria muito melhor distribuir este dinheiro gasto com estas coisas supérfluas e gratificar os tais jovens e consequentemente os maduros também, mas até nessa seara eu entrei de sola e descobri que existe uma barreira bem clara que é intransponível, dito por um diretor, falando bem claro em nossa reunião do jeito que eu imprensei ele pra responder. Dinheiro não, outra coisa qualquer, menos isso. Tudo menos isso!!! Quer cartão, quer plaquinha? Diga, meu amor...

Bem, há de se convir que ainda temos emprego na Austrália, mas que todo dia levas de desempregados enchem as ruas ou aceitam trabalhos casuais, parciais e mal pagos, ou então se mudam para países como México (vindos dos Estados Unidos) e Índia (vindos da Austrália), Filipinas, Malásia ou Indonésia. A empresa é bilionária mas só o é por causa do arroxo salarial... global...

Só agora, finalmente, surgiram com a idéia de valorizar os mais experientes que não respondiam às tais pesquisas. Os jovens foram rebaixados de seus privilégios de serem contratados ganhando mais por períodos limitados, mas seus contratos pelo menos foram extendidos e seus períodos "no banco" (à espera de contratos, remuneradamente) reduzidos, na política de procurar manter a mão de obra especializada por mais tempo.

A empresa estava se tornando refém das demandas dos jovens que gritavam mais alto, achando que era todo mundo igual, assim como o mundo de hoje está virando refém de certas minorias...

Daí eu fui preso... brincadeirinha...

Testes

Dentro dos meus planos mais a curto prazo está a sofisticação dos testes. Testes sempre foram muito bem organizados na empresa, como eu nunca havia visto antes, porém não automatizados. Aliás, ao trabalhar na primeira empresa na Austrália, lá havia scripts de testes. O usuário testava e tudo era gravado. Quando surgia um problema, nós, técnicos, podíamos repassar todos os passos que o usuário havia feito e descobrir exatamente onde estava o erro, como num vídeo-tape. 

Exemplo de script de teste, faça isso, faça aquilo, nessa ordem
e você obtém aquilo outro. Senão, é erro.

Em alguns lugares os testes já estão bem sofisticados, mas nós não podemos nos sofisticar muito e temos que ir na rabeira da tecnologia por causa de uma série de restrições ligadas ao fato do sistema ser crítico.

O que temos são scripts escritos, passos para se usar o sistema e testar cada componente. Mas as pessoas nem sempre os escrevem muito bem, e isso dá gargalo, ou seja, gente que não consegue executar os scripts corretamente porque falta informação. É que quem escreveu sabia, mas supôs que quem ia executar também sabia. Ledo engano.

Isso atrasa os testes e também pode comprometer os resultados, se o testador desistir de seguir à risca e pular passos para terminar logo, ignorando possíveis erros.

Ao testar o sistema, os testadores tiram cópias das telas e colocam num documento anexo ao script que é assinado e computada as horas gastas. Cada erro é registrado, documentado, e reportado para solução imediata ou posteriormente.

São vários tipos de testes, dentre eles UT (Unit Test, teste do módulo), AT (Assembly Test ou String Test, teste de integração do módulo com as interfaces), RT (Regression Test, teste de regressão, ou seja, tudo o que o sistema fazia não deve ser afetado, não pode regredir depois das modificações) e PT (Partido dos Trabalhadores, digo, Product Test ou Integration Test, teste de integração ou produção final, aprovado pelos clientes), dentre outros mais específicos.

Meu "sonho" atual é ver os scripts escritos com perfeição e tendo as "screenshots" (imagens das telas) em meio aos passos e não em outro documento. Isso porque o Suporte à Produção precisa conhecer o sistema a fundo para ser capaz de reproduzir tudo o que o usuário faz, mas como isso é impossível, pelo menos através destes scripts com imagens ele facilmente descobre como realizar uma função do sistema e com isso reproduzir o erro. Manuais de usuários nunca são o bastante pois do jeito que eles não entendem nossa linguagem técnica, nós também não entendemos suas linguagens de negócios.

Software com bug de graça é uma zona.
Ops, tradução errada estilo mídia brasileira.
Tradução certa é: área de software livre
de bugs (erros)

É preciso as pessoas se interessarem por escreverem certo, em "baby language" (linguagem simples) para que qualquer leigo possa executar um script de teste. É preciso que elas utilizem certos padrões como escreverem as mensagens do computador exatamente como elas aparecem ao invés de apenas citarem que "aqui vai aparecer uma mensagem". É preciso padrões para escrever-se teste scripts também a fim de que qualquer um possa escrevê-los com qualidade, qualquer pessoa de qualquer nível de especialização. 

Do mesmo jeito os padrões devem ser seguidos por aqueles analistas de negócio que escrevem especificações de usuário onde a tendência é que escrevam como se estivessem escrevendo um livro. A linguagem não pode ser a mesma, tem que ser estruturada, e haver uma preocupação em ser conciso e prever todas as situações reversas. Por exemplo, quando se diz "faça isso", deve-se dizer também "porque senão".

Criando o Bicho Solto, Liberdade nos Testes

Mal comecei trabalhando na Austrália e já me falaram pra nunca usar a palavra "tests" porque significava "testículos"... tinha que ser no singular... É como tentar entender porque as mulheres se enfezam tanto quando são chamadas de "whores" (putas, prostitutas) mas gostam de ser chamadas de "bitches" (putas, cachorras) ao ponto de algumas escreverem nos vidros traseiros de seus carros "aqui vai uma bitch".

Tente me quebrar, laritas, nem te ligo

Não é que eu goste de criar o bicho solto mas briguei também para introduzir os testes livres na empresa. Hoje os usuários são encorajados a tentarem "quebrar" o sistema quando executam o Product Test pré-programado de aprovação das modificações numa atualização de software. Eles então agem como se estivessem na mesa deles e "fazem tudo errado" como eles sempre fazem mesmo. O sistema tem que admitir qualquer coisa errada que eles façam sem quebrar nem dar sinais de que aquele comportamento não foi previsto. Laritas, nem te ligo...

Quando comecei na empresa, comecei ajudando nos testes que seria a forma mais fácil de aprender o sistema. Mas os scripts eram tão mal feitos que eu errava tudo. Então decidi fazer testes por mim próprio, fora dos scripts, e isso se chama free-testing. Todos cairam na minha cabeça por eu ignorar os "procedimentos" pela primeira vez. Ora, retruquei, veja só como meus testes livres tem descoberto problemas, caso contrário eles jamais seriam descobertos por nós, mas com certeza seriam pelos usuários. Não senhor, isso não é nada benvindo, você está descobrindo coisas que não existem, fique na sua...

Quando eu era menino, aprendi este gesto de passar o dedo sob o
nariz como sendo sinal dizendo que o outro está mentindo,
é verdade?

O conselho deles entrou por uma perna de pinto e saiu por uma perna de pato, senhor rei mandou dizer que contasse quatro, dei um muxoxo e revirei os olhinhos, tsc, tsc...

Hoje, depois de vários anos de insistência, a empresa incorporou os testes livres com os usuários em todas as implementações de versões de software. Os testes livres encontram mais problemas do que os testes programados. 

"Jeitinho brasileiro" aqui de novo minha gente!

Veja só como eram os nossos argumentos: eu argumentava que quanto mais testamos o sistema livremente, tentando quebrá-lo, mais erros a gente conseguia para serem consertados. O argumento deles era: o usuário deve seguir o que é pra ser feito, se ele faz diferente, problema deles, o sistema não tem obrigação de estar preparado e vai dar erro. Meu argumento advogava que sistema não pode quebrar de jeito nenhum e tem que estar preparado para tudo, todas as besteiras e imbecilidades do usuário mais idiota possível. Isso eu trouxe do Brasil. Eles rebatiam que, se o usuário não sabe o que faz e não faz o que está escrito nas regras pra fazer, não pode reclamar de erros e o problema é dele.

Quem estava certo? O ovo ou a galinha? Dá pra sentir o tamanho das diferenças aqui no espaço cultural?

Desça do pedestal, meu anjo anglo, pra eu pegar
você e o ângulo, venha sambar e rebolar aqui na
 minha mundiça cultural...

Eu ganhei. Hoje nós tapamos os buracos e os usuários tem mais liberdade para errarem sem comprometerem os dados do sistema graças aos testes livres em que eles podem fazer o que quiserem sem receio. Me chama de lagartixa, me joga na parede, diz o sistema em êxtase...

Busca-se a perfeição para atingir-se o meio do caminho, é o meu lema, lembram-se?

O que eu trouxe do Brasil mesmo? 

A crença de que devemos fazer tudo o mais simples possível assim qualquer idiota faz o que tem que ser feito corretamente, pois afinal, o que não falta no Brasil é idiota (desculpem, é por falha de educação, pura e simplesmente endêmica). Aprendi isso no primeiro ano de trabalho, ou até na universidade mesmo, no Brasil. 

É o contrário daqui da Austrália em que se exige um absurdo de conhecimento que ninguém tem, porque todo mundo tem um rei na barriga. Derrubar eles do pedestal não foi fácil, mas ainda estou tentando.

É bem típico da personalidade anglo exigir o máximo de tudo, ser mais especialista do que o outro de modo que o outro nunca saberá tudo o que você sabe, e com isso você se sente o rei da cocada. Você é mais socialista quando pensa nos menos favorecidos...

Pavor de Rato

Outro detalhe: tem usuário que não usa o mouse, só usa as teclas. O sistema tem que estar preparado para isso, mas não está porque ninguém nunca pensou em testar todas as opções de teclado. De vez em quando este tipo de usuário descobre um besouro cabeludo (bug, erro) porque ninguém nunca pensou que um usuário podia trabalhar daquele jeito. Resultado, aumento nos testes da interface com o usuário, sempre tomada como perfeita e desnecessária de ser testada. Outra briga minha. Os usuários deviam me carregar nos ombros...

Defensores dos teclados contra os ratos

Minha luta tem sido por testar-se para sempre, todos os dias, eternamente. Na época de hoje, com toda esta complexidade, só se pode garantir um produto de qualidade se não se pára de testar nem um minuto. Vai dormir e sonha testando...

Todo dia um componente é atualizado em toda a rede, só se pode garantir integridade se pegar-se os erros logo, imediatamente. Foi assim que uma versão de banco de dados modificou um comando muito utilizado e discretamente aperfeiçoou ele, gerando erros esporádicos e inesperados no sistema que ninguém sabia onde estava. Aquela função não estava sendo testada fazia tempo pois nada havia mudado nela por anos a fio. Não nela, mas no software de base de gerenciamento de banco de dados. Por essa ninguém esperava. Na linha do "under-the-hood" um colega descobriu antes do usuário reclamar assim que a nova versão do software foi implementada. A isso se chama "proactive problem" (problema pró-ativo, detectado antes de causar danos, uma raridade).

Então agora todos testam, todos propagam os besouros e aranhas cabeludas que encontraram (os bugs) e os consertos são auto-fundeados pela empresa, quase imperceptivelmente, se não fosse pelo "paperwork" (documentação e aprovação do cliente). Um jeitinho brasileiro oficializado. Mas eu não patenteei...

Tablete que não é para mascar

Tabletes

Outro sonho já está sendo realizado em outra parte do mundo. Trata-se de entrada e operação dos dados via tablets. O funcionário já vai andando, observando as situações e vai dando entrada no que vê. O computador então avalia o que ele está vendo e diagnostica o que é preciso fazer, mostrando onde é que precisa-se fazer alguma coisa no produto. Digamos que o produto é um mega-iate sofrendo manutenção num estaleiro, ele mostra exatamente onde o engenheiro deve fazer manutenção do motor a energia nuclear graficamente. É o Facebook do engenheiro.

Numa discussão em reunião concluiu-se que não pode ser utilizado no sistema pois você não consegue digitar muita coisa num tablete sem cansar e atirá-lo longe, então sugeri os teclados e telas projetados. Ora, ninguém tinha pensado nisso ainda... suspense.

O grande problema do "touch-screen" (toque na tela) é que perdemos
o senso do tato. Não consigo mudar de função no centro digital do
 carro que não seja controlado na direção quando estou dirigindo
porque, com o balanço, o dedo escorrega e toca em outra função,
me irritando. Se fosse através de pitocos, eu "sentiria" ele e não o
deixaria escapar... saudades de um passado mais eficiente quando
se respeitava os nossos sentidos...

Existem muitos outros sonhos sendo alimentados e brevemente espero que consigamos muitos deles. Um deles era tornar totalmente independente o ambiente de desenvolvimento e isso já está sendo testado. Assim este ambiente pode até ser enviado para outro país. O tiro pode sair pela culatra se me transferirem para a Índia...

Um outro recurso sendo testado é trabalhar-se em casa, à distância. Por vários fatores isso ainda não tem sido possível mas o projeto já está muito avançado. Isso evitaria que várias pessoas viajassem todo fim de semana para chegar no escritório, gente que mora em outras cidades e pega avião pago pela empresa.

Continua...