Commitando... (Mais escovação de bit)

Há alguns anos tive uma reunião com um consultor da IBM chamado Antoine. O sujeito era belga, e seu português era tão perfeito quanto o meu inglês. Ou seja, passamos uma tarde praticamente nos comunicando por mímica e desenhos de flipchart.

De qualquer forma, o papo foi sobre o gerenciador de banco de dados DB2 e muito produtivo, até que Antoine fez uma pergunta que me desconcertou:

- Sua empresa tem uma rotina corporativa para controle de commit?

Não tínhamos, é claro, mas comecei a refletir sobre o assunto.

Na mesma linha do texto sobre bind, vou tratar aqui desse outro termo estranho, o commit, sobre o qual conversamos bastante nos cursos de Performance SQL que  ministramos na TI do Banco do Brasil.

Numa tradução livre, commit significa “confirmação”. No mundo DB2, trata-se exatamente disso. Ao executar uma instrução insert, delete ou update, o dado é fisicamente incluído, excluído ou alterado da tabela (podendo inclusive ser “enxergado” por outras instâncias). No entanto, somente após o commit a operação é efetivada. Inversamente, o rollback, desfaz o comando executado.

No ambiente mainframe, principalmente, o commit e o rollback são instruções “caras” em termos de processamento, porém são indispensáveis à estabilidade do ambiente produtivo e à integridade dos dados processados pelas transações. Um fim inesperado – também conhecido por abend – de uma rotina provoca a perda de todas as informações não commitadas.

Existem ainda situações complexas, em que há mais de um banco de dados envolvido. Um protocolo denominado two-phase-commit se encarrega de sincronizar a confirmação dos dados nos diferentes ambientes, evitando inconsistências na transação.

O commit é importante nas aplicações on-line, mas nas rotinas batch é ainda mais crítico. Mesmo programadores experientes costumam controlar o commit apenas implementando um contador e um loop a cada bloco de registros – mil ocorrências, por exemplo. Isso é insuficiente, e vamos explicar o porquê.

A questão é delicada porque, sob a ótica do desempenho, o commit deve ser realizado o mínimo possível. Inversamente, se considerarmos o aspecto da segurança, seria ideal commit a cada ciclo de processamento. Para atender a essas duas necessidades, portanto, conclui-se que sua periodicidade deve ser necessária e suficiente, ou seja, um uso parcimonioso do comando, de forma a haver um equilíbrio entre performance e segurança.

Aqui voltamos ao questionamento do Antoine. Ao commitar apenas pelo contador, não sabemos exatamente de quanto em quanto tempo o comando será executado. Mil registros podem ser processados em segundos ou horas.

É, pois, fundamental gerenciar a variável tempo. Como isso requer uma programação um pouco mais elaborada, um “serviço corporativo” traria uma série de benefícios à TI, encapsulando a “regras do negócio”, facilitando a codificação, evitando redundância de código, minimizando a incidência de erros e facilitando os testes.

A partir da sugestão do consultor da IBM, portanto, concebemos uma sub-rotina de commit. Essa importante ferramenta conferiu segurança e melhor desempenho aos programas batch de grandes sistemas corporativos.

Mais alguns lembretes:

• O commit deve ser realizado sempre a partir do programa mais externalizado, preferencialmente aquele referenciado no JCL, nunca dentro de uma sub-rotina, pois esta não detém o controle do ciclo completo do processamento;

• Se um componente Cobol batch não tem acesso ao DB2, porém realiza chamada(s) de sub-rotinas Cobol/SQL, sua compilação é como Cobol puro. No entanto, a procedure deve ser construída como se ele fosse um Cobol/SQL, ou seja, o JCL o chama via módulo específico do SGBD – no BB esse módulo é o IKJEFT01;

• Mesmo com um controle rigoroso, um programa ainda pode ter problema de commit, quando uma instrução SQL for muito “pesada” e levar um tempo excessivo para ser executada. Nesses casos, pode ser necessário “quebrar” eventuais joins, subselects e outros comandos em instruções distintas, ou reavaliar como estão os índices das tabelas envolvidas;

• Boas práticas orientam o uso do commit inclusive nos programas que realizam apenas consultas (instruções select). Isso libera recursos do SGBD, por exemplo, caso outra aplicação esteja esperando para executar um utilitário sobre o mesmo tablespace.

Bom, desculpem pelo texto excessivamente técnico, mas essa “escovação de bits” faz parte do dia-a-dia de quem trabalha com TI.

 

Venda de Imóvel - Tributação

Sempre que precisamos de alguma informação relacionada a imposto de renda, é uma dor de cabeça. Mesmo que a regra esteja lá, nossa situação tem sempre uma particularidade que gera alguma dúvida quanto à tributação.

Ao vender uma kit no ano passado, precisei declarar o ganho de capital.

Numa situação normal, após a venda você tem que pagar imposto, relativo à diferença entre o valor da compra e da revenda. Para isso, precisa utilizar um programa específico, baixado do site da Receita. Atenção: não é o mesmo da declaração de ajuste anual.  

