A armadilha da previsibilidade – Parte I
O ser humano busca por natureza entender e controlar seu ambiente. Este desejo por um ambiente mais previsível vem...
O ser humano busca por natureza entender e controlar seu ambiente. Este desejo por um ambiente mais previsível vem de tempos antigos e teve um impacto direto no nosso caminho para desenvolver todas as ciências: boa parte da curiosidade que resultou no nosso avanço científico e tecnológico vieram do objetivo de entender e controlar a natureza, essenciais para o nosso bem estar.
Porém já há muito tempo o homem descobriu que nem tudo pode ser efetivamente previsto. Só para citar um exemplo, um vinicultor que está preparando uma nova safra de vinhos sabe que não pode prever exatamente qual vai ser a qualidade de seu produto final -— a quantidade de variáveis é tão grande e sua inter-relação tão complexa, que o resultado final tem sempre um grau de surpresa.
Estas situações, que são muito comuns, não tiraram do homem seu ímpeto de buscar relações claras e previsíveis de causa-efeito em tudo que encontra. Na verdade, a impressão que temos é que os sistemas complexos, onde tais relações não são previsíveis, são a exceção. E mais ainda, que nós só "nos conformamos" com elas depois de muito tentarmos, sem sucesso, prevê-las e controlá-las.
A área de desenvolvimento de software vem passando por uma etapa assim. Há décadas as pessoas têm criado e evoluído processos de desenvolvimento de sistemas que consideram que esta atividade pode ser controlada e prevista. Este tipo de visão gerou as metodologias tradicionais de desenvolvimento, como por exemplo o RUP, e os resultados foram sempre desanimadores.
Mais recentemente, um conjunto de metodologias ágeis, como Scrum e XP, vêm surgindo como uma alternativa para os processos mais tradicionais. Estas metodologias têm em sua base a visão de que o processo de desenvolvimento de software não é algo de todo previsível, e portanto definem um modo de trabalho que permita tirar o melhor resultado do processo, sem exigir que o resultado final seja o que se imaginava no princípio (até porque consideram que isto é impossível). Estas metodologias têm provado ser extremamente efetivas e são atualmente utilizadas pela grande maioria de empresas baseadas em software (como Google, Microsoft, SAP e Facebook, só para ficar em exemplos "pequenos"). Mas com o sucesso destas técnicas, muitas vezes seus princípios têm sido esquecidos, e tem sido comum encontrarmos empresas buscando ao mesmo tempo adotar métodos ágeis, mas exigindo previsibilidade destes mesmos processos.
A previsibilidade é incompatível com o desenvolvimento de software por uma série de motivos. Vou citar aqui alguns deles:
A nossa capacidade de imaginar um novo software é bastante limitada. Um sistema de computador automatiza geralmente um ou mais processos complexos em uma empresa. Para isto, precisa lidar com um conjunto enorme de situações e cenários. Quando "imaginamos" um novo sistema, geralmente pensamos de maneira "geral" no processo, mas não somos capazes de antever todas as situações que o software vai ter que tratar. Num caso mais real, o sistema vai ter que atender a diversos stakeholders, e a "integração" entre estas visões é mais um ponto onde naturalmente vão ocorrer "gaps", que apenas o processo meticuloso de desenvolvimento vai conseguir trazer à tona, e que precisarão ainda ser definidos e tratados.
A primeira visão sobre isto é imaginar que basta um trabalho de análise bem feito para que tais incertezas e conflitos sejam evitados, e foi este o caminho que as metodologias de software trilharam, criando documentos, modelos e templates cada vez mais detalhados. Mas mesmo aumentando significativamente o esforço nestas fases de especificação, e consequentemente o custo e o prazo, percebemos que os problemas continuam a ocorrer.
Outra questão que se mostra crítica no desenvolvimento de software é a nossa própria linguagem. O português (assim como qualquer outra língua) permite sempre várias interpretações diferentes para um mesmo texto. A própria beleza da língua vem em parte desta flexibilidade. Se somamos a isto a tendência natural do ser humano de sempre buscar a confirmação do que ele já sabe, não é difícil entender porque temos sempre tantos mal-entendidos com as especificações de sistemas.
Todas as técnicas já desenvolvidas para se "documentar" previamente o que o software deve fazer ou se baseiam no português e por isso sofrem do problema da dubiedade, ou tentam criar uma nova representação, que além de trazerem o problema de uma nova linguagem que precisa ser aprendida pelos envolvidos, só conseguem representar partes muito pequenas do sistema, e por isso tem utilidade restrita.
A melhor linguagem já inventada que não deixa nenhum espaço para diferentes interpretações são as linguagens de programação, e o processo de traduzir uma necessidade de negócio é justamente o projeto de desenvolvimento de software. Ou seja, as dubiedades só terminam mesmo quando o sistema está desenvolvido.
Isto não quer dizer que não se deve discutir ou documentar o sistema previamente, mas apenas que precisamos considerar que estas técnicas possuem, por natureza, limitações. E a máxima de que "a única medida de progresso confiável de um projeto de software é software funcional" precisa ser levada a sério.
A parte técnica do trabalho também traz um bom grau de incerteza. É importante lembrar que todo trabalho de desenvolvimento é fundamentalmente fazer algo novo, e por isso todo desenvolvedor já se deparou com atividades que ele mesmo previa que durariam poucas horas, e acabam durando dias. Qual é o erro de uma estimativa que temos em um caso como este? É fácil termos situações em que a diferença chega a 800%! É viável tentar ter estimativas precisas de projetos quando temos este nível de discrepância em atividades individuais?
Novamente pode-se imaginar que isto é decorrente de "erro" do desenvolvedor, mas a realidade é que simplesmente não é possível controlar todos os aspectos envolvidos em uma atividade de desenvolvimento.
Outra tentação é se imaginar que "na média" estes desvios se compensam, mas as formas tradicionais de execução dos projetos fazem justamente o oposto e intensificam ainda mais as distorções. Isto porque a tendência natural das pessoas, quando atuam em uma tarefa com um prazo definido, é se programarem para finalizá-la na data definida. Mesmo quando a atividade pudesse ser finalizada antes, acaba terminando no prazo, e quando ocorre qualquer situação não prevista, o prazo estoura.
Finalmente, outra constatação importante é o aprendizado gerado por um projeto de desenvolvimento de software. Justamente pela necessidade de se detalhar e definir diversos pontos que eram "cegos" para os envolvidos no projeto, o projeto acaba trazendo para todos um grande aprendizado sobre o sistema, e até mesmo sobre o negócio que se busca informatizar. Isto faz com que a visão sobre o que o sistema deve fazer evolua durante o projeto, e é no mínimo um grande desperdício não aproveitar todo este aprendizado. Atrelado ao fato de que o próprio ambiente de negócios está mudando, não permitir que o projeto evolua durante o trabalho diminui tremendamente a capacidade de geração de valor.
Novamente aqui temos uma tendência a imaginar que os processos de gestão de mudanças dos projetos tradicionais podem ser a resposta, mas na prática eles são sempre rígidos demais para dar conta da real dinâmica necessária para o projeto.
Mesmo com tudo isso, ainda é muito comum as empresas buscarem trazer "previsibilidade" ao seu processo de desenvolvimento de software, exigindo a definição de prazos, custo e escopo antes de começar qualquer desenvolvimento. Mas como vimos, esta "previsibilidade" não passa de uma ilusão, e sua busca costuma trazer consequências muito negativas, tanto para o projeto em si, como para a cultura e o ambiente de trabalho.
No próximo artigo desta série, vamos analisar os impactos que esta busca acarreta, e quais alternativas temos para encarar esta situação, mostrando como as empresas podem reduzir os desperdícios e potencializar seus resultados através de um novo enfoque na forma de gerir e controlar seus projetos.