Este é um assunto antigo e batido. Porém de grande relevância e ainda cheio de mitos, dúvidas e o pior: Cercado de resistências no dia a dia de equipes de desenvolvimento de software em empresas de consultoria e Software Houses de todos os portes.

As alegações para não utilizar um processo ou método de desenvolvimento são sempre as mesmas:

• Nós não temos tempo, o prazo é muito curto!
• O cliente não vai querer pagar por isso…
• Somos pagos para criar software, não documentos!
• Isto aumenta demais o custo do projeto.
• Já sabemos o que precisamos fazer, é só programar!
• A demanda é muito simples, não precisamos disso…
• Na prática, esta coisa de processo não funciona.

Mas então qual é o motivo para a alta taxa de insucesso dos projetos de software? Afinal, se a estimativa de custo e prazo estavam corretas e o escopo estava tão claro ou era tão simples que nem mesmo era preciso fazer uma análise mais aprofundada, o que deu errado? Geralmente algumas das seguintes situações ocorrem:

• O prazo é excedido (e frequentemente numa taxa absurda que, por vezes, ultrapassa até a faixa de 100% do prazo estimado);
• O custo é excedido (e frequentemente as consultorias levam prejuízo com projetos que, a princípio, pareciam ter uma ótima margem de lucro);
• A entrega é um produto muito distante das expectativas do cliente, ou seja, eles esperavam uma maçã, mas entregamos algo semelhante a um abacaxi que, no fundo, não sabemos bem o que é…

E ainda podemos observar os seguintes sintomas durante o andamento do projeto:

• O cliente reclama o tempo todo (do prazo, do escopo, da qualidade, da atenção dada ao projeto e muitas outras coisas);
• A equipe se desfaz “repentinamente” (as pessoas vão para outros projetos ou para outras oportunidades de emprego);
• A equipe não sabe o que fazer ou como fazer as coisas (projeto e funcionalidades mal compreendidos);
• A equipe se perde em meio as atividades (não sabem quais os próximos passos);
• A entrega não é clara (nem para o Gerente do Projeto, nem para a equipe e nem para o cliente);
• Grandes “mudanças”, como arquiteturais ou de modelagem de dados, são descobertas no meio ou até mesmo no fim do projeto. A palavra está entre aspas, pois geralmente não são mudanças, mas sim necessidades mal compreendidas e as vezes que até foram sinalizadas pelo cliente desde o início.

Vários outros sintomas poderiam ser citados e certamente qualquer pessoa que trabalha em projetos de software se identificaria com cada item da lista, lembrando-se de situações que viveu na própria pele. E o motivo é simples: A forma como fazemos software repete viciosamente a receita falha de não seguir um processo na prática.

A maioria das grandes consultorias possuem um processo, geralmente inspirado no RUP. E até possuem certificações de qualidade. Apesar disto, o problema persiste. Por quê? Basta pensar por alguns segundos e qualquer profissional da área vai se lembrar de experiências onde o processo e a documentação era apenas uma “burocracia que tinham que seguir” para entregar o projeto. Quantas vezes a documentação é feita DEPOIS do desenvolvimento do software, quando deveria ser a base para a sua construção? Em síntese: Apenas para “inglês ver”.

Se o processo não é implantado de fato na organização ele se torna um grande fardo para os profissionais que deveriam ser resguardados e assessorados por ele. Implantar um processo de desenvolvimento não é apenas criar um monte de modelos de documentos. Também não se trata de conseguir um certificado para a empresa. Trata-se na verdade de incorporar um processo ou método à cultura da organização, de treinar e envolver os profissionais, além, é claro, de seguir de fato o processo e não apenas “ter para constar”.

Quando uma organização busca uma certificação de qualidade baseada em processo, mas não implanta este processo de fato, ela apenas GASTA dinheiro. Quando ela implanta, ela investe. Mas não é um investimento para curto prazo e talvez este seja um dos motivos pelos quais muitos gestores não consigam ver com o devido valor tal investimento.

Mas o que um processo pode fazer de concreto pela organização ou pelo projeto? É fácil entender a necessidade de se planejar algumas coisas: A construção de uma ponte, um prédio ou um viaduto. E até coisas mais simples: Uma viajem, as férias ou o casamento. É fácil olhar para estas necessidades e pensar “seu eu não me preparar e planejar, acho que pode dar errado”. Mas por alguma razão as pessoas não tem este mesmo instinto ou consenso quando o assunto é “software”. Elas acreditam que “de alguma forma mágica” tudo será construído muito rapidamente e, como computadores são incríveis, o sistema vai saber fazer tudo o que elas imaginarem (mesmo se imaginarem depois de o sistema já estar pronto). Sei que não preciso dizer mais direi: Nada disso vai acontecer.

Como qualquer outra coisa (e eu diria muito mais) a construção de softwares precisa ser minuciosamente planejada para que haja um mínimo de qualidade e para que não se jogue dinheiro fora (e muito) devido a fatores como:

• Pedidos desnecessários (coisas que o cliente pediu ou acha legal ter, mas nunca vai precisar);
• Prazo e/ou esforço mal estimados;
• Retrabalho e/ou perda de produção devido a necessidades mal compreendidas ou mal implementadas;
• Perda de produtividade por questões de má gestão da equipe – profissionais frustrados ou desmotivados produzem muito menos e com baixa qualidade;
• Desgaste no relacionamento com o cliente que, aliás, quando está insatisfeito não volta.

Desta forma podemos dizer acertadamente que ter um processo significa pensar e planejar antes de fazer. Consequentemente, isto significa diminuir custos e aumentar a lucratividade. Além disso, ao se diminuir custos tornamos a organização mais competitiva. E estas não são razões ruins para se decidir por um investimento.

E será que funciona? Pense bem: Organização, planejamento e métodos funcionam para qualquer outra coisa. Isto apenas não é diferente para o assunto “construção de software”. E por que haveria de ser?

Aí vão alguns conselhos para quem ainda pensa que um processo de desenvolvimento é só uma teoria que não pode ajudar:

• Se o tempo é curto hoje, ele será bem menor depois que o projeto não estiver andando adequadamente por falta de entendimento, falta de definições e, principalmente, depois que parte dele precisar ser refeito ou reestruturado devido deficiências durante a concepção (que, aliás, pode nem ter sido feita);
• Se o custo já está elevado, ele será muito maior quando a equipe for forçada a fazer várias horas extras para entregar o projeto que já está atrasado. Por causa daquelas “mudanças” que só são descobertas no meio ou no fim do caminho;
• Se o cliente não quer pagar pelo que não entende (o processo e os documentos), muito menos irá pagar pelo atraso ou pelo produto de má qualidade;
• Nada é tão simples quanto parece. E se parece, é porque você não entendeu;
• E por último, mas não menos importante, planejar, na prática, é o que funciona! Se planejando temos problemas, sem planejamento temos muito mais.