No programa Ganho de Capital, após registradas as operações, é calculado o imposto devido e disponibilizado o DARF para pagamento. Se o imóvel era seu há muito tempo, o sistema usa um (pequeno) deflator anual. Ainda assim a “mordida” do Leão costuma ser pesada.

Ou seja, o Leão não é manso, mas há algumas alterantivas. A 9.250, de 1995, isenta de imposto o ganho de capital na venda do único imóvel do titular, limitado a R$ 440 mil. 

Uma outra lei, mais nova (11.196, de 2005), cria outra possibilidade de isenção desde que o alienante  aplique o produto da venda na aquisição de outro(s) imóvel(is) residencial(is) em até 180 dias. Se aplicar parcialmente o produto da venda, a tributação é proporcional ao valor não aplicado.

Aí começam os problemas de interpretação. Se você não pretende comprar outro imóvel, tem que pagar o imposto no mês seguinte ao da venda. Se pretende, só vai declarar a venda após os 180 dias regulamentares. Supondo que, nesse prazo, você não adquira outro imóvel, ou mesmo utilize apenas parte do produto da venda, terá que pagar o imposto.

Foi o meu caso. Eu pretendia comprar outro imóvel, mas acabei não comprando. Portanto, teria que pagar o imposto. Meu entendimento foi: tenho que pagar o imposto acrescido apenas de juros, mas a multa não.  

E foi o que fiz. Cocei o bolso em R$ 17 mil, mas qual não foi minha surpresa ao receber uma notificação da Receita me cobrando a multa. Lá vou eu no Setor de Autarquias reclamar. A atendente disse que eu tinha razão, era um problema do software. A cobrança era indevida, mas eu teria que recorrer.

Conversei ainda com um auditor fiscal, que disse que eu estava errado. Eu discordei, e ele informou que esse era o entendimento da Receita. Fiquei meio p... da vida, e disse que o entendimento era dele, e era errado, pois o que estava escrito na lei era outra coisa. 

Como o clima ficou meio quente, um outro auditor me chamou à sua mesa, perguntou qual o problema, eu expliquei... e ele me deu razão (isso pode, Arnaldo?), mas falou que o meu erro foi não informar a intenção de comprar outro imóvel ao preencher o Ganho de Capital. O sistema – sempre ele – entendeu que eu estava simplesmente pagando o imposto devido com atraso, e por isso me cobrou a multa.

Bom, estava resolvido (pelo menos parecia...). Eu iria fazer uma retificação, alterar um campinho específico, e com isso os R$ 4 mil da multa seriam dispensados. Mas eu ainda teria que entrar com um recurso.

Eu já ia saindo todo feliz com o resultado, e comentei com o auditor que até foi bom eu não ter comprado o outro imóvel, pois pretendia usar a lei agora, com a venda de outro apartamento (você só pode fazer isso uma vez a cada cinco anos).

Foi quando o auditor falou: aí a coisa muda de figura. Não pode!

O que??

Pois é. No momento em que eu for dispensado da multa, de alguma forma eu me beneficiei da lei e, portanto, agora só daqui a cinco anos...

Então, volta tudo ao início, e lá se vão meus R$ 4 mil de novo. É a vida... 

Política: Não é bem assim...

Dia de eleição. O que mais se vê nas ruas são as batidas discussões sobre políticos ladrões e corruptos. Infelizmente, é fato. A imensa maioria deles faz jus à fama.

Mas isso me incomoda, e por alguns motivos.O primeiro é de ordem pessoal. Meu pai, meu maior ídolo, minha referência, foi agricultor, comerciante... e político. Um simples vereador numa cidade do interior, durante décadas. A prova irrefutável de que ele era a pessoa mais decente que eu – assim como todos os que conviveram com ele – conheci é o fato de que, até sua morte, ocorrida em 2009, aos 86 anos, ele sobrevivia às custas de uma miserável aposentadoria do INSS e, principalmente, de uma vaquinha dos filhos.

Seu Eduardo Patrício chegou a ser um “homem de recursos”, como se diz no sertão do Ceará – notadamente em Boa Viagem e Quixeramobim, cidades nas quais ele morou e trabalhou muito. Quando ele, convencido por minha mãe, mandou a família para Fortaleza, sua condição financeira começou a piorar. Mas ele ficava todo orgulhoso ao dizer que esse sacrifício foi responsável pela sua maior riqueza: a educação e formação dos filhos. 

Algum dia voltarei a escrever sobre alguns dos “causos” do meu pai, que, além de tudo, era uma figuraça.   

Após essa breve digressão, voltemos. O segundo motivo do meu incômodo está, de certa forma,  relacionado ao anterior. Como meu pai, existem políticos decentes, honestos, que, obviamente, representam um gota dágua no oceano. Dá pra contar nos dedos.

Terceiro: a política é um retrato da sociedade. Assim como existem prefeitos, deputados, vereadores corruptos, isso também ocorre em todos os segmentos da sociedade. Empresários, professores, padres, pastores e seus rebanhos, estudantes, bancários, jogadores de futebol, jornalistas, médicos, magistrados, enfim, em todo lugar temos pessoas de bem e outras nem tanto. Boa parte das pessoas que adoram xingar os políticos, gostaria mesmo é de estar lá, e se olhasse pra dentro de si, possivelmente identificaria comportamento semelhante. E no seu dia-a-dia têm lá seus pecados. Talvez com volumes menores...

