A Versão 1.0 É Ruim, Mas Vamos Lançar Assim Mesmo

>> Traduzido e adaptado do artigo do blog Coding Horror.
>> Translated and adapted from this Coding Horror blog post.

Nunca estive contente com nenhum software que já tive de liberar. De certa forma, como muitos outros desenvolvedores, sou perfeccionista. Em cima disso, os problemas inevitáveis sempre aparecem:

• O cronograma é muito agressivo. Precisamos de mais tempo!
• Tivemos problemas inesperados que nos forçaram a tomarmos decisões desagradáveis.
• A arquitetura do sistema estava errada, precisou ser modificada no meio do projeto.
• Tivemos atritos na equipe, discussões que não puderam ser antecipadas.
• O cliente não era exatamente aquilo que achávamos.
• A comunicação entre arquitetos, desginers e desenvolvedores poderia ter sido mais eficiente.
• Superestimamos nossa capacidade de aprender uma nova tecnologia.

Essa lista continua e não termina. Razões para que um projeto falhe não faltam.

Ao final do desenvolvimento, você se depara com um sistema que é apenas uma sombra daquele monumento da engenharia de software que foi vislumbrado no início do projeto. Vem aquela tentação de jogar a toalha – acrescentar mais tempo ao cronograma para fazer a coisa do jeito certo. Afinal de contas, um desenvolvedor de verdade sempre libera uma versão.

Apesar disso, estou aqui para dizer exatamente isso: não liberar seria um erro.

Sim, você fez muita coisa errada nesse projeto. Além disso, também fez muitas outras coisas erradas das quais nem sabe ainda. E não há meios de descobrir quais são elas a não ser entregando seu sistema para os clientes e usuários. Donald Rumsfeld já disse sabiamente:

Como se sabe,
Existe o conhecimento conhecido.
Aquilo que sabemos que sabemos.

Também se sabe,
Existe o desconhecido conhecido.
Ou seja, sabemos que existe algo que não conhecemos.

Mas existe também o desconhecido não conhecido.
Aquilo que nem sabemos
Que não conhecemos.

Ao final de um projeto – marcado pelas gambiarras de última hora e pelas correçõe mal acabadas – você pode se curvar e limpar a bagunça. Reunir toda a equipe de novo e gastar algum tempo arrumando e melhorando a primeira versão antes de ser liberada. Pode até se sentir melhor por tomar essa decisão difícil, chamando arquitetos para discutir mudanças de última hora e evitando que seja entregue um sistema repleto de falhas e incompleto.

Infelizmente, isso é ainda pior que liberar o sistema com falhas.

Ao invés de gastar três meses arrumando problemas no ambiente estéril e isolado do laboratório, esse tempo poderia ser gasto ouvindo feedback de pessoas no mundo real, pessoas honestas do dia-a-dia, usuários (chatos?) dedicados do seu sistema. Não aquele sistema que você idealizou, nem aqueles usuários que você imaginava, mas um cenário verdadeiro e concreto. Pode usar esse feedback do mundo real para arrumar as partes verdadeiramente ruins da versão 1.0, gastando seu orçamento de forma muito mais eficiente, com base em fatos e carga concreta de usuários.

Não me entenda mal. Não quero dizer que se deva liberar um lixo de sistema. Acredite, somos todos perfeccionistas aqui. O mundo de verdade pode ser cruel e imperdoável para nós, perfeccionistas. Mas é mais saudável abrir mão da perfeição máxima e se dar conta de que quando seu sistema falhar inevitavelmente no campo de batalha, a decepção também será inevitável… porém… o problema pode ser arrumado! O que importa não é o estado inicial do sistema quando for liberado – alguns defendem a idéia de que “se você não tem vergonha da sua versão 1.0, é porque liberou tarde demais” – mas o que você faz depois de entregá-lo.

A velocidade com que sua equipe responde e resolve problemas é o que realmente marca e define a qualidade do sistema, muito mais do que uma simples versão impecável marcaria. É nesse ponto em que a perfeição se faz necessária. Não fique preso àquela utopia mística do sistema perfeito. Ao invés disso, gaste recursos demonstrando dedicação e tempo de resposta aos clientes e usuários, fazendo do feedback deles uma ferramenta importante e constante para melhorar e evoluir o sistema. De certa forma, quando você otimiza seus esforços para produzir um sistema infalível, está desperdiçando recursos.

Não tenha dúvidas de que, seja qual for seu cronograma ou orçamento, terá no mercado um sistema muito melhor se for lançado o mais rápido possível – conforme as possibilidades – e gastar todo o restante de seus recursos iterando rapidamente entre melhorias e feedback do mundo real.

Portanto, confie no que digo: Mesmo que a versão 1.0 seja ruim, libere assim mesmo.

== Jeff Atwood