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)
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 |
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 |
- 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
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... |
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... |
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 |
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... |
Em contrapartida ao RIA, vejam o que a empresa saltou como solução para um probleminha.
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 |
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 |
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...