É mais ou menos como aquela velha piada. Num avião, o cara se dirige à moça lindíssima sentada ao seu lado:

- Por um milhão de reais você passaria uma noite comigo?

Os olhos dela brilham.

- Um milhão de reais é bem razoável...

- E por cinquenta reais?

- O senhor está pensando que eu sou prostituta?

- Bem, isso já foi respondido na primeira pergunta. Agora é só uma questão de preço...

Voltando à vaca fria, o que me incomoda mesmo no bordão “político ladrão” é outra coisa. Exceto se retornarmos a uma sociedade anárquica, sempre vamos precisar de políticos. Não há como fugir.  

O estigma de que a política é lugar para criminosos, portanto, apenas afasta mais e mais as pessoas decentes dela. E cada vez mais, estaremos entregando o ouro ao bandido, reduzindo-se nossas oportunidades de mudar alguma coisa em dias como hoje, de eleições municipais.

Você gostaria que seu filho fosse político? Eu gostaria. Pedro tem apenas dezessete anos. É quase uma criança, mas vive dando mostras de sua integridade. Não sei se já nasceu assim, ou se tem a ver com a educação que recebeu. Talvez as duas coisas.

Mas ele quer ser engenheiro. Ótimo. Se fosse político, ótimo também!  

Reflexões...

Não sei se é politicamente correto, mas...

- Desconfie de quem concorda com tudo, para quem tudo está sempre maravilhoso;

- Desconfie de quem discorda de tudo, para quem tudo está sempre uma droga;

- Numa discussão produtiva, o normal é as pessoas alternarem-se entre o falar e o ouvir. Atenção àqueles que adoram ouvir a própria voz, mas não têm a mesma disposição na hora de escutar;

- Um bom termômetro para saber se você está indo bem (na vida ou em qualquer outra área) é quando você é querido por muitos... e detestado pelos picaretas;

- É muito fácil ser um chefe bonzinho, fazer todo mundo gostar de você. Mas isso só é bom se o serviço está sendo feito, se a empresa também está sendo beneficiada. Afinal, trabalho é uma relação de troca;

- Não adianta apenas dizer que você está sempre aberto à discussão, ao feedback. Você precisa, naturalmente, propiciar condições para que as pessoas cheguem até você;

- Você pode e deve ser amigo de seus subordinados, desde que isso não interfira na isenção das suas decisões, especialmente quando o assunto for promoção;

- Fique atento àqueles que dedicam preocupação excessiva em mostrar resultado para trabalhos que “estão na mídia”, que têm visibilidade. Verifique se aquele trabalho duro, necessário, mas que não dá ibope, recebe a mesma atenção, ou se está sendo varrido para debaixo do tapete;   

- Não se deve tratar igual os desiguais. Substitua a igualdade pela equidade. Seja justo, valorize quem efetivamente se dedica. Infelizmente isso vai gerar algumas antipatias, mas é o preço a se pagar. Mas atenção! Cuidado para não extrapolar a questão da hierarquia no trabalho. Isso é apenas uma questão de estrutura organizacional. Fundamentalmente, você não é melhor que ninguém;

- Para saber se você está agindo corretamente, coloque-se do outro lado e verifique se você continua pensando da mesma forma;

- Pare de reclamar. Quer dizer, reclame um pouquinho, mas saiba que sempre há o que fazer na sua esfera de atuação. Quase nunca os problemas são inteiramente alheios a você, embora seja muito cômodo pensar dessa forma;

- Fuja dos puxa-sacos. Eles, literalmente, lhe puxam pra baixo!

E pra concluir: mesmo sabendo que a ignorância é o segredo da felicidade, prefira o conhecimento...

Pé-trocado

Recentemente me disseram que eu ando muito sério nas minhas postagens, que eu deveria escrever algo mais leve, como em outros tempos. Então vamos lá.

Essa um amigo que está morando no exterior certamente vai lembrar, pois de vez em quando não perde a oportunidade de contar para alguém.

Certo dia, a lâmpada que ficava logo acima da minha estação de trabalho estava sem acender e esse meu amigo, sempre solícito, se dispôs a consertar. Tirou o sapato, subiu na cadeira e resolveu o problema. Só que, enquanto isso, eu percebi que nossos sapatos eram iguais e resolvi tirar uma onda. Tirei os meus, calcei os dele e fiquei quieto.

Ele desceu, calçou meus sapatos e voltou à sua mesa, sem se dar conta da troca. Ocorre que eu calço um número a mais que ele. Depois de certo tempo, meu amigo percebeu que havia algo errado. A todo instante, parava de digitar, olhava para os pés, movimentava-os para os lados e imaginava como eles poderiam ter “encolhido”. Eu sentava bem à sua frente e fingia não perceber seu incômodo.

Isso ocorreu pela manhã. Durante todo o dia, meu antigo parceiro de tênis, ex-militar, sistematicamente repetiu o gesto de olhar pra baixo, mexer os pés, franzir a testa e voltar ao trabalho, cada vez mais intrigado.

