SCJP (310-065)

No dia 31/05 o exame SCJP (310-065) foi aplicado pela última vez pela Prometric, antes de ser migrado para a Pearson Vue, foi justo o dia que marquei a minha prova, pois a principio não haveria como transferir o voucher que eu já tinha adquirido, portanto essa era a minha data final para fazer o exame.

Fiz uma revisão total do conteúdo em 3 dias, estudando pelo livro da Katty, que consiste em vários simulados. Fiquei preocupado, pois as notas que eu obtive não eram as que eu esperava, mas felizmente durante a prova real, eu percebi que os simulados foram bem mais difíceis, especialmente o último simulado do livro que está no nível “Eu não caio em pegadinhas!”.

Quase não houve questões teóricas, o requisito para passar no exame foi realmente conhecer detalhes da Linguagem e API padrão fazendo análises a partir de trechos de código. A prova foi bem cansativa, sempre existia como resposta as alternativas genéricas:  “Compilation fails” e “RuntimeException”.

Após passar no exame, eu acredito que ele realmente comprova os conhecimentos do candidato na linguagem e nos itens mais comuns da API padrão.  Obviamente que para o “mundo real” esses conhecimentos são um ponto de partida, para qualquer profissional que queira entender os diversos frameworks utilizados no dia a dia dos projetos.

Dynamic table mapping - Hibernate

Ao longo dos anos se tornou comum utilizar frameworks ORM na construção de softwares que necessitem armazenar informações, esse tipo de framework facilita a manipulação dos dados fornecendo muitos recursos como: controle da conexão, transação, sessão, desacoplamento com as particularidades dos SGBD's, entre outros.

No meu caso, estou utilizando JAVA + Hibernate sendo o mapeamento entre classes/tabelas feito por XML e Annotations, porém nesse software eu precisei mapear a mesma classe para tabelas diferentes durante a execução, ou seja, eu precisei alterar o mapeamento dinamicamente. Junto da equipe a primeira idéia que surgiu foi alterar o xml de configuração (hibernate.cfg.xml), o que não fazia nenhum sentido pois teríamos que ao final da execução, retornar a configuração inicial. 

A partir daí o raciocínio foi simples, em algum momento o Hibernate tem que carregar o mapeamento para algum dos seus objetos e de alguma forma ele deve expor essa “facilidade”. Após algum tempo para a busca, não encontramos nada que resolvesse algo que é aparentemente simples: “Se estamos trabalhando com um framework de mapeamento objeto-relacional, nada mais óbvio que a necessidade de alterar o mapeamento em tempo de execução”.

Eu acredito que sempre que esse tipo de coisa acontece, o jeito é forçar a solução e como diria meu pai: “a necessidade faz o ladrão”, abrimos o código do Hibernate 3.5.6 para entender as estruturas de mapeamento. Realmente o Hibernate é muito bem construído é não deixou a galera na mão, encontramos uma classe interna da org.hibernate.cfg.Configuration, que implementa a Mappings, a partir dessa classe conseguimos fazer nosso dynamic table mapping.

Segue abaixo a parte mais importante do post, o exemplo:

// instancia o org.hibernate.cfg.Configuration
conf = new AnnotationConfiguration();
//carrega o hibernate.cfg.xml
conf.configure();
// carrega o mapeamento class-entity/table
conf.buildMappings();
// cria o manipulador de mappings
Mappings mps = conf.createMappings();

// Exemplo de alteração do mapeamento
Table t = mps.getTable(null, null, "tabela_antiga");
t.setName("tabela_nova");

Vale lembrar que após a alteração do mapeamento um novo SessionFactory deve ser criado, assim como os objetos que são criados a partir dele (Session, Transaction, etc). Espero que esse post ajude as outras pessoas que como nós não encontraram essa "simples" resposta, nem na documentação do Hibernate.

Observação: Como o mapeamento está sendo alterado direto no código, é importante lembrar que essa estrutura deve existir no banco de dados, caso não exista também é possível criá-la pelo Hibernate, mas  essa questão não faz parte desse post.

