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