Quase no final da tarde, eu estava de pé a uns cinco metros dele, conversando com outros colegas, quando meu amigo parou o que estava fazendo, olhou fixamente para os meus pés, para os dele, para os meus novamente, refletiu longamente e caminhou em minha direção, sem muita convicção.

Ao chegar, meio sem graça, perguntou educadamente:

- Com licença, Sérgio. Por acaso, será que nós não trocamos nossos sapatos por engano?

Morrendo de vontade de rir, controlei-me e respondi bem sério:

- Olha, você não acha meio comprometedora essa pergunta? Em que situação isso poderia ter ocorrido?

Ele coçou a cabeça, pediu desculpas e já ia voltando para o seu lugar quando eu e os demais não nos agüentamos, gargalhamos e entregamos o ouro.

Sempre que nos encontramos lembramos com bom-humor do episódio, um caso típico de inutilidade que entra para a posteridade...   

Simples assim

Veja (e ouça) esses dois clipes. Sem entrar  no mérito do que é bom ou ruim – eu prefiro a Tiê -  as duas interpretações passam mensagens bem distintas, apesar de se tratar da mesma música.

A comunicação falada – especialmente presencial – adiciona vários componentes àquilo que está sendo transmitido, além das palavras em si: a expressão corporal e facial, o tom de voz, o volume e até a possibilidade do feedback imediato, que nos permite eventualmente corrigir algum mal-entendido.

Já a linguagem escrita não tem nada disso, e ainda conta com um agravante: a perenidade. Um email inadequado, uma postagem precipitada no facebook – muitos esquecem inclusive o alcance absurdo da rede social – uma ata de reunião, tudo permanece registrado, podendo ser objeto de consulta no futuro.

Um dia desses chamei um funcionário de minha equipe para conversar sobre uma mensagem que ele havia encaminhado a vários destinatários. Pensei duas vezes antes de fazê-lo, mas acredito que uma das principais atribuições de um administrador é a formação de sua equipe.

Com muito cuidado, tentei explicar que o texto poderia ser melhorado (na verdade, estava muito ruim) e recebi a seguinte resposta:

- Olha, Sérgio, não tem jeito, eu nunca fui bom em português.

Retruquei:

- Eu também não, mas o fato de ler e escrever bastante vai fazendo a gente melhorar continuamente.

Na realidade, muitos dos erros que cometemos não têm muito a ver com o desconhecimento de regras, mas sim com falta de atenção. Argumentei com meu amigo que ele poderia ter evitado pelo menos alguns dos equívocos, que era mais uma questão de atenção ou mesmo de lógica. Falei de algumas dicas básicas, tipo: vírgulas são pequenas pausas, pontos são pausas maiores, crase – um eterno problema – é simplesmente a junção de dois “As”, etc.

Pedi para que meu funcionário pronunciasse mentalmente aquilo que escrevera e voltasse a redigir a mensagem. Resultado: o texto saiu quase perfeito!

Seguem alguns macetes que podemos utilizar no dia-a-dia:

• Quem escreve bem escreve pouco. Isso é particularmente relevante no mundo atual, em que convivemos com excesso de informação;
• Simplifique! Muitas vezes tentamos utilizar termos difíceis sem conhecer o seu significado. É comum a utilização indevida de palavras, apenas pelo que elas parecem representar. Exemplos: assertividade não tem nada a ver com acerto, amiúde não significa detalhamento (a miúdo?), e por aí vai;
• Todo editor de texto tem um corretor ortográfico. Ele nunca vai resolver tudo, mas já filtra os erros mais crassos;
• Algumas coisas são bem chatinhas de aprender, como o uso do porque, do hífen (principalmente depois da reforma ortográfica), do mal/mau, do verbo assistir, do há/a, etc. Aí não tem jeito: pesquise! Com o advento do Google, isso é a coisa mais fácil que existe;
• Gosto muito de uma coluna chamada Dicas de Português, publicada pela jornalista Dad Squarisi no jornal Correio Braziliense (assim mesmo, com “z”).

Bom, melhor ir encerrando por aqui. Quanto maior o texto, maior a possibilidade de errar. Quem sabe já não cometi alguma gafe...  

Desmistificando o BIND

Todas as vezes que converso com alguém de TI sobre BIND, percebo que esse é um conceito extremamente vago para a maioria das pessoas, mesmo em se tratando de analistas e programadores experientes.

Há algum tempo, coloquei numa prova uma questão em que perguntava qual o significado dessa estranha palavra. A maioria dos alunos marcou a opção relacionada à sigla  Binary INteractive Dynamic, algo sem o menor sentido. Na realidade, até existe um acróstico para o termo -Berkeley Internet Name Domain – mas se trata, no entanto, de um servidor para o protocolo DNS.

Estamos falando de outra coisa. Vou tentar explicar tudo em linguagem  coloquial, lembrando que, dependendo da área de tecnologia envolvida, podemos ter significados diversos, mas sempre com o sentido de “ligação”.

Bom, delimitando o escopo, neste contexto vamos tratar de bind como o processo de conexão de um programa com um banco de dados. Utilizaremos o exemplo de um módulo Cobol/SQL acessando o DB2 em ambiente mainframe.

