Elcio Ferreira Desenvolver software é uma atividade arriscada e imprevisível. Uma pesquisa feita pela Harvard Business Review apontou que 70% dos projetos de software atrasam. E o principal fator de risco para os projetos é a complexidade. Quanto mais complexo o software e o ecossistema em que ele está inserido, maior o risco.
E o que é pior: a complexidade impacta o custo de manutenção. Manter software é muito mais caro do que desenvolver e esse custo oculto é impactado diretamente pela complexidade criada durante o desenvolvimento.
Entre os problemas gerados pela complexidade, estão:
- redução da velocidade de inovação
- aumento do custo de inovação
- redução da qualidade e segurança do software
- redução do engajamento no uso do software
- aumento dos custos de infraestrutura
- aumento dos custos de suporte
- aumento dos erros operacionais
É por isso que combater a complexidade é, na grande maioria dos casos, a iniciativa de gerenciamento que mais pode trazer retorno, ou ajudar o software a trazer retorno. O combate à complexidade no desenvolvimento de software acontece em vários níveis.
No nível operacional, combatemos a complexidade com conhecimento e boas práticas de programação. Garantir que seu time conheça padrões de projeto, arquitetura de software e boas práticas para a modelagem e para a escrita de código limpo e fácil de manter são algumas das ações frequentemente adotadas para o combate à complexidade no nível operacional.
No nível tático, o combate à complexidade se dá primariamente com métodos e rotina de trabalho. A organização do time, a escolha do método de trabalho e das ferramentas e rotinas para lidar com as demandas do projeto podem impactar diretamente o nível de complexidade no software que está sendo construído.
E no nível estratégico? Quando a conversa sai dos bits e bytes e vai para o mundo dos negócios existe uma lacuna de conhecimento que faz com que, na maioria das empresas, os projetos de desenvolvimento entreguem software muito mais complexo do que deveriam. É claro que as ações operacionais e táticas podem ajudar sua empresa a desenvolver software mais simples, mas nada se compara ao que pode ser feito no nível estratégico.
Gerentes de nível estratégico não precisam entender os detalhes técnicos das rotinas de desenvolvimento de software para combater a complexidade, mas precisam entender a principal razão pela qual projetos de software se tornam complexos.
A principal origem da complexidade em projetos de software
A maior parte da complexidade em software tem sua origem em relações exponenciais entre os componentes do projeto. Para ilustrar isso, vamos falar do tamanho das equipes de desenvolvimento. Em uma equipe de desenvolvimento de software as pessoas precisam conversar o tempo todo. Uma parte importante do tempo dos programadores é gasta conversando uns com os outros, numa atualização mútua a respeito do que foi feito, como foi feito, o que deve ser feito a seguir e como.
Imagine agora uma equipe com quatro pessoas. Cada um deve conversar com os outros três. Isso gera seis relações, conforme você pode ver na figura a seguir:
Agora, imagine que, no intuito de aumentar a velocidade do time, vamos acrescentar dois novos programadores. Isso representa um aumento de 50% na força de trabalho. Mas veja na figura a seguir o que acontece com a necessidade de comunicação entre eles:
Um aumento de 50% na força de trabalho representou, nesse caso, um aumento de 150% no esforço necessário de comunicação entre o time. Logo, esses dois programadores a mais vão tornar o time mais rápido, mas o aumento de velocidade não será de 50%. Há muita perda no processo. E quanto maior for o time, maior será essa perda, até um ponto em que acrescentar membros ao time não aumenta a velocidade, mas diminui. Veja no gráfico a seguir como o esforço de relacionamento e comunicação do time cresce exponencialmente em relação à quantidade de pessoas:
Não tem nenhuma novidade aqui, já há uns 20 anos que o pessoal do movimento ágil descobriu e tem divulgado que uma equipe de software ideal tem entre 6 e 8 pessoas. Mas eu gostaria que você pensasse em outras relações exponenciais que são causas diretas de complexidade em projetos de software.
A primeira delas tem a ver com a quantidade de equipes. É claro, se há um limite natural para o tamanho das equipes de desenvolvimento, então vamos dividir nosso pessoal em várias equipes que trabalham em paralelo. Parece perfeito, mas se essas equipes estiverem trabalhando no mesmo software, ou mesmo se trabalharem em softwares diferentes mas que exijam muito alinhamento entre as equipes, os esforços de gerenciamento e de garantia de um trabalho integrado crescem exponencialmente em relação à quantidade de equipes.
Ou seja, não há apenas um limite natural para o tamanho das equipes de software, mas há também um limite natural para a quantidade de equipes trabalhando em um mesmo escopo de negócios.
Há outras relações como esta que você precisa conhecer. Por exemplo, a quantidade de código em projeto de software impacta diretamente e de maneira exponencial na dificuldade para se corrigir erros ou desenvolver código novo. É por isso que é tão comum que projetos de software cheguem a um momento em que a manutenção e evolução exige um esforço tão grande que os próprios desenvolvedores recomendam reescrever tudo.
O problema é que geralmente o software é reescrito dedicando-se mais esforço ao combate da complexidade nos níveis tático e operacional. Os programadores acham que dessa vez não vão cometer os mesmos erros, vão usar práticas e ferramentas melhores e tudo vai se resolver. Mas essa abordagem ignora as relações mais importantes no estudo da complexidade em projetos de software que são as que acontecem no nível estratégico.
E a mais importante delas é a relação entre complexidade e a quantidade de recursos em um software. Numa simplificação grosseira, podemos dizer que um software com 10 telas não é apenas duas vezes mais complexo do que um com cinco telas. Isso se dá porque os recursos de um software interagem uns com os outros. Cada nova funcionalidade incluída em um software que já está funcionando exige revisar todas as outras que possam ser impactadas por ela e testar tudo novamente.
Da mesma maneira que parece existir um limite natural para o tamanho das equipes e para a quantidade de equipes de software atendendo a um problema de negócios, há também um limite natural para o tamanho do próprio software.
É claro que você deve continuar investindo em equipes capacitadas, boas práticas e ferramentas para combater a complexidade, é claro que você deve organizar seu pessoal em pequenas equipes trabalhando de maneira ágil, mas nada disso é tão poderoso em manter a complexidade sob controle quanto duas ações simples que só podem ser feitas no nível estratégico:
A primeira delas é dividir o produto em produtos menores, independentes, reduzindo o escopo de trabalho de cada equipe. E a segunda, mais poderosa, é simplesmente fazer menos coisas. Bons gestores de projetos de software vão desafiar as justificativas de necessidade de cada feature, entendendo que uma redução de 20% de escopo no desenvolvimento inicial de um projeto de software tem um impacto exponencial de muito mais do que 20% em todo o TCO.
Em resumo, no nível estratégico: divida suas equipes, divida seus problemas e tente reduzir os escopos. O efeito disso sobre a complexidade vai reduzir seus TCOs, aumentar a produtividade e a qualidade das entregas.
Gostou? Estamos publicando um texto desses por semana. Assine nossa newsletter para não perder nada e ainda receber dicas exclusivas para gestores de TI e desenvolvimento.
23 de maio de 2023
