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.