Dentro do código, consideremos duas instruções hipotéticas:
MOVE 1 TO GDA-SDO
EXEC-SQL SELECT NOM FROM DB2XXX.CLIENTE WHERE SALDO = :GDA-SDO 

Ao compilarmos o programa, um dos primeiros passos é a pré-compilação, que varre o código-fonte, identifica as instruções de diferentes linguagens e realiza alguns procedimentos, quais sejam:

1. Extrai do programa Cobol a linha do EXEC-SQL, substituindo-a pela chamada de uma subrotina que irá realizar o acesso ao DB2;

2. O fonte Cobol, após a pré-compilação, ficará mais ou menos assim:

 MOVE 1 TO GDA-SDO

CALL “Interface-DB2” + Parâmetros (incluído na linkedição)

3. Todas as instruções SQL extraídas dão origem a um outro arquivo-fonte, denominado DBRM (Data Base Request Module);

4. Os dois fontes recebem um timestamp com o exato momento da geração dos dois arquivos (um com as instruções Cobol e o outro com o  SQL). Isso é necessário para que, em tempo de execução, quando o programa fizer requisições ao banco de dados, o mesmo se certifique de que tudo faz parte de uma mesma versão. Havendo divergência, o DB2 retorna o “famoso” SQLCODE -805;

5. O bind é simplesmente a criação do plano de acesso do programa ao BD, ou a geração de um executável (o package) a partir do fonte DBRM relacionado. Esse executável normalmente tem o mesmo nome do programa de origem.

Portanto, ao executarmos o programa e este  chegar à instrução SQL, o módulo de carga Cobol, na prática, chama (vide CALL acima) a interface com o DB2 “pedindo” o seguinte:

- Acesse o “package” com o meu nome/timestamp para o meu SELECT com as variáveis que estou lhe passando e me retorne o resultado.

É importante ressaltar que aqui estamos falando de bind “estático”, ou seja, aquele que é realizado previamente à execução, no momento em que o programa é instalado em cada ambiente. Isso é extremamente importante, pois desonera a aplicação de traçar sua estratégia de acesso às tabelas no momento em que o usuário está utilizando o sistema (mais adiante falaremos de bind dinâmico). 

Em cada ambiente produtivo (desenvolvimento, teste, produção, etc) há um bind específico, utilizando o mesmo DBRM.

Mas por que fazer um novo bind em todos os ambientes, ao invés de se reutilizar o package gerado no desenvolvimento? Porque cada ambiente tem seu próprio DB2, com características específicas, e o processo considera diversas informações do catálogo, como a existência de índices, a quantidade de registros da tabela e até a variedade de conteúdos dos campos das tabelas.

Quer dizer que o bind deve ser mais demorado conforme envolva tabelas grandes, pois o DB2 analisa cada linha? Não! Ao se rodar o utilitário RUNSTATS, todas as estatísticas das tabelas necessárias ao bind são consolidadas e gravadas no catálogo do DB2, e essas sim, são utilizadas na geração do package.

Por conta disso é que, como o conteúdo dos bancos de dados é muito dinâmico, faz-se necessário a realização periódica de RUNSTATS e REBIND, para que, a partir do mesmo DBRM, o DB2 reavalie sua estratégia de acesso e gere novo package.

Por fim, quando falamos em bind dinâmico, estamos nos referindo à realização, em tempo de execução, de todo o processo de decisão do DB2 quanto à forma de acesso aos dados, o que pode causar degradação de performance na aplicação, ou mesmo sua indisponibilidade.

Costumo dizer que o bind dinâmico é, na realidade, a ausência de bind, embora não seja bem isso. Até porque, quando uma classe de persistência Java chega ao mainframe via JDBC (Java Database Conector), por exemplo, a primeira execução é bastante onerosa, mas o plano gerado fica em cache e é reutilizado nas chamadas subseqüentes.

Bem, o assunto vai longe, acredito termos abordado o essencial.   

Olhar interior

Um dia desses, a senhora da limpeza se aproximou humildemente e travamos esse insólito diálogo:

- “Seu” Sérgio, eu queria agradecer ao senhor...

- Por que, Elza?

- Porque o senhor conversa comigo.

- Ah, legal. Então, muito obrigado também, pois você também conversa comigo!

- O senhor não entendeu...

- Claro que entendi, por isso estou agradecendo também...

- É que, pra maioria das pessoas, a gente é invisível e, às vezes, se eu não saio do meio, o povo passa até por cima de mim...

Isso não é novidade. Já saiu na mídia uma pesquisa em que um estudioso se fantasiou de gari e relatou uma situação semelhante. Mas presenciar isso pessoalmente me marcou. É a crua constatação de que cada vez mais nos prendemos a estereótipos, consideramo-nos diferenciados ante os mais humildes. Isso pode ser explícito, como a humilhação de um manobrista por um médico, a que presenciei recentemente em uma festa, ou implícita, sutil, como o caso da minha amiga da limpeza.

