Fiquei insatisfeito com todos os softwares que já lancei. Em parte porque, como muitos desenvolvedores de software, sou perfeccionista. E então, inevitavelmente, há … problemas:
- O cronograma foi muito agressivo e muito curto. Precisamos de mais tempo!
- Tivemos problemas técnicos imprevistos que nos forçaram a fazer concessões com as quais não nos sentimos confortáveis.
- Tínhamos o projeto errado e precisávamos alterá-lo no meio do desenvolvimento.
- Nossa equipe sofreu atritos internos entre os membros da equipe que não havíamos previsto.
- Os clientes não eram quem pensávamos que fossem.
- A comunicação entre os designers, os desenvolvedores e a equipe do projeto não foi tão eficiente quanto pensávamos.
- Superestimamos a rapidez com que poderíamos aprender uma nova tecnologia.
A lista é longa. Razões para o fracasso em um projeto de software são inúmeras.
No final do ciclo de desenvolvimento, o senhor acaba com software que é uma sombra pálida do monumento brilhante e glorioso à engenharia de software que o senhor imaginou quando começou.
A essa altura, é tentador jogar a toalha, adicionar mais tempo ao cronograma para que o senhor possa fazer tudo certo antes de enviar o software. Porque, afinal de contas, os verdadeiros desenvolvedores enviam.
Estou aqui para dizer aos senhores que isso é um erro.
Sim, o senhor fez um monte de coisas erradas nesse projeto. Mas o senhor também fez um monte de coisas erradas que o senhor ainda não sabe. E não há outra maneira de descobrir o que são essas coisas até que o senhor envie essa versão e a coloque na frente de usuários e clientes. Eu acho que Donald Rumsfeld colocou isso da melhor forma:
Como sabemos,
Existem os conhecidos.
Há coisas que sabemos que sabemos.
Também sabemos que
Existem incógnitas conhecidas.
Isso quer dizer que
Sabemos que há algumas coisas que o
que não sabemos.
Mas também há incógnitas desconhecidas,
As que não conhecemos
Não sabemos.
Diante da inevitável tristeza do fim do projeto – repleto de compromissos e soluções rápidas e parciais totalmente insatisfatórias – o senhor poderia se acalmar e lamber as feridas. O senhor poderia se reagrupar e passar mais alguns meses corrigindo essa versão antes de lançá-la. O senhor pode até se sentir bem consigo mesmo por ter tomado a decisão difícil de acertar a engenharia antes de lançar no mundo mais um software incompleto e cheio de bugs.
Infelizmente, esse é um erro ainda maior do que enviar uma versão defeituosa.
Em vez de passar três meses consertando essa versão em um laboratório estéril e isolado, o senhor poderia estar gastando esse mesmo período de três meses ouvindo o feedback de pessoas reais e honestas, incômodousuários dedicados do seu software. Não o software como o senhor o imaginou e os usuários como o senhor os imaginou, mas como eles existem no mundo real. O senhor pode dar a volta por cima e usar esse feedback direcionado do mundo real não apenas para corrigir todas as partes ruins da versão 1, mas gaste todo o seu orçamento de desenvolvimento de forma mais eficiente, com base em dados concretos de uso de seus usuários.
Não estou dizendo que o senhor deve lançar uma porcaria. Acredite em mim, somos todos perfeccionistas aqui. Mas o mundo real pode ser um lugar cruel e implacável para nós, perfeccionistas. É mais sensato deixar para lá e perceber que, quando seu software cai na costa rochosa do mundo real, a decepção é inevitável… mas pode ser consertado! O que é importante não é tanto o estado inicial do software – na verdade, alguns dizem que se o senhor não está envergonhado com a v1.0, não a lançou cedo o suficiente – mas o que o senhor faz depois de liberar o software.
A velocidade e a capacidade de resposta da sua equipe ao feedback do usuário definirão o tom do seu software, muito mais do que qualquer lançamento isolado. É nisso que o senhor precisa ser bom. Não o ideal platônico de enviar um software mítico e perfeito, mas ser sensível aos seus usuários, aos seus clientes, e demonstrar isso por meio do ato de melhorar e refinar continuamente o seu software com base no feedback deles. Portanto, na medida em que o senhor está otimizando para lançamentos de software quase perfeitos, está otimizando para a coisa errada.
Não há pergunta que, para qualquer orçamento de tempo que tenha, o senhor acabará com um software melhor se fizer o lançamento o mais cedo possível e depois gastar o resto do tempo iterando rapidamente com base no feedback do mundo real.
Portanto, o senhor pode confiar em mim: mesmo que a versão 1 seja uma porcaria, envie-a mesmo assim.