Não, seu Problema não é “Pressão para Implementar IA”, é Falta de Qualidade

IA não é processo nem solução, é apenas ferramenta, e, quando a necessidade de IA é expressada, isso está necessariamente ligado a uma dor subjacente que precisa ser tratada: baixa produtividade, muito retrabalho, baixa reputação, churn alto e NPS baixo são exemplos dos problemas reais que, muitas vezes, fazem os stakeholders saírem por aí “exigindo” IA. Não que IA não possa ajudar, “apenas” o problema real é mais embaixo (e geralmente é um problema de Quality Assurance).

Desenvolvimento de software é uma atividade de engenharia, e é preciso engenho e arte; uma das atividades mais complexas deste ofício é mapear a real necessidade do cliente/stakeholder (que, muitas vezes, precisa inclusive de apoio para entender o que ele mesmo quer). Isso vale também para as “dores” ou “problemas” que nós, engenheiros de software, identificamos ao dissecar os requisitos de um potencial novo projeto. Esta atividade investigativa — que guarda uma semelhança importante com um dos pilares de Quality Assurance, a análise de causa-raiz — precisa ser feita sempre. 

Por isso, ao ouvir “precisamos implementar IA”, pergunte: por quê? O que está acontecendo no “mundo real” que fez com que o stakeholder/cliente buscasse a “bala de prata” da inteligência artificial? Pergunte sobre densidades de defeitos, sobre problemas recorrentes em produção, sobre milestones perdidas; questione o stakeholder sobre o dimensionamento de sua equipe de Quality Assurance, sobre o mapeamento de riscos que justifica a cobertura funcional de testes (e que ele provavelmente não tem). Veja se há falta de compliance regulatório, normativo e legal, ou, simplesmente, falta de persistência de regras de negócio. Muito provavelmente é nesses pontos que estará o “verdadeiro” problema.

Não que, para endereçar esses problemas, não possamos contar com o apoio de IA: mas será apenas isso, apoio. Para melhorar taxas de defeitos, pode-se utilizar IA para apoiar em processos de análise de causa-raiz de lotes de defeitos (mas, primeiro, precisamos definir o processo de análise de causa-raiz); para problemas recorrentes em produção, pode-se utilizar IA para apoiar em um processo de roteamento de defeitos com base em severidade (mas, primeiro, precisamos definir o processo de gestão de defeitos); para o dimensionamento de equipes de Quality Assurance, podemos usar IA para inferir, através de dados históricos, o perfil dos engenheiros necessários (mas, primeiro, precisamos definir um processo estruturado de coleta dos dados históricos). A solução é processual e de conhecimento de domínio, e IA pode (ou não) entrar apoiando. 

A “exigência” do uso de IA é sintoma de um problema, não causa. Projetos têm os mesmos desafios processuais que tinham antes de 2022; antigamente a “exigência” era automação de testes (que também nada mais é do que o uso de ferramentas para solucionar/acelerar processos).

O grande desafio é sensibilizar a alta gestão desta necessidade de separar causa e sintoma antes de partir para o uso de uma ferramenta. Isso exige um conhecimento de engenharia de software de ponta a ponta: desde pré-vendas, passando por formatação de propostas, até implementação e gestão de projetos. É preciso firmeza e robustez técnica para não ceder à resposta “fácil” de que a implementação de uma ferramenta de inteligência artificial vai resolver problemas de engenharia.