Esses fatos retratam a nossa incapacidade cada vez maior de encarar a vida com simplicidade, de dar valor às coisas realmente importantes, de colocarmo-nos na situação do outro, de olharmos para as nossas atitudes de forma isenta e serena.

É o tal negócio: a ignorância é o segredo da felicidade; o conhecimento, do tormento. 

Melhor não pensar demais nessas coisas...     

Cadu

Cerca de cinco mil adolescentes participam do Programa Menor Aprendiz do BB de norte a sul do País. Além da capacitação profissional, a orientação dá foco também em princípios éticos e responsabilidade socioambiental. 

Em 2008, o menor da Gerência de Projetos da DITEC era o Carlos Eduardo, um moreninho magro, inteligente e adorado por todos. Além da preocupação com sua formação profissional, procurávamos integrar o Cadu nas atividades sociais que realizávamos.  

Cadu gostava muito de futebol e nas olimpíadas internas da diretoria era o nosso meia-atacante, infernizando a vida dos adversários com sua habilidade e velocidade.

Quando ele me disse que nunca tinha ido a um estádio, prometi levá-lo tão logo aparecesse a  oportunidade.  

Um dia, chamei o Cadu e informei:

- Amigão, eu gostaria de levar você para o melhor jogo que houvesse aqui em Brasília. Infelizmente, o time que poderia proporcionar o maior espetáculo pra você assistir – o meu Fortaleza – não vai se apresentar aqui tão cedo. Portanto, quarta-feira que vem vou lhe levar para um joguinho de segunda categoria no Bezerrão, ok? Se você quiser ir, peça autorização aos seus pais.

Seus olhos brilharam. Cadu era muito bem informado para saber que naquele dia o estádio do Gama seria reinaugurado com a presença simplesmente dos dois maiores jogadores do mundo na época, Kaká e Cristiano Ronaldo. O jogo era Brasil e Portugal, ganhamos por 6 a 2 e nossa seleção deu show!

Hoje, alguns anos depois, meu amigo Cadu já encerrou seu estágio, virou atleta e está na batalha.

Com certeza, o Banco, as dezenas de amigos que conquistou e aquele inesquecível 19 de novembro de 2008 o acompanharão por toda a sua vida!

Bases Corporativas - Um Caso de Sucesso

Nos anos 90, a TI do BB já era referência em termos de sistemas informatizados e processamento de grandes volumes de informação. No entanto, ainda não havia, na prática, um conceito consolidado de bases corporativas.

Em 1997 o Banco do Brasil colocava em produção o aplicativo CLIENTES que, apesar de rodar no “jurássico” terminal 3270, representou um marco na história da tecnologia da informação da empresa. Além de extremamente funcional e ajudar as agências na realização de negócios, o grande diferencial do CLIENTES era transparente para a maioria dos seus usuários e se encontrava na revolução do sistema que rodava por trás de sua camada de apresentação.

Na esteira do Programa Arquitetura da Informação – PAI – um conjunto de sistemas conhecido como COPO (Clientes, Órgãos, Produtos e Operações) foi concebido como embrião das Bases Corporativas, um moderno conceito de gerenciamento de informações, do qual o BB foi mais uma vez pioneiro, em se tratando de grandes empresas do segmento financeiro brasileiro.

Um dos pilares dessa estrutura foi a base de clientes. Até então, o Banco do Brasil utilizava o sistema BDC – Base de Dados Cadastrais – uma estrutura  descentralizada (eram dez SGBDs espalhados pelo país, sem comunicação entre si), sem garantia de unicidade, e que exigia a replicação de informações em seus diversos sistemas transacionais e gerenciais.

Num esforço sinérgico de diversas áreas, tendo à frente as Diretorias de Tecnologia e de Crédito, O Banco do Brasil iniciou então o desenvolvimento do Projeto MCI – Mercado Interno – que contemplava vários avanços, como a centralização das informações, regras rígidas que garantiam a unicidade do cadastro, reuso dos dados e até uma filosofia praticamente inexistente à época, notadamente em se tratando de mainframe: o conceito de serviço.

O sistema foi implantado em tempo recorde e seus benefícios superaram todas as expectativas. O MCI atravessou incólume o bug do milênio e até hoje suas informações são consumidas por centenas de sistemas nas diversas plataformas do BB.

Sua implantação resultou em economia de storage e tempo de processamento, aumento na confiabilidade dos dados, alto grau de reuso e baixa manutenção. Externamente, ganhamos em credibilidade, melhoria da imagem do Banco junto à clientela e incremento dos negócios.

Podemos afirmar com convicção que esse foi o primeiro exemplo efetivo de MDM - Master Data Management, ou Governança de Dados - do mercado bancário brasileiro, permitindo ao BB o gerenciamento de dados complexos, a proteção da informação, a melhoria de controles contábeis e o subsídio à decisão de negócios. 

O MCI virou benchmarking, ganhou prêmios e foi copiado pela concorrência nos anos que se seguiram.

TI: Teoria e Prática

Na busca de tentar resolver – ou pelo menos minimizar – a bomba-relógio que é a guerra desigual entre os recursos cada vez mais limitados frente às demandas cada vez mais crescentes no mundo de TI, uma das coisas que sempre me vêm à mente é a dicotomia Generalização/Especialização.

