Problemas no código são como uma dívida financeira, isto é, algo que você pode assumir, desde que pague, sob pena de cair em uma espiral de problemas. Não é de hoje que, no universo de softwares, assume-se dívida técnica por limitações de tempo e de orçamento, com a intenção de pagá-las em suaves prestações.

Há um aspecto positivo e negativo nisso, como em toda dívida contraída. Por um lado, você tem a vantagem de acelerar um go-to-market e de poder validar ideias com usuários rapidamente. Por outro lado, é extremamente comum que essa dívida se acumule até se tornar um problemão que custa caro e impede a organização de fazer mais do que simplesmente manter as luzes acesas, como upgrades e inovações.

E no ambiente SAP? A dívida técnica se reflete, por exemplo, na migração para o SAP S/4HANA. De acordo com pesquisa da ASUG, apenas 16% das organizações entrevistadas concluíram a migração, enquanto 21% estão fazendo. Os 63% restantes vão fazê-la futuramente. Por quê?

A mesma pesquisa mostra que 60% a 80% do orçamento e equipe estão dedicados a manter os sistemas. Só 7% das empresas levantadas gastam mais tempo inovando do que executando. A dívida técnica está por trás desse cenário.

Quais as principais fontes de dívida técnica das organizações que usam SAP?

1. Customização

Uma aplicação não nasce repleta de código ruim. A deterioração do código acontece ao longo do tempo, depois de muitos remendos e diferentes equipes trabalharem nela.

O volume de código customizado, em muitos casos, se torna impossível de ser monitorado (sem uma ferramenta para automatizar o processo). Nas migrações dentro de SAP, isso significa que todos esses objetos customizados deverão ser movidos.

O alto volume de customizações feitas sem muito padrão é uma das principais forma de dívida técnica.

2. Desenvolvimento em ABAP

Até 2040, a SAP permanecerá com o ABAP, uma das mais antigas linguagens de programação. Isso não necessariamente é algo ruim.

O porém está em escrever programas em ABAP, que requer grandes habilidades em programação de um número cada vez menor de profissionais. Desenvolvedores ABAP estão entre os perfis mais escassos no mercado de tecnologia.

Além disso, coloque-se no lugar de um desenvolvedor que vai trabalhar em um código caótico. Uma tralha a mais num ambiente totalmente bagunçado não fará muita diferença, concorda? Código ruim gera código ruim, que gera mais dívida técnica.

3. Padrões distintos de qualidade entre desenvolvedores

Os desenvolveres, por via de regra, tomam cuidado com a qualidade do código produzido. Porém, em muitos casos, qualidade é um conceito muito pessoal, e nem todo desenvolvedor envolvido no projeto vai usar os mesmos critérios de qualidade para avaliar o código produzido.

Isso significa que código de baixa qualidade vai acabar entrando em produção, diminuindo a qualidade do todo.

Sem ferramentas de inspeção de código externas, muitas equipes não conseguem evitar o efeito em dívida técnica, mesmo usando o code inspector. Com a desculpa de voltar depois à questão, elas acabam assumindo a dívida técnica em função de velocidade e de custos.

Alguém acredita que esse código ruim que entrou em produção vai ser refatorado? A fila anda…

E tem mais: o code inspector não identifica problemas de qualidade por si mesmo, não monitora a qualidade ao longo do tempo, nem recomenda maneiras de solucionar o problema.

4. Testes de baixa qualidade

Os testes são uma garantia de que os desenvolvedores codifiquem sem medo. Então, se os testes passam, está tudo certo para a produção.

Mas se os testes não são os certos? Quando eles não testam o que você pensa que eles testam ou não testam nada?

É isso que acontece quando os testes não são testados. O problema é mais comum do que se pensa, e mais uma fonte de dívida técnica.

5. Saída da fonte de conhecimento

Normalmente os sistemas customizados são antigos, e foram criados por várias mãos, como equipe interna, terceira e consultorias. Algumas customizações são tão profundas que devem ser consideradas quase como aplicações independentes.

Nesse cenário, é bem difícil desenhar e implementar standards de desenvolvimento sem ferramentas para isso. E então, quando os autores da fonte de conhecimento saem da empresa e uma nova equipe assume, você fica com mais uma fonte de dívida técnica.

6. Não refatorar

Você certamente se depara com código ruim no seu dia a dia. Pode ser complicado limpar código que você nem sabe quem escreveu. E você não quer mexer nesse vespeiro.

Mas a equipe que não tira um tempinho da sprint para refatorar o que está mantendo está gerando um problema que vai estourar no seu colo, com a total perda de controle da aplicação. Ao manter um código ruim vai ter que perder muito tempo interpretando – ou decifrando – o que está escrito, por exemplo, um trabalho maçante.

Essa é mais uma fonte, ainda que não da geração de dívida técnica, de manutenção dessa dívida.

Comece a eliminar a dívida técnica de seu ambiente SAP

Quanto mais dívida técnica, mais difícil de pagá-la. Por isso que é melhor ter o mínimo possível e, acima de tudo, mantê-la gerenciável, reduzindo de fato ao longo do tempo suas implicações e montante.

A redução de dívida técnica pode ser feita a qualquer momento, dentro da jornada SAP, esteja migrando ou não. Aliás, gerenciamento de dívida técnica não é um projeto. É uma prática. É possível criar pequenos projetos dentro da sprint, para serem tocados com as demandas em andamento, mas o ideal é toda a oportunidade de melhorar o código já escrito seja aproveitada pela equipe.

O QADevOps ajuda você nisso. Na plataforma, você monitora e gerencia todo o código customizado já produzido e recém-produzido, identificando possíveis fontes de débito técnico antes de que entrem em produção e recebendo recomendações para melhoria contínua. É a garantia de que o que entrará em produção está com a melhor qualidade, não gerando retrabalho para a equipe.

No dashboard da plataforma, você também acompanha métricas como:

• Redução de custo por objeto
• Custo em retrabalho
• Objetos avaliados
• Ganhos cumulativos.

Faça uma demonstração do QADevOps, uma ferramenta pensada para alavancar a performance de processos SAP.