Se produzir software custasse zero, tudo bem. Mas custa dinheiro.

Esta precisamos agrupar com outra para responder:

Por fim, quem já viu o “making the matrix” que vem no DVD do Matrix (1)? O produtor (GP) explica como eles conseguiram fazer o filme a um custo tão baixo. Porque os diretores conseguiram ver todo o filme no storyboard. Não precisaram ir filmando para irem apurando a idéia. Foi um Waterfall. Matrix!

Criar um software custa dinheiro, muito dinheiro, mas o preço de escrever documentos de requisitos extensos e extensivos logo como primeira coisa no desenvolvimento é muito maior que o preço do desenvolvimento em si. Uma análise deste tipo não pode estar errada ou o projeto como um todo falha.

Infelizmente nas últimas décadas só vimos mais e mais análises falhando porque ninguém consegue prever o futuro de antemão, porque o negócio exige mudanças no escopo do sistema, etc.

A comparação com a criação de um filme não faz sentido. Um dia de filmagem para este projeto custa uma fortuna, o elenco ganha mais por hora que todos os indianos juntos ganham no ano, só as lentes das câmeras custam o preço de carros. Neste caso pode ser mais barato pagar o preço de tentar adivinhar o futuro e modelá-lo completamente em uma ferramenta gráfica do que desenvolver incrementalmente, cena-a-cena. O mesmo para a construção de prédios e aviões, mas não para software.

Software de qualidade é construído para ser flexível e as plataformas atuais suportam isso de maneira muito razoável.

Em geral, o software será feito para alguem, que tem um tanto de dinheiro “fixo” para resolver um problema num prazo máximo. Como convencer alguem que vai pagar a conta que a quantidade de dinheiro que ele vai gastar vai ser definida de forma incremental, bem como o prazo?

Existe um argumento prático: eu posso dizer que vai custar X quando sei que vai estourar o orçamento ou podemos trabalhar no mundo real e investirmos este X incrementalmente. Mas ainda que o argumento não valha para você não tem problema: podemos trabalhar com custo fixo em metodologias incrementais, o RUP por exemplo quase sempre funciona assim.

Para alguns projetos nunca antes realizados, inovadores, é realmente complicado prever e o waterfall falha totalmente. Mas… assim como desenvolver software não é igual a outras engenharias, nem todo desenvolvimento é iegual ao outro. Tem aquele projeto inovador, diferente, nunca antes feito, e tem aquela n-ésima ocorrência de outro website similar a outro já feito antes. Para este caso, é possível fechar escopo antes de sair fazendo.

Se fosse simples assim seria muito mais lucrativo comprar software pronto ao invés de desenvolver o seu. Comprar algo pronto é quase sempre melhor que criar algo novo mas a maioria das aplicações possui algo que não se encontra no mercado, e muitas vezes este é o diferencial da empresa.

Veja as grandes indústrias. Para domínios como ‘contas a pagar’ geralmente compra-se algo de prateleira, um ERP ou coisa que o valha. Para algo que realmente importa, para negócio da empresa, dificilmente compram algo pronto. Mais e mais os componentes secundários do software (segurança, gráficos, servidores, planilhas, transações, armazenamento, etc.) são ‘comprados prontos’ em frameworks e derivados mas o desenvolvedor continua focado em implementar regras de negócio daquele cliente.

Desenvolver software customizado é algo feito em exagero em muitos aspectos, muita cosia deveria ser comprada e não recriada, mas boa parte dos projetos são únicos em seu segmento porque trazem o diferencial, cultura e demais atributos específicos da empresa em questão.

Olhem o consumidor - “Tenho este dinheiro limitado e preciso do resultado até o dia D - do contrário, todo esforço terá sido em vão, pois ou o dinheiro acaba e você pode jogar tudo fora ou então a janela de oportunidade se vai e você também pode jogar tudo fora”.

Infelizmente vejo uma desconsideração total pela figura de quem paga pelo serviço. Todos nós somos consumidores. Já pensou fazer sua casa num método que ao longo do tempo o preço e prazo serão definidos? E se seu dinheiro acaba? Vai morar ná versão pré-acabada da casa? Tem até ente que topa isso… mas…