As ideias mais modernas de governança apontam para que os recursos sejam os mais genéricos possíveis, e alocados de acordo com a necessidade estratégica da organização. Na prática, porém, isso é impossível. Pelo menos em sua totalidade. Mas parcialmente, é possível. E fundamental!

A questão é: em que áreas isso deve ser aplicado? Em construção? Requisitos? Teste? Gestão de projetos? Infraestrutura? Talvez em todas, com percentuais diferenciados.

Aqui não estamos falando de software houses, ou de qualquer empresa exclusivamente de TI, mas de empresas comerciais que têm uma área de TI, cuja abordagem é bem diferente.

No geral, temos dois tipos de estruturação:

• Especialização no processo (projeto, requisito, teste, infraestrutura) ou
• Especialização no negócio (cartão, empréstimo, CRM...)

Talvez, o que dê uma melhor relação custo/benefício seja um mix, algo do tipo:

Construção: aqui não há margem para ilusões. A dependência do conhecimento do negócio é altíssima, indispensável. Então, algo como 70% de especialização no sistema e 30% de generalização (ou seja, o funcionário, aqui, é especialista “apenas” em linguagem, banco de dados, enfim, tecnologia) talvez fosse uma boa segmentação. Somente esses 30% seriam a mão-de-obra flutuante, aquela que pode ser redirecionada conforme a estratégia da organização. Na prática, é quem pode manter a produtividade ao sair de um sistema contábil para outro de auditoria, por exemplo. Ou seja, grosso modo, uma “mini-fábrica-de-software” interna;

Requisitos, testes, outros processos: 30% especialista em sistemas críticos (conhecendo também o processo relacionado) e 70% “genérico”. Aqui a flexibilidade é maior, assim como essa liberdade aumenta cada vez mais, conforme o processo. Ainda assim, o conhecimento prévio do negócio ainda é muito importante, principalmente por um aspecto: o negócio crítico é cada vez mais comprimido por restrições de tempo e abstração na sua especificação. 


Isso é o que funciona. Porque, na prática, a teoria é outra.

Contra- Indicadores

Um importante instrumento de apoio à gestão empresarial é o uso de indicadores. Não vamos aqui entrar no mérito de Balance Scorecard, KPIs ou algum conceito teórico, mas sim de qualquer método, mesmo empírico, em que o gestor determine parâmetros para medir a “saúde” de uma ou mais áreas da organização.

O problema é quando o indicador vira um fim em si mesmo. Daí derivam alguns problemas. O primeiro: a proliferação do controle. É número que não acaba mais, sem nenhum critério sobre a real necessidade daquilo que é inventado. E às vezes somos bem criativos... Chega-se ao absurdo de se criar indicador do indicador!

Mas isso não é o pior. A coisa fica séria mesmo quando começamos a administar em função de indicadores. Ou seja, há uma inversão de valores. Ao contrário de se utilizar os números obtidos para identificar problemas, corrigir distorções e melhorar processos, trabalha-se para produzir bons números, maquiar resultados, apresentar notas boas.

Um exemplo crasso: define-se um indicador de satisfação de clientes. Pronto! A partir desse momento, como num passe de mágica, o índice de satisfação sobe assustadoramente! Sinal de que o atendimento melhorou? Claro que não!

Funciona mais ou menos assim: primeiramente, definimos que não vamos mais registrar clientes insatisfeitos. Quando alguém reclamar de algo, o atendimento fará um "sambarilove", registrará um eufemismo qualquer na ferramenta de onde serão extraídas as informações gerenciais e está resolvido. O problema em si continua, mas superficialmente parece que tudo está às mil maravilhas... 

E rapidamente ocorre uma curiosa acomodação. No início, é tudo meio velado, escondido. Com o tempo, a coisa vai se institucionalizando, e praticamente todos assimilam esse modus operandi.

É nesse ponto que reverter esse quadro se torna um trabalho hercúleo, mas ainda assim fundamental. Caso contrário, em algum momento, os problemas vão aumentando de forma que com o tempo a situação vai se tornar inadministrável.


Todos gostamos de boas notícias, de verificar que tudo está correndo bem. Mas precisamos a todo custo agir com rigor, atacar a fundo os problemas que nos afligem, chegar às causas-raízes dos nossos males, só assim conseguiremos atingir os nossos objetivos.  

No mundo corporativo atual, a cobrança de curto prazo está imensa -  e só tende a aumentar - mas o administrador não pode perder de vista a preocupação com a perenidade da organização.

Não Concordo!

Esses dias perdi uma funcionária da minha equipe, uma gerente com a qual eu vivia discutindo. Nossas divergências eram freqüentes. Era “não concordo” pra cá, “não concordo” pra lá...

Resumindo: uma das melhores pessoas com quem trabalhei na vida. Comprometida, preocupada com os destinos da nossa área, da nossa empresa.

Batalhei pela sua promoção. Se não fosse nesses termos (uma ascensão) eu nunca a teria liberado. Porque é esse tipo de funcionário que leva a empresa pra frente, que quando vê alguma coisa com a qual não concorda, não se intimida porque está diante do chefe.

