O software muda.
Mas por quê? O software é um produto gerado com o intuito de resolver problemas anteriormente solucionados pela mente humana. Portanto, são problemas muito complexos. Os produtos convencionais são produzidos para resolver problemas simples, geralmente físicos. No caso do software, os questionamentos são muito maiores. Assim, é natural que se perceba que o que foi pensado antes não atende realmente a necessidade, ou então não atende da melhor forma. Surge a necessidade de mudar. Todo processo tradicional, utilizado para produzir qualquer coisa, impõe limites a mudanças. Ao chegar em um restaurante, normalmente conseguimos trocar nosso pedido caso este ainda não esteja sendo preparado. Caso o bife já esteja sendo frito, no mínimo ganhamos uma cara feia. Isto ocorre porque o restaurante terá um prejuízo material: um bife terá de ser jogado fora. No software, não existe prejuízo material. Por isso, a mudança parece custar menos.
Custa? Não sei. Como assim custar menos? Menos que o que? Lógico, não há o prejuízo material, mas temos o prejuízo homem/hora. Porém, não temos como medir este. Com certeza, o retrabalho não é integral quando uma mudança é sugerida. Não jogamos fora o trabalho anterior e fazemos tudo denovo.
Pois então, se sabemos que vai mudar, o que fazer? Os processos de software tradicionais, dirigidos a planos, cobram caro por mudanças. Normalmente, exigem estabilidade nos requisitos, e “te olham feio” quando aparece algo a ser mudado. A lentidão da resposta a mudanças encarece mais ainda o processo. No final, acabamos encaixando as necessidades no plano inicial e pronto. Ora, quem trabalhou com atendimento de clientes de software sabe que isso não é agradável. Passamos bastante tempo desenvolvendo algo que não deixa o cliente completamente satisfeito.
Além disso, um estudo recente de Michael Mah, da QSM Associate, relatou que, no final dos projetos pesquisados, não era possível encontrar metade dos planos originais para realizar uma comparação. Isto porque seguir o plano não é o objetivo principal. A grande meta é satisfazer o cliente.
A realidade é que as etapas dos processos burocráticos são comidas, ou feitas de qualquer jeito para entregar.
O desenvolvimento baseado em componentes é praticamente uma utopia. Os problemas que o software resolve são diversos e específicos. Somente algumas partes dos problemas são comuns. Essas subdivisões que são reaproveitadas em outros projetos podem constituir um framework, promovendo facilidade no reúso. Mas a idéia de compor um software através da junção de módulos, sem precisar agregar nenhuma parte nova, não condiz com a realidade. Então, num ponto onde seria necessária uma mudança, é provável que a estrutura montada para reaproveitar o máximo os componentes existentes tivesse que ser refeita, ou então um componente teria que ser modificado.
Não é no sentido de “se não pode vencê-la, junte-se a ela” que promovo o processo orientado a mudanças. Promovo o processo orientado a mudanças porque penso que este é um mercado muito chamativo. O cliente que não está comprometido com uma especificação formal e que está interagindo constantemente com a definição do software se sente no controle do processo produtivo. Isto é extremamente agradável para ele, dando um sentimento de dinheiro bem investido.
