CARREIRA
Olá amigos, em 11 anos de desenvolvimento, já encontrei os mais diversos cenários em cliente, ou mesmo dentro da consultoria, onde cada um fazia o que bem entendia em relação a padrão de nomenclatura, desenvolvimento das customizações, tornando tudo muito caótico e sem nenhuma regra!
Isso não era privilégio das pequenas consultorias não, as grandes também não tinham a menor culpa em assumir que não tinham nenhum padrão no ciclo de desenvolvimento ou mesmo no quesito mais elementar: os nomes das tabelas, nomes de programas, transações, etc.
Quando cada pessoa segue o que acha bacana, o sistema vai ficando falho, em relação ao suporte, ou seja, quanto mais caótico o ambiente estiver, mais complicado e ajustar os itens necessários a mudança das regras de negócio do cliente, isso faz com que a correção demore muito, tornando qualquer ajuste muito caro para o cliente, para a consultoria e sobrando para o ABAP.
Sobra para o ABAP, pois temos muitos gerentes que não tem a menor noção do que esta acontecendo na vida, quanto mais no seu desenvolvimento que já têm mais de 12 mil linhas e você precisa tampar um buraco neste queijo suíço!
QUAIS OS PROBLEMAS ENVOLVIDOS ?
Quando não temos um padrão do que seguir, o ambiente de desenvolvimento fica passível de erro e equívocos do que realmente precisa ser feito e em quanto tempo. Isso gera a falta de compreensão, onde o ABAP ajusta um item e o Analista Funcional não teste o cenário equivalente ao ajuste realizado.
Aqui alguns pontos que podemos observar na falta
- A primeira coisa que vem a cabeça, claro, são os erros de desenvolvimento inerentes aos código “macarronicos” dentro do programa ABAP. Isso gera um custo alto para a área de engenharia de software do cliente.
- Incremento do tempo para procurar as falhas e um tempo ainda maior para realizar as suas correções, pois o ABAP precisa de um tempo maior de debug e uma atenção redobrada para não modificar o que já esta funcionando no ambiente.
- Aquela piada onde um programador ajusta um item e com este ajuste insere mais Bugs no sistema, neste cenário, é bem possível que isso realmente aconteça. Quando não temos um código intuitivo e organizado, o ABAP vai ter que “rebolar” para inserir um ajuste no sistema.
- O cliente irá gastar muito com desenvolvimento, pois, dependendo do problema, terá que ser contratado um profissional sênior para resolver um problema, sendo que, se o sistema estivesse bem arquitetado e organizado (intuitivo), um profissional Pleno, ou até mesmo um Júnior, poderia lidar muito bem com os ajustes do ambiente!
- Acredito que esta seja a prova fundamental dos erros de sistema e de programas mal arquitetados e que foram crescendo de forma desordenada e sem a menor organização! Cresce, de forma exponencial, os possível erros em produção, parando programas de missão crítica que nunca deveriam parar por erro de programação, ou seja, um cenário mal restado e um código inserido em lugar errado, podem parar o faturamento de uma empresa inteira, gerando um prejuízo enorme e um inferno na vida de muita gente!
Já passei por grandes banco, aqui no Brasil, onde a padronização era algo inimaginável. Alguns profissionais, simplesmente falavam que era coisa de empresa de internet (sério, teve um gerente de projetos que chegou a me falar isso!!!!) e que um banco não precisava disso para nada!
Ambientes que não existem qualquer padronização, normalmente não têm as documentações técnicas dos ajustes realizados nos programas ABAP, sendo assim, não temos a menor chance ao tentar mapear o que um software faz e como ele faz, perguntas como: “De onde vem este valor desta coluna, no relatório de faturamento ?”, não são respondidas facilmente olhando um Help ou um simples documento Word! Então, o analista, querendo responder a pegunta, acaba abrindo um ticket na TI, para que alguma consultoria, envie um ABAP para “somente” debugar o programa e descobrir de onde vem este valor!
Não seria mais fácil ter uma intranet com tudo o que foi desenvolvido e o mapeamento mais atualizado do programa, para que essas questões sejam simples de responder, sem a necessidade de gastar dinheiro para isso ?
Imagine que a sua empresa irá passar por um processo de auditoria interna e que, para isso, ela precise mostrar códigos e falar sobre padrões de desenvolvimento para uma área de QA de um cliente! Uma empresa desorganizada não vai conseguir cumprir esta função.
Para o controle da qualidade de software, a padronização de nomes e documentação do ciclo de desenvolvimento, é de suma importância para cumprir com qualquer departamento de qualidade e de engenharia de software, pois com a padronização a rastreabilidade de desenvolvimento é muito mais segura, ou seja, você consegue rastrear um problema, vinculada a uma funcionalidade especifica e verificar a qual chamado ela pertence para cobrar as pessoas envolvidas nos ajustes!
O QUE É A PADRONIZAÇÃO NO SAP ?
Quando falamos de padrão, no ambiente SAP, falamos sobre a maneira que os profissionais interagem com o sistema. Todo mundo fazendo a interação da mesma forma, tanto os programadores ao criar uma tabela interna em um programa, quanto os funcionais usando uma interface visual em um programa para fazer o upload de um arquivo Excel para o servidor.
A interação terá que ser feita sempre da mesma maneira! Interação do processo dos funcionais e os programas dos ABAPs! Isso é padrão.
Depois de realizar a padronização do processo e do código, o envio para outros ambientes será feita de forma parecida também, pois tudo seguida uma lógica pre-determinada e você não vai precisar fazer algum artifício no sistema para poder realizar um transporte de um elemento do sistema, ou mesmo a famosa “abrir o QA para editar um programa”!
COMO PODEMOS PADRONIZAR ?
Em um ambiente SAP, para criar um padrão de desenvolvimento e de processos, temos que cruar um “Booking” (ou Workbook) com todo o processo documentado para que todos possam fazer as coisas da mesma maneira. Um workbook de desenvolvimento, têm os nomes de elementos de dados, programas, transações e os nomes de todos os elementos pertinentes a um ABAP para que, assim, todos os ABAPs possam das nomes iguais e seguir um padrão na hora de criar uma transação, uma tabela no banco de dados, um programa, um perform dentro de um programa, um Loop, etc!
Esse padrão torna as coisas muito mais fáceis de perceber, pois quando estamos no código já sabemos em que estamos fuçando e quais as modificações que vamos precisar executar para que um ajuste funcione rápido e com qualidade.
Claro, no Workbook temos que especificar, também, a maneira que desenvolvemos uma solução para que um ABAP não inclua o ajuste dele em um parte que não têm muito haver. Podemos criar, no workbook, as áreas especificas para que um ABAP mude o código de um programa, gerando uma padronização de desenvolvimento e de ajuste!
Ganhamos muito na qualidade das entregas, na segurança dos desenvolvimentos e no prazo e custos de desenvolvimento. Imagine que o seu desenvolvimento (um relatório, um extrator, uma BADI, etc) é um produto e que todo produto precisará de um ajuste no futuro, então crie uma determinada “região” no seu programa que seja “convidativa” para realizar determinados ajustes em seu programa, depois de uma seleção de dados ou antes de um APPEND em uma tabela interna.
BENEFÍCIOS DA PADRONIZAÇÃO DO DESENVOLVIMENTO
A cartilha de desenvolvimento ou WorkBook, garante que todos trabalhem de forma organizada e metódica para entregar um programa de qualidade (ou mesmo um ajuste), tornando a equipe muito mais produtiva e centrada na resolução, rápida, de problemas, gerando muito mais economia e reduzindo custos no desenvolvimento.
Com a padronização do código, um consultor ABAP, não importa a senioridade do mesmo, poderá executar um ajuste em qualquer programa, pois todos os programas estarão falando a mesma língua, ou seja, um protocolo que será compreendido por todos de forma simples, sem a necessidade de se traduzir um código para um analista Júnior, ou Pleno.
Os problemas na produção, irão se tornar quase remotos, pois a padronização e a qualidade tornará os transportes muito mais rápidos e as requests irão para um ambiente de homologação e testes serão realizados antes do envio a produção, tornando o ambiente muito mais seguro.
A qualidade do desenvolvimento, irá entregar muito mais performance a aplicações, pois todas elas irão conversar de forma semelhantes, tendo o seu código padronizado no acesso a banco de dados e performance da aplicação no tratamento da massa de dados.
A qualidade e o código simples, irá auxiliar a equipe de suporte na resolução de problemas e na entrega de melhores soluções de código para os problemas encontrados pelas área de negócio.
A área de gestão da empresa, visualiza a redução de gastos e a qualidade do atendimento ao usuário final, ou seja, uma redução de custos gera uma percepção de qualidade maior para a empresa, tornando o negócio muito mais ágil e competitivo na gestão da mudança da organização.
Você não precisa de uma ferramenta para isso, só criar um padrão e realizar a gestão eficiente de objetos sap, programação e requests para tornar a resolução de problemas muito mais rápida!
Espero que eu tenha ajudado com este artigo!
Um grande abraço e até o próximo!
Léo