Não confundir, em hipótese alguma, com o “nuvem negra”, aquele que reclama o tempo inteiro, que está sempre culpando o outro pelos problemas do trabalho, que se considera o maioral, o injustiçado, que está sempre contando vantagem pelos corredores, em altos brados, mas trabalhar para mudar o que está errado, agir positivamente, que é bom, nada...

Mas existe um tipo ainda pior: o subserviente, aquele que está sempre com um sorriso no rosto, concordando com tudo, notadamente com quem está acima hierarquicamente. Às vezes, é até divertido acompanhar isso numa reunião. O cara não sabe nem do que se trata, mas concorda com ardor, com veemência!

Agora, se alguém “inferior” se atravessa no seu caminho, ele procura uma oportunidade para desqualificá-lo, para utilizá-lo como “escada” para se promover, geralmente de forma irônica. E o que é pior: muitas vezes, a miopia corporativa faz com que essa figura passe por um grande profissional e consiga galgar posições dentro da organização. Isso porque muito chefe adora uma babação e acredita num marketing rasteiro, superficial, sem conteúdo.

Voltando à minha indócil gerente: sua promoção é um sopro de esperança, é a renovação da crença de que a minha empresa valoriza aquilo que realmente precisa ser valorizado: a seriedade, o trabalho duro, o profissionalismo. 

Outsourcing Possível

Participando de um GT de outsourcing, um colega de batalha de alguns anos me pergunta qual minha opinião sobre uma forma efetiva de uma empresa pública terceirizar desenvolvimento de software. Pra mim não há muitas alternativas, até porque já se tentou de quase tudo, sem sucesso.

Primeiramente, descartamos o bodyshop. Para os incautos, trata-se da contratação de serviços em que a remuneração se dá por hora-homem, ou seja, ela é completamente desatrelada de qualquer entrega, razão pela qual é ilegal (TCU), imoral e engorda (no caso, o caixa da terceirizada).

Portanto, o modelo a ser adotado é o de Fábrica, com a métrica adequada àquilo que se quer contratar (ex: APF), com fatores de ajustes para atender às especificidades da organização. E o ideal é a contratação de pacotes significativamente grandes, de forma a diluir os custos de controle. 

Bom, até aqui nenhuma novidade. Mas o ponto central começa com algo que postei em outro texto, que é a redução contínua do delay entre o surgimento da necessidade do negócio e sua implantação. E mais. Digamos que esse delay seja de trinta dias. Hipoteticamente, somente após uns vinte dias é que as regras efetivamente se materializam (se é que se materializam), de forma que não há como se explicitar formal e tempestivamente isso numa encomenda terceirizada.

Assim é que, na prática, um modelo possível seria uma especificação superficial por parte da contratante de forma a permitir, num primeiro momento: uma medição indicativa; uma previsão orçamentária; e uma estimativa de esforço/prazo.

A partir daí, um funcionário da contratante compõe uma célula de desenvolvimento com a equipe disponibilizada pela contratada, ao tempo em que se busca uma maior consolidação da demanda, de forma que, ao final do serviço, seja possível medir e remunerar a empresa pelo produto entregue, de acordo com as condições pactuadas.

Eu sei, não é lá um modelo muito redondo, e há alguns aspectos questionáveis, mas não há muito como fugir disso.

Infelizmente.    

Em Busca do Equilíbrio­

Na TI de hoje, especialmente para uma empresa com as características de um grande banco, o negócio não pode esperar. Portanto, é natural que o  desenvolvimento de software trabalhe quase sempre com prazos exíguos.

Nesse contexto, qualquer processo declarado, por mais enxuto que seja, é visto como um transtorno. Num cenário de restrição extrema, o único artefato indispensável tende a ser o código em si, o sistema.

A área de TI deve perseguir obstinadamente o objetivo de entregar tempestivamente, mas com qualidade, a solução que permita à empresa realizar negócios.

Para tanto, é imperioso racionalizar os processos. A base acadêmica é importantíssima, mas ela deve ser adaptada às especificidades de cada organização.

Outro aspecto relevante é a retroalimentação dos processos, por parte de quem os executa. Por mais competente que seja a área normatizadora, nem sempre aquilo que ela declara se mostra efetivo ao ser aplicado à realidade, e é aí que o feedback se faz necessário. 

O mais importante é nunca perdermos de vista que processos, padrões e artefatos não são um fim em si mesmo, mas devem sempre estar a serviço de um objetivo maior. Mas precisamos pensar a TI além do cenário de curto prazo.

Para perpetuarmos nossa área, faz-se necessário reter conhecimento e construir sistemas robustos, estáveis, com documentação necessária e suficiente. Nem mais nem menos.

A documentação de um sistema é útil se ela espelha fielmente sua arquitetura e funcionalidades, além de poder ser efetivamente reusada em intervenções futuras.   

Um ambiente produtivo estável libera mão-de-obra de manutenção para o atendimento de novas demandas, aumentando a agilidade e a própria imagem da TI junto à organização. Precisamos encontrar o ponto de equilíbrio entre entrega e controle. Esse é o nosso desafio.

Parece óbvio, e é. Mas não é fácil.