Como (tentar) prever a criatividade

Este é o primeiro artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.

---

Previsibilidade é quase o oposto de criatividade. À primeira vista, podemos colocar criatividade e previsibilidade em dois extremos do mesmo eixo. Para aumentar uma, é preciso diminuir a outra.

No extremo da previsibilidade temos organizações que têm somente capacidade de repetição. Suas atividades são facilmente gerenciadas por serem extremamente previsíveis. Uma forma de alcançar este grau de previsibilidade é inventar sempre a mesma coisa. O problema é que repetir a mesma coisa várias vezes não é inventar. Por isso que esses lugares altamente previsíveis são extremamente chatos para se trabalhar. Você está sempre fazendo as mesmas coisas. Escrevendo o mesmo relatório para o mesmo gerente.

No lado extremo da previsibilidade, temos fábricas tradicionais, com linhas de montagem e tudo mais, como as que Henry Ford projetou. Nestas fábricas tudo é extremamente previsível. Se colocarmos uma peça no começo da linha, podemos saber com uma boa precisão quando ela passará por cada um dos estágios. Essa previsibilidade é alcançada através de muita padronização e repetição.

No outro extremo estão as organizações que escolheram abandonar totalmente a previsibilidade em favor da criatividade. Essas inventam coisas maravilhosamente interessantes, mas não se pode confiar muito nelas para estabelecer prazos. Você sabe que dali vai sair alguma coisa surpreendente, mas ninguém sabe dizer quando. Estes lugares também são muito chatos para se trabalhar, porque parece que nunca vão acabar de construir nada. Sempre há um último retoque para ser feito. Sempre aparece um novo projeto interessantíssimo para deixar o anterior inacabado.

É deste lado que ficam alguns artistas, como Leonardo da Vinci. Ele era conhecido por atrasar as encomendas e tem gente que diz que às vezes ele até colocava alguns significados ocultos nas telas. Fazer uma encomenda a ele era receita certa para uma boa dor de cabeça. Ele não ia entregar no prazo e no final o que ele entregasse podia não ser muito bem aquilo que você tinha pedido. No entanto, ninguém pode dizer que ele não era criativo. O cara era a inovação em pessoa, inclusive foi pioneiro em muitas áreas de pintura, engenharia e anatomia.

É natural perguntar quantos carros uma fábrica pode produzir por dia. Mas não faz sentido nenhum perguntar a nenhum pintor que se preze quantos quadros ele pode fazer por mês. Cada quadro é uma obra única e o tempo de produção pode variar demais para que estimativa seja minimamente precisa.

Nenhum dos dois extremos é bom. A boa notícia é que não precisamos escolher entre preto ou branco. Há vários tons de cinza entre eles que podemos explorar.

Ao contrário do que possa parecer, não precisamos escolher entre uma e outra. Previsibilidade e criatividade não estão no mesmo eixo. As duas são ortogonais. Não precisamos necessariamente diminuir uma para aumentar a outra. Não é preciso ser imprevisível para ser criativo. Talvez as variáveis não sejam tão independentes como queiramos, mas também não são tão intrincadas que não dê para separá-las um pouco.

A menos que você esteja querendo reconstruir alguma coisa que já tenha construído, desenvolver software é um processo criativo. Só que nem todo programador pode se dar ao luxo de fazer como Da Vinci e desrespeitar prazos e demandas. É preciso ter algum grau de previsibilidade para agradar os clientes.

Para lidar com este problema é que foi inventada a iteratividade. O segredo é projetar o software em ciclos curtos chamados de iterações. No início de cada iteração, a equipe combina com o cliente o que deverá ser produzido durante um certo período de tempo e ao final deste período o cliente recebe um sistema funcional que pode ser testado. Pode ser que o sistema seja bem pequeno, minúsculo. Mas ele evoluirá ao longo do tempo até chegar uma hora que o cliente diga 'está bom, era isso que eu queria' e os programadores possam procurar um novo projeto.

Uma boa forma de se enganar é não entregar software rodando ao final da iteração. Você pode, no lugar disso, entregar um calhamaço de documentos, só para provar que não ficou parado o tempo todo. A idéia é que quem quer que esteja pagando pela sua empreitada possa validar esses documentos e dizer 'continue, você está no rumo certo' ou 'não é bem por aqui, acho que devemos mudar de estratégia'.

Quando se usa um documento para esse tipo de comunicação, uma de três situações pode ocorrer. A primeira é o cliente validar seu documento e assinar embaixo, só que ele estava pensando em uma coisa quando leu e você estava pensando em outra bem diferente quando escreveu. A segunda é ele não concordar com o que você escreveu e implicar com as menores coisas para ter certeza que você entende o que ele está querendo. Essa segunda situação pode facilmente descambar para um fluxo eterno de remendos ao documento que impede que a coisa de verdade seja construída. A terceira possibilidade é que ele valide o que você escreveu e esteja pensando no mesmo que você. Mas é mais fácil ganhar na loteria do que isso acontencer.

Esse problema não acontece com software rodando. Quando o produto está vivo na frente do cliente, não há espaço para interpretações erradas. O sistema faz exatamente aquilo que está fazendo ali, ao vivo, na frente dele. Se algo estiver errado ou puder ser melhorado, o produto é um objeto concreto para servir de instrumento na discussão. Ninguém vai precisar adivinhar o que o outro está pensando.

A chave para o equilíbrio entre previsibilidade e criatividade através de iterações está em achar um tempo de iteração que seja pequeno o suficiente para que as estimativas não fiquem muito distorcidas e grande o suficiente para permitir que alguma coisa de útil seja feita. Tudo isto ainda permitindo que a equipe possa exercitar sua criatividade.