Referência: Documentação Hibernate - 2.Arquitetura

BPO - Uma questão de atitude

Business Process Outsourcing (BPO) é a terceirização de um processo de negócio de uma empresa, que geralmente não faz parte de seu core business. É justamente aí que as grandes barreiras começam. Pela atividade terceirizada não fazer parte de sua atividade fim, geralmente os clientes possuem pouco conhecimento imediato a respeito do objeto de terceirização. É comum que esse conhecimento seja construído à medida que a relação de terceirização amadureça. Claro que existem clientes de maturidade variada, mas aqui o intuito é analisar a média.

Em setores de terceirização de alta competitividade entre players, o que se percebe acontecer de forma repetida é a construção de um "not know how" empírico por parte do cliente, pautado em más experiências passadas. Nesses casos, o cliente adota uma postura defensiva que intimida qualquer fornecedor.

Como contribuir para o aumento da maturidade de seu cliente em uma situação como essa?

Como não se deixar intimidar por essa barreira entre cliente e fornecedor?

A responsabilidade nesse caso é do fornecedor, detentor do know how, da expertise, direcionar o cliente de forma que este possa mudar sua atitude perante ele e a empresa fornecedora. A maior dificuldade é que enquanto o objetivo maior (mudança de atitude e aumento da maturidade do cliente) não acontecer, os conflitos serão comuns.

A falha maior nesse caso, é que para evitar desgastes imediatos, evita-se por vezes um posicionamento que a princípio pode parecer áspero, mas que em longo prazo pode ser determinante na construção de uma relação duradoura. Não há mal em dizer que o cliente está errado, pelo contrário, não fazê-lo é um ato de negligência grave. O desafio consiste em evidenciar esse erro ao cliente da melhor forma possível, mas deve-se ter cuidado para não atribuir menos ou mais relevância do que tal pauta deveria ter.

Deve-se buscar um comprometimento com o cliente e não um comprometimento de subsistência com seu próprio emprego.

E você, está realmente comprometido com seu cliente? Ou acha mais fácil agir como o avestruz da foto?

A revolução dos bichos

Quando eu vi esse título “A revolução dos Bichos”, de George Orwell, logo imaginei que era um livro para crianças (confesso que fiz cara feia!), quando comecei a ler percebi que era uma fábula e que realmente poderia ser lido por crianças, mas aos poucos percebi que haviam mensagens escondidas para os adultos, reflexões sobre a vida em sociedade.

Em um breve resumo, com uma pitada de opnião, a história se passa em um sítio (país), que é dominado por um homem muito rigido (autoritário). Um certo dia um porco (revolucionário) mostra como será o mundo depois que o homem desaparecer (depois que o atual regime cair), porém dias depois o idealista morre, mas seus sete mandamentos para o novo mundo (novo regime) permanecem escritos na parede como sonhos distantes.

Todos os animais na históra representam “tipos” de posturas sociais, como: manipulação, alienação, ignorância, teimosia, passividade... Tipos que você já conhece!

De alguma forma a expulsão do dono (a revolução) ocorre. E então os animais se reorganizam para criar aquele novo mundo apresentado pelo idealista falecido, seguindo fielmente os mandamentos. Porém surgem as primeiras divergências entre os comandantes do novo regime e então as primeiras deturpações das idéias começam a ocorrer, logo os mandamentos um a um foram removidos ou alterados de acordo com as pretensões do novo ditador, até que no fim é impossível distinguir as diferenças entre o homem (antigo ditador) e o porco (novo ditador).

É engraçado como essa sátira da revolução russa, possui tantos pontos em comum com outras revoluções (a Cubana por exemplo), mostra claramente o caminho percorrido quando os mais fracos tomam o poder e são, por ele corrompidos. Se pensarmos um pouco, é curioso como reconhecemos esses “tipos” em nossas equipes, realizando as mesmas ações (de liderança ideológica ou autóritária) em diferentes níveis. Para quem conhece a história, você age como qual dos “animais” do sitio?