Novamente você está fazendo uma analogia ruim comparando com construção civil. Uma casa com apenas um banheiro é inútil para seu usuário mas software com 30% das funcionalidades prontas não.

Acho que você se enganou fortemente quanto ao consumidor. Se eu tenho R$1000,00 e quero uma Ferrari eu vou obter? Se uma mulher grávida tem todo o dinheiro do mundo e quer que o filho nasça aos 2 meses ela consegue? Se eu quero um prédio de dez andares construído em duas semanas eu consigo? Isso é falta de respeito? Falta de respeito é dizer para o usuário que ele vai conseguir obter o que quer naquele preço e naquele prazo sabendo que estatisticamente a maioria dos projetos definidos nestes termos falham miseravelmente. É anti-ético, até.

A proposta ágil é exatamente oposta. Colocamos o cliente como quem guia a situação: se ele quiser gastar apenas X e se não mudar de idéia dá para saber com uma boa margem quando tudo será implementado. Mas este é o cenário que estatisticamente quase nunca acontece, geralmente ele vai mudar de idéia.

A diferença é que em um modelo ágil nós falamos: “Ok, você pode mudar de idéia”.

Nós respeitamos tanto quem paga o software que ao invés de nos trancarmos por meses a fio para depois mostrar um teórico produto final que o cliente olha e diz “não era nada disso!” nós colhemos feedback a cada passo, e se você aliar isso ao fato de que o cliente pode mudar de idéia você tende a chegar ao software como era esperado.

Também deixamos o cliente priorizar o que vai ser feito primeiro. Com isso o cliente consegue ter uma visão das partes mais importantes do seu sistema e mitigamos a maioria dos riscos envolvidos, para tecnologia e negócios.

Mas, de novo, tem situações novas que mais se assemelham com as pesquisas… não é possível prever exatamente quanto se vai gastar nem quando se terá o resultado. Talvez o erro seja querer que todo e qualquer desenvolvimento de software se encaixe num modelo ou em outro. Parece que tem muita emoção e pouca racionalidade neste debate.

Acho que você vai gostar muito da literatura sobre métodos ágeis, ela fala exatamente que cada caso é um caso.

Tem a ver com capacitação. Método é fundamental. Mas bons métodos, gestão e habilidades são como um tripé. No meu entender, tem gente que abusa de XP e outras metodologias ágeis por não terem a habilidade de antever as coisas. Não estou generalizando nem dizendo que XP não tem seu lugar. Critico apenas o uso do XP para observar resultados que uma pessoa experiente ou habilidosa anteciparia de bate-pronto. Muitas vezes o número de interações é excessivo ou abusivo.

XP? A maioria do que falei aqui se aplica em RUP ou qualquer metodologia iterativa incremental.

Se seu desenvovledor entende tanto do domínio que pode se antecipar ao usuário é algo fantástico, mas cuidado. Desenvolvedores (geralmente) não são pessoas que lidam com o negócio e tendem a construir mega-aplicações cheias de funcionalidades inúteis. Com o acompanhamento direto e feedback do cliente que uma metodologia iterativa dá você pode deixar o feedback do cliente podar as asas do desenvolvedor e economizar rios de dinheiro ao não implementar coisas que não serão usadas.

Enfim, que a racionalidade reine em detrimento das modas.

E que a inovação não seja engolida pelo senso comum ;)

Olhem o consumidor - “Tenho este dinheiro limitado e preciso do resultado até o dia D - do contrário, todo esforço terá sido em vão, pois ou o dinheiro acaba e você pode jogar tudo fora ou então a janela de oportunidade se vai e você também pode jogar tudo fora”.

Infelizmente vejo uma desconsideração total pela figura de quem paga pelo serviço. Todos nós somos consumidores. Já pensou fazer sua casa num método que ao longo do tempo o preço e prazo serão definidos? E se seu dinheiro acaba? Vai morar ná versão pré-acabada da casa? Tem até ente que topa isso… mas…

Mas, de novo, tem situações novas que mais se assemelham com as pesquisas… não é possível prever exatamente quanto se vai gastar nem quando se terá o resultado. Talvez o erro seja querer que todo e qualquer desenvolvimento de software se encaixe num modelo ou em outro. Parece que tem muita emoção e pouca racionalidade neste debate.

