Já vinha estudando sobre gerenciamento de processos desde fevereiro deste ano, época da minha primeira passagem pela equipe. Tive uma rápida passagem por ETL e, há dois meses, estou de volta ao BPM. Aprendi muitas coisas neste período, principalmente a lidar com a diversidade de profissionais. E é justamente esse o ponto central desta pequena série. Tenho trabalhado com o ALBPM e com um Java que não é Java, mas é Java. Sim, a coisa é meio confusa. Entretanto, existem aplicações puramente Java que auxiliam o sistema como um todo, como as consultas.
Bem, como eu disse, o ponto central deste post é a diversidade de profissionais.
Quando somos jovens, com o excesso de energia que é peculiar desta idade, e encontramos códigos que não estão em boa forma (good shape), a reação mais natural é criticar. Entretanto, quando amadurecemos e olhamos para nossos próprios códigos do passado, com os olhos do conhecimento que adquirimos durante os anos, percebemos que já desenvolvemos de forma amadora. A evolução é algo natural (ou deveria ser) e, naturalmente, tendemos a achar ruim hoje, o que fizemos ontem. Assim, considerando apenas os profissionais que estão preocupados com a sua carreira, não existem bons ou ruins e sim, profissionais que estão em diferentes níveis de carreira.
Acredito que os três níveis tradicionais de analista - júnior, pleno e sênior - não são suficientes para expressar os níveis reais da carreira. Acho que poderiamos explodir o pleno em mais três níveis (como baixo, médio e alto). Reforço que estou me referindo aos profissionais que realmente se preocupam com a sua carreira, que estudam e buscam o aprimoramento, mesmo nos horários de folga.
Dentro deste grupo de profissionais, considero o analista bom ou ruim baseado na sua reação quando encontra um código ruim pela frente. Você diz, isso não é problema meu?
Deixa eu explicar melhor. Nas grandes empresas, é natural assumir aplicações legadas, que chamo, carinhosamente, de filhas adotivas. É natural também, que estas aplicações tenham passado pelas mãos de muitas pessoas. Estas pessoas, obviamente, se encontram em níveis diferentes de conhecimento.
Com aplicações em produção, é comum atendermos chamados solicitando melhorias ou correções (bug-fixes). É neste momento que podemos (e devemos) fazer a diferença.
Se você está no grupo de pessoas que afirmam que um código legado mal feito não é um problema seu, está na hora de rever conceitos e, talvez, se tornar um pouco mais psicopata.
Acredito que o pior cenário para fazer melhorias de código, seja o de grandes empresas, por inúmeros fatores, alguns exemplos:
- Ambiente de produção fora do seu controle: Geralmente os processos de deploy e restart de servidores de aplicação não estão nas mãos dos analistas e sim de uma equipe especializada;
- Muitas camadas de testes antes de um deploy: Normalmente, os únicos testes que estão na mão dos analistas são os unitários. Outros testes como os integrados e regressão, estão nas mãos de equipes especializadas em testes.
Estes exemplos mostram como pode ser complicado "subir" alguma modificação motivada "apenas" por melhorias no código. Como um outro post, já planejado, pretende mostrar, o cliente, normalmente, não está preocupado com isso. Não concordo com essa visão, entretanto expor meu ponto de vista sobre esta situação não é propósito deste post.
Estes motivos, na minha visão, já são suficientes para tornar nosso o problema.
Assim, um chamado de melhoria ou correção é uma ótima oportunidade de deixarmos a nossa vida um pouco mais tranquila no futuro. Como? Só vejo uma forma, sendo psicopata.
O meu tempo, como a da maioria das pessoas que frequenta este blog, é escasso. Assim, quando fazer as alterações não contempladas em um chamado? Como fazer de forma segura? Como ser eficiente para não afetar as metas?
Estas perguntas serão respondidas no próximo e último post dessa série. Até lá.
Nenhum comentário:
Postar um comentário