O Maior Bug é Não Entender o Negócio

Não faz muito tempo ouvi de um desenvolvedor: “não quero saber de regras de negócio, estou preocupado é com o meu código”. Noves fora o assombro pelo óbvio desconhecimento da conexão entre o ovo e a galinha, esse comportamento também pressupõe uma tradução impecável entre regras de negócio e requisitos de software que, na prática, é tão rara quanto impraticável. Esse viés é causa-raiz de bugs super complexos que, tipicamente, causam impacto em cascata, exigem refatoração, e, finalmente, ocasionam perdas de prazo, de reputação e de receita.

Uma das maneiras através das quais eu gosto de definir os objetivos de Qualidade no desenvolvimento de software é “garantir persistência de regras de negócio”. É claro que essa não é a única persistência importante, mas, se formos priorizar as dimensões de conformidade que devemos atacar, certamente vem em primeiro lugar. Em outras palavras, garantir que a aplicação realmente resolva os problemas do mundo real que fizeram com que ela fosse desenvolvida para começo de conversa.

Não adiantam discoveries super coloridas, refinamentos fluídos, arquiteturas enxutas e escaláveis, design systems modernos e intuitivos, governança bem estabelecida e ferramentas de IA se a sua aplicação não atende às regras de negócio. Isso significa que não adianta olhar apenas para forma — que, no limite, é exatamente o que o desenvolvedor que mencionei faz —, é preciso olhar para o conteúdo. Essa necessidade de “mais semântica e menos sintaxe” perpassa todo o processo de desenvolvimento de software, e se traduz, inclusive de acordo com normativas ISTQB, em conhecimento de domínio.

Conhecimento de domínio é mais do que conhecimento funcional (pois a funcionalidade já pressupõe um nível de abstração de implementação, ainda que em artefatos de alto nível), conhecimento de domínio é conhecimento do negócio. Isso se traduz na necessidade de que todos os atores envolvidos em um projeto de desenvolvimento de software tenham um conhecimento adequado da indústria específica a que a aplicação em desenvolvimento atende.

Isso não é apenas percepção de campo; por exemplo, um estudo empírico (*) com 232 projetos globalmente distribuídos demonstrou que a integração de conhecimento de domínio de negócio com conhecimento técnico produz:

• Melhoria na efetividade do design
• Redução estatisticamente significativa na densidade de defeitos em todas as fases
• Maior alinhamento entre software entregue e necessidades do cliente

Além disso, existe já o bem documentado aumento exponencial do custo de encontrar bugs tardiamente no processo de desenvolvimento de software (o que está diretamente conectado a problemas de conhecimento de domínio): a “Regra dos 100” da IBM Systems Sciences Institute é uma das referências mais citadas neste assunto, mostrando que o custo de qualidade aumenta em uma ordem de grandeza a cada fase, desde design e mapeamento de requisitos até produção/pós-release.

Como, então, garantir a persistência das regras de negócio, o conhecimento de domínio, a proficiência funcional e, principalmente, como evitar o posicionamento do desenvolvedor mencionado acima? A Engenharia de Qualidade de software traz diversas ferramentas e processos que podem apoiar nesse caminho, mas o primeiro passo é sempre o reconhecimento deste problema por todos os envolvidos, em especial pelos decisores, no sentido de apoiar investimentos, propostas técnicas, roadmaps e perfis de equipes que privilegiem a busca constante pela conformidade.

Fonte: “An empirical study of the effect of knowledge integration on software development performance” em ScienceDirect (https://www.sciencedirect.com/science/article/abs/pii/S0950584904000618).