Princípios Gerenciais: Seu gerente se lembra deles?

Normalmente, gerenciamento é definido como a arte e/ou ciência de realizar tarefas por intermédio de outras pessoas, ou seja, os gerentes são responsáveis por planejar e orientar o trabalho dos outros, o que para muitos dos “não-gerentes” parece como a arte de não fazer nada, quem nunca ouviu a frase: “O meu gerente não faz nada o dia inteiro!”, isso pode ser verdadeiro em alguns casos, mas acredito que são raros, pois em um ambiente competitivo os demais membros da equipe já teriam tomado o seu lugar.

Escuto muito sobre equipes auto-gerenciáveis (vide SCRUM), e apóio por acreditar que funcione bem no lugar certo, mas com certeza em algum nível hierárquico ainda precisa existir a figura do gestor que mantém a coesão do grupo, administra os conflitos, direciona os esforços para atingir as metas da empresa...

Existem várias definições sobre o qual o papel do gerente em uma organização, eu prefiro a seguinte definição: “Gerente é aquele que consegue que o resultado da equipe seja maior do que a soma do resultado de cada individuo”. Se eu precisasse dar nota para o trabalho de um gerente esse seria um dos meus critérios mais valiosos.

Equipes com bons profissionais parecem uma embarcação com capitão de férias, o barco segue em movimento, mas quando ocorrem imprevistos e a situação se agrava o consenso também desaparece, é como uma nação sem governo cada um trabalha em interesse próprio. Imagine um exército sem general, parece absurdo!? Essa é a importância da figura do gestor.

No gerenciamento assim como no jogo de xadrez, tem a vantagem quem consegue considerar mais lances adiante e realizar a melhor estratégia se adaptando conforme o jogo. Imprevistos sempre podem acontecer e alguns são até bem vindos, exemplo disso é quando um profissional chave para o projeto comunica a sua saída da equipe repentinamente, comumente vejo gerentes encarando isto apenas como um contratempo, mas também pode ser visto como uma gama de oportunidades, tais como contratação de um profissional com perfil diferente (ou melhor), reestruturação da equipe, desafios e reconhecimento aos demais membros da equipe, etc..

Recentemente eu acompanhei a saída do líder de uma equipe, logo ficou claro para todos que não havia alguém já qualificado para assumir, portanto curiosamente a solução dada pela direção foi a promoção de dois profissionais da equipe, pois havia um com mais habilidade no relacionamento interpessoal e o outro com um profundo conhecimento técnico, então os papéis foram redefinidos na tentativa de um complementar o outro.

De acordo com Tom Gorman existem cinco princípios mais importantes que todo gerente deve saber:

Valor para o cliente: Os clientes pagam pelo valor do produto ou serviço, não é possível atender a todos os desejos dos clientes, portanto deve-se criar um tipo específico de valor, ou seja decidir o que a empresa vai entregar aos clientes e a partir daí organizar-se.

Organização: Empresas menores tendem a ser menos estruturadas, com menos departamentos e recursos para organizar e empresas maiores exatamente por terem muitos recursos para gerir tendem a ser mais organizadas, porém determinado departamento pode ser organizado ou não independente do tamanho da empresa, e grande responsabilidade disso é do gerente realizar seu trabalho corretamente.

Vantagem competitiva: É o “algo mais” no produto ou serviço oferecido e qual é o seu público-alvo, porém isso deve estar bem claro a todo momento nas decisões dos gerentes, muitos fracassos empresariais estão baseados no “esquecimento” desse princípio.

Controle: Os controles asseguram que o gerente possa saber o que está acontecendo. Os controles são baseados em autonomia e informações. Porém o que não é medido não é gerenciado.

Lucratividade: O negócio só existe para gerar lucros. Se por incompetência do gerente a empresa perder dinheiro provavelmente não ficará com o emprego por muito tempo. Com certeza cada empresa possui suas metas, mas a principal é obter lucro.

