O que é sucesso num projeto de software?

Faço minhas as palavras do Miguel Honório, no artigo Definindo sucesso em projetos de software.

Tomei a liberdade de reproduzir aqui o gráfico que ele usou para demonstrar o panorama dos projetos de software nos útimos 18 anos:

Desde 1994, tivemos, em média, 29,33% dos projetos entregues no prazo previsto inicialmente, com o custo previsto inicialmente e com o mesmo escopo inicial. São quase 20 anos e ainda não conseguimos acertar nem a metade do que estimamos.

Isso é muito ruim. Péssimo!

Mas, por que? Será que apenas 30% dos clientes do planeta conhecem realmente seu negócio? Certamente não. Será que menos de 30% dos profissionais de TI do mundo todo sabem realmente desenvolver software? Novamente, claro que não.

Quantas vezes, ao apresentarmos uma nova tela para o cliente, não ouvimos: "é... tá legal... mas faltou um campinho aqui pra escrever uma observação." Se trabalhamos com estimativas (de tempo, custo e escopo) rígidas, sabemos que esse pequeno ajuste vai acarretar dedicação de tempo. E, como não gostamos de trabalhar de graça, também acarretará custo. Mas se o cliente precisa mesmo desse novo recurso, não pode ser sacrificado. Mesmo que ele tenha esquecido de dizer isso antes. E o desgaste de cobrar por uma coisinha simples não vale a pena. Então, normalmente atendemos ao pedido, que invariavelmente, vai acumulando para um monte de pequenas solicitações, que formam uma semana de trabalho gratuito. Aí achamos que o cliente é aproveitador e que não conhece o próprio negócio. Ruim, né?

Bem, essa é a visão do desenvolvedor. E a visão do cliente, qual seria?

Ao longo dos anos, tenho conversado com clientes a respeito do que eles pensam sobre nós, desenvolvedores. A opinião deles não é lá muito confortante. Eles nos acham topetudos, enrolões, pouco comprometidos, incompetentes. E dizem que nós falamos outro idioma, que muitas vezes não conseguem entender. Alguns acham que falamos difícil para podermos cobrar mais caro. Ou seja, somos um mal necessário.

Mas, se o cliente toca o negócio dele, significa que ele conhece, certo? Se viramos noites trabalhando e entregamos software, significa que somos comprometidos e que conhecemos as ferramentas, certo?

Então, qual o problema? O método de trabalho. Nós, desenvolvedores, não temos como saber, de antemão, as dificuldades que teremos durante o desenvolvimento do sistema. Os clientes, também, não conseguem pensar em todas as nuances de legislação, regras, campos de tela... antes de ver alguma coisa funcionando.

Pessoas insistem em ler documentos e ver diagramas, ao invés de terem software funcionando. O tempo gasto na elaboração desses artefatos poderia ser muito bem empregado no desenvolvimento das funcionalidades. Muitas delas levariam menos tempo para serem desenvolvidas do que a própria documentação detalhada, preparada antecipadamente.

E, por que, então, continuamos desenvolvendo software dessa maneira? Por tradição. E pela falsa impressão de previsibilidade. Mas, vamos encarar a questão de frente: não temos poder para prever o futuro. Ninguém tem. Por isso, parece que os clientes gostam do me engana que eu gosto, ou não estão de fato comprometidos com seu próprio negócio, ou sempre buscam alguém para culpar em caso de algum problema. Até parece que eles não sabem que temos a tradicional "gordurinha" no prazo e no custo. Gente, trabalhar software assim não é racional.

Tá, mas qual seria a solução para contratar desenvolvimento de software sem as estimativas iniciais? Para isso não tem solução, porque tudo que vamos fazer no mundo dos negócios, precisa de uma estimativa. Só que estimativa é o que o próprio nome diz: estimativa. Não é certeza.

Como desenvolvedores, temos a obrigação de estimarmos um prazo, com base no que o cliente diz. Ele, por sua vez, precisa saber que mudanças virão tão rápido quanto a primeira entrega de software. E que, se mudou o que precisa ser feito (escopo), também mudou o dia de entregar (prazo) e o quanto ele vai pagar por isso (custo). Para mais ou para menos.

Minha sugestão é: que tal contratar o desenvolvedor por mês? Se o cliente sentir que ele está enrolando, contrata outro logo no primeiro mês. Se o ritmo estiver bom, continua. Afinal de contas não é isso mesmo que vendemos, nossas horas de trabalho?

É muito normal vermos projetos 99% prontos. Incomum é vermos um cliente realmente satisfeito com os sistemas da empresa.

Leia o post do Miguel e faça o download do livro que ele recomenda. Leitura simples e bem prática, onde aprendi bastante quando estava ajudando a traduzí-lo.