Por fim, quem já viu o “making the matrix” que vem no DVD do Matrix (1)? O produtor (GP) explica como eles conseguiram fazer o filme a um custo tão baixo. Porque os diretores conseguiram ver todo o filme no storyboard. Não precisaram ir filmando para irem apurando a idéia. Foi um Waterfall. Matrix!

Tem a ver com capacitação. Método é fundamental. Mas bons métodos, gestão e habilidades são como um tripé. No meu entender, tem gente que abusa de XP e outras metodologias ágeis por não terem a habilidade de antever as coisas. Não estou generalizando nem dizendo que XP não tem seu lugar. Critico apenas o uso do XP para observar resultados que uma pessoa experiente ou habilidosa anteciparia de bate-pronto. Muitas vezes o número de interações é excessivo ou abusivo.

Enfim, que a racionalidade reine em detrimento das modas.

Eu não falie que Fábrica trabalha em Waterfall mas Waterfall não é a única coisa danosa para um processo de desenvolvimento, seja ágil ou não. Como mencionei acima fábricas se baseiam em linhas de montagem e software de qualidade dificilmente consegue ser criado segundo este princípio. A falta da existência de uma dedicação e entendimento do time sobre o projeto é mais uma causa de tantas e tantas falhas.

A ‘impressão do Jornal’ no seu exemplo está tão fora do negócio principal (que é editar um jornal) que eu a coloco no mesmo nível de escrever um compilador, uma JVM/CLR ou um framework como Hibernate e isso nós já terceirizamos há séculos. Assim como apenas se editarmos um jornal com uma técnica nova nós o faríamos na redação (ou pelo menos acompanharíamos da redação) em software se a tecnologia de infra-estrutura é commodity ela é tratada como tal. Acontece que se a maior parte do desenvolvimento de software fosse commodity não teríamos tantos softwares sendo desenvolvidos, essa simplesmente não é a realidade. Apesar de uma grande ‘zona cinza’ relativa aos domínios cada um tem sua peculiaridade e por isso somos pagos para desenvolver sistemas novos e por isso precisamos da nossa atividade sendo tratada como criativa (não necessariamente artística) e não como uma atividade previsível como montar um equipamento segundo um plano bem formado (note que a criação do equipamento em si por engenheiros não é feita no esquema de fábrica -apenas a montagem. Interessante, não?). Então, dado que:

1) A maior parte do desenvolvimento de sistemas é relacionada a um negócio
2) Mesmo as empresas que desenvolvem coisas não ligadas ao negócio (seriam análogas à impressão neste caso) não trabalham com fábricas (JBoss/Red Hat, Bea, Oracle, Sun, Thoughtworks, Jetbrains, Eclipse Foundation, Microsoft… só para citar algumas)

As fábricas não possuem espaço real em desenvolvimento de software que não como modelo de negócios que foca em baixo custo e qualidade zero.
Note que isso não tem anda a ver com terceirização que quando bem feita traz resultados. Fábricas não são terceirizações bem feitas.

[]s

Concordo que não devemos esperar SCRUM de quem nunca entendeu o RUP mas que eu saiba fábricas não estão restritas ao modelo waterfall.

E mais, existem certos tipos de projetos que se encaixam bem no perfil de fábrica. Seguindo seu exemplo, a impressão do jornal poderia ser delegada à um terceiro (uma fábrica ágil ou não). O software que representa o “core” do negócio, dependendo da complexidade EXIGE UMA ABORDAGEM TOTALMENTE DIFERENTE. Aí estou contigo!

Mas aí vejo alguns problemas:
1. A maioria das pessoas têm dificuldade para diferenciar software de negócio do que não é associado diretamente ao negócio.
2. É preciso muita disciplina para que velhos hábitos não sejam despertados ou para que ajustes possam ser feitos rapidamente. Um exemplo, o cliente deve sempre interagir diretamente com desenvolvedores especializados e não com analistas de telas e fluxogramas.

Portanto fábrica de software não é o problema IMHO, mas as pessoas, elas precisam entender que algumas atividades têm essa “natureza artística” que você menciona.

(E também porque já trabalhei com/para ou já comprei serviços destas empresas e sei bem que não funciona.)