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...