Abrindo a mente

Tradição é uma forma de transferir conhecimento. Os economistas Friedrich Hayek e Thomas Sowell explicaram que tradição é um meio economicamente eficiente de transferir e obter conhecimento de todos os tipos. Sowell observou que a tomada de decisões consome tempo (um recurso valioso), e as tradições culturais oferecem uma maneira barata e consensualmente aceita para economizar os recursos despendidos na tomada de decisões feita de forma independente (SOWELL, 1996).

As tradições são geralmente consideradas antigas, inalteráveis e profundamente importantes. Quando se escava suas origens, nota-se que elas serviram no passado como uma resposta a determinado problema. Se esse problema ainda nos aflige, não há razão para ignorá-las apenas para parecermos modernos ou revolucionários. Mas quando não nos atentamos para as mudanças a nossa volta, saimos do campo da tradição para entrarmos no conservadorismo.

O conservadorismo se contrapõe a mudanças nos usos e costumes da sociedade, por ser baseada no pessimismo antropológico. Assim, para os conservadores é a sociedade e seus hábitos e tradições que moderam e limitam a perversividade natural do homem. Nas palavras de Louis de Bonald: “Não são os indivíduos que formam a sociedade, mas a sociedade que forma os indivíduos”.

Pode parecer estranho, mas essa é uma frase que poderia ter saído de um gerente de projetos: “Não são os desenvolvedores que formam a projeto, mas o projeto que forma os desenvolvedores”. E se somos todos maus por natureza, devemos nos proteger de nós mesmos, no melhor estilo estamos-fazendo-isso-para-proteger-nossas-bundas. Temos medo de tudo: de falharmos, do futuro incerto, de não sermos entendidos, da equipe que não tem foco, do cliente indeciso…

Então nos cobrimos com a capa das tradições, o modelo ancestral e mecânico que sempre nos respaudou. E que nos economizou a energia da tomada de decisões, mesmo quando ela foi necessária. Então ouvimos coisas como essas: “O aplicativo não funciona, mas eu fiz tudo que exatamente como ditava o diagrama”. “O projeto não atende mais as necessidades do cliente, mas está totalmente dentro da especificação”. “O cliente não usará o software e nos amaldiçoará por sete gerações, mas ele vai pagar por tudo nos termos do contrato”. “Um ano é muito tempo, por isso fiz um cronograma que prevê o que acontecerá nos próximos doze meses”. “Não sei o que aconteceu, durante as reuniões parecia que tudo estava indo bem”.

Como se fossem Carlitos em Tempos Modernos, as pessoas se tornam parte da engrenagem processual, alheias aos seus reais objetivos, mas ainda presas pelas metas estipuladas. O projeto afunda, mas quando toca a sirene do almoço eu desligo meu monitor e saio. Está tudo aqui no regulamento, pode ver.

E se, por um segundo, abríssemos nossas mentes para novas possibilidades? Será que ainda precisariámos disso:

• Cronogramas que levam meses ou mesmo anos;
• Especificações Funcionais Utópicas;
• Debates de Escalabilidade;
• Reuniões de equipe intermináveis;
• A “necessidade” de contratar dúzias de funcionários;
• Números de versões sem sentido;
• Planejamentos cristalinos que prevêem o futuro;
• Testes de usuário irreais;
• Papelada inútil;
• Hierarquia de cima-para-baixo.

Muita coisa mudou desde a época em que os primeiros softwares foram escritos, saímos dos computadores do tamanho de casas para os mainframes e daí para os PCs, deixamos o processamento batch e chegamos nas LAN, e agora vivemos a era da internet e do SaaS. Apesar disso, muitas equipes ainda continuam desenvolvendo suas aplicações comerciais como se construíssem um sistema de defesa militar na década de 60. Por que?

Não é mais necessário perfurar centenas de cartões para criar uma versão testável de um software. Não é mais necessário esperar numa fila de processamento. Hoje se vê quase em tempo-real o resultado de uma implementação. Além disso, com pessoas cada vez mais bem-formadas, por que tratar a equipe como uma massa que deve ser contida e controlada, como se fóssemos contra-iluministas no século XVIII.

Na contra-mão de tudo isso, adotar as práticas dos métodos ágeis significa:

• Permanecer pequeno e ágil;
• Pular coisas que tentam representar a realidade (diagramas, gráficos, esquemas) e construir algo real;
• Iniciar a construção do software com a interface, telas reais que as pessoas irão utilizar, e evitar escrever um software errado;
• Entregar o que o cliente precisa e eliminar tudo que ele não precisa;
• Ter uma equipe pequena e coesa, não de especialistas, mas de generalistas.

Alguns achrarão todas essas idéias bastante naturais. Outros estarão firmemente presos a maneira tradicional de fazer as coisas. Mas o que queremos é apenas iniciar o debate. Dar um choque para que todos acordem e pensem sobre a necessidade de continuar fazendo as coisas como fazemos hoje. Nem tudo sobre as metodologias ágeis se aplicarão a todos os projetos. Não precisamos de mais de “um único sol no céu, um único soberano na Terra“. Queremos apenas aprender mais para continuar a fazer o que importa e jogar fora tudo que não faz mais sentido.

Se as portas da percepção estivessem limpas, tudo apareceria para o homem tal como é: infinito.

William Blake. The Marriage of Heaven and Hell

Dito isso, acho que estamos finalmente prontos para começar.