Muitas empresas obtêm bons resultados financeiros, mas isso não significa que o trabalho está sendo bem feito e que os problemas não estão sendo escondidos por trás desses resultados. Até que ponto as pessoas sabem o que acontece dentro da empresa? Será que os gerentes na sua empresa realizam seu papel?

Vai estudar meu filho!

Depois de um longo período sem posts, lá vai um post leve. Me certifiquei em ITIL V3 Foundation e gostaria de compartilhar a experiência. Já faz algum tempo que me interessei por ITIL, seu conteúdo, processos, termos e conceitos. Ao começar a trabalhar em uma empresa onde existem áreas buscando aplicar cada dia mais esses conceitos, conhecer esse conjunto de boas práticas se tornou uma necessidade para mim.

Plano de estudos: o livro oficial de introdução possui conteúdo mais do que o necessário para estudar para o certificado. Li o material apenas uma vez fazendo um resumo e revisei esse resumo. Para facilitar o estudo assisti algumas aulas em um curso online e fiz alguns simulados, em torno de uns 7.

A prova foi tranquila, em geral as questões foram a respeito das definições dos termos. O tempo é suficiente para fazer a prova e revisar tudo sem pressa.

Espero que esse post possa ajudar alguém. Boa sorte para quem for fazer a prova.

O assistente do analista

Eu quero contar uma história: um belo dia alguém da Empresa X disse que era preciso rever a política de cargos e salários para corrigir alguns problemas. Realmente havia sobreposição de funções, cargos de maior responsabilidade com menor remuneração e uma certa confusão sobre as atribuições de cada cargo. Então, uma equipe foi reunida para redefinir essa política. No início do trabalho, ficou bem claro que existiam muitos “Analistas” e “Assistentes” dentro da empresa; foi encontrado até assistente que gerenciava analista.

Pela definição, assistente é quem auxilia em alguma coisa e analista é quem realiza a “análise” de como é, porque é, e o que fazer a partir daí. Considerando então que o assistente segue as orientações de alguém e faz algo já definido, podemos entender que o analista, por sua vez, possui um perfil mais flexivel, sabendo lidar com as variações que o seu trabalho pode apresentar.

Essa então foi a parte fácil. Mais fácil ainda foi promover os assistentes que trabalhavam como analistas para o seu cargo de direito. O complicado foi mostrar aos analistas que apesar de possuírem o cargo, eles desempenhavam as funções de assistente.

Foram abertas oportunidades para essas pessoas de realmente se tornarem analistas. A empresa reconheceu seus erros “estruturais”, apresentou um generoso programa de capacitação e a promessa de aumento de salário aos analistas que concluíssem o programa. Para o espanto da equipe que conduzia essa reestruturação, muitas pessoas nessa situação se recusaram a participar do programa por entender que não era necessário estudar para obter um “status” que já possuíam. Houveram várias discussões sobre os ganhos que a capacitação traz, independente da área.

Essa resistência se mostrou como um problema cultural na empresa. Novamente, a equipe responsável pelas mudanças entendeu que eram necessárias iniciativas não apenas da perspectiva técnica desses profissionais, mas também pessoal. Foram apresentadas à diretoria algumas alternativas para a resolução desse problema, porém veio a seguinte decisão de um dos diretores: “É melhor, financeiramente, a demissão das pessoas que estão resistentes às mudanças para a contratação de outras com o perfil que agora desejamos”.

Conclusão: as pessoas que se indignaram, mesmo recebendo a mais pelo tipo de trabalho que desempenhavam e não concordaram a participar do programa de capacitação, perceberam que apesar do “barulho” que fizeram representavam menos de 2% dos funcionários e, como na prática eram assistentes, poderiam ser facilmente substituídos.

Na sua empresa, essa visão entre assistente e analistas é bem definida? Existe resistência às mudanças? As pessoas se consideram insubstituíveis? E você?