A estória de Howard Scott Warshaw é um exemplo de como um prazo apertado gera produtos ruins, mesmo quando os melhores da indústira trabalham no projeto. Howard é um programador lendário da falecida Atari que escreveu vários sucessos, incluindo Yars Revenge, considerado um dos melhores vídeo-games já criados.
O prazo dado para criar o jogo do ET, que inclusive foi enterrado no deserto do Novo México nos EUA pela Atari, foi de apenas 5 semanas. Um prazo apertadíssimo para desenvolver um jogo que deveria vender 4 milhões de cópias, segundo a estimativa da época pela Atari.
O prazo apertado e as poucas condições de trabalho levaram à criação de um dos piores vídeo-games da História. O jogo foi um tremendo fracasso e muitos alegam que foi este jogo em particular que levou a Atari a quebrar. Na verdade, a Atari já vinha em dificuldades por conta dos computadores pessoais que estavam atraindo mais a atenção das pessoas na época.
O fato é que no desenvolvimento de software é preciso ter tempo para que as pessoas possam trabalhar com qualidade. Querer algo para “ontem” vai levar a um produto ruim, cheio de bugs, mal testado e que provavelmente vai capotar na primeira curva. Pode até vender bem de início, mas os reviews negativos dos usuários serão a pedra na lápide do produto.
Faça pouco, mas faça bem
Se o prazo é muito curto, diminua a quantidade de features que precisam ser implementadas para o lançamento do produto. Tentar completar o produto com prazo apertado fará com que você gaste muitos recursos depois, consertando todos os defeitos que deixou para trás.
Você pode completar as features depois do lançamento, atualizando seu produto à medida em que fica pronto. Na época de Warshaw o método de desenvolvimento de software era basicamente o waterfall, conhecido como método cascata: você ia de ponta a ponta no seu produto, sem a previsão de atualizações no meio do caminho. Ou seja, ao entregar o produto, acabou o desenvolvimento.
Hoje em dia, com os métodos interativos, o produto é atualizado constantemente. Trabalha-se com várias entregas que permitem que o produto seja ajustado durante o desenvolvimento. Use este fato a seu favor.
Ainda existe waterfall
Acredite se quiser: em pleno Século XXI ainda há empresas que trabalham usando o método waterfall. Todo mundo sabe que não funciona, todo mundo sabe que é grande o risco do produto final não ser aderente às necessidades do usuário, mas ainda há gente que insiste nesta metodologia fracassada por conta dos sucessos do passado.
O mundo mudou e também mudou a forma das pessoas consumirem software. Hoje em dia todo mundo espera por atualizações. Atualizações constantes, inclusive, são um sinal de que há alguém tomando conta do produto. Se o seu produto não tem atualizações constantes, o usuário passa a perceber que trata-se de um abandonware, ou seja, um software abandonado. Esta sensação é especialmente poderosa para aplicativos publicados nas lojas on-line.
Aprenda a dizer não
Este é um conselho de quem já andou nessa estrada, bateu de frente e saiu de ambulância: aprenda a dizer não quando te pedirem algo em um prazo que beira a fantasia. Muitas estórias de catástrofes na área de TI ocorrem por que até mesmo o developer compra a ideia de que é possível espremer um desenvolvimento completo em um prazo ridículo.
Eu já cai nessa. O prazo era ridículo, superestimei minhas capacidades e no fim das contas saí como culpado de não cumprir o prazo. E fui obrigado a engolir o meu orgulho. Quem mandou ser arrogante?
Dizer não pode poupar-lhe não só dores-de-cabeça mas pode poupar à sua empresa um belo de um prejuízo. É preciso usar o bom senso.