Fabrica de software - vale a pena?

This message was edited 1 time. Last update was at 06/03/2008 15:18:26

Realmente quando falamos fábrica de software generalizamos, mas vou citar algumas coisas que vejo no mercado, e acredite, conversei e pesquisei bastante sobre isso nos últimos 5 anos:

1. Waterfall: O modelo é muito dispendioso. Essa história de ficar 2 meses no cliente capturando requisitos é caro demais. Além de caro, é arriscado, pois documento word e diagramas aceitam qualquer besteira. É abstrato demais. Sempre que chegamos no código vemos que os requisitos estão incertos, ambíguos, conflitantes e etc... Waterfall geralmente destrói as qualidades internas, externas e do próprio projeto.

2. Gantt Charts: Qualquer %Complete que um gerente de projetos de software te mostrar num Gantt Chart é MENTIRA. O software é produto de um meio de produção atômico. 10% ou 100% de requisitos capturados não quer dizer nada para o andamento do projeto. Gerentes de Projeto PMP também não quer dizer nada para projetos de software. (leia meu artigo "Entregue Software Funcionando! Gerenciamento de Projetos Ágil" na MundoJava 26). Veja também esse screencast:

http://www.aspercom.com.br/ead/mod/resource/view.php?id=250

3. Selos (CMMI, ISO): Não garantem quase nada com relação à qualidade interna e externa da aplicação. Minha visão sobre CMMi é que nada adianta você ser maduro em um processo que é ruim. Como o Jacobson diz: "É fácil um bom processo ser mensurável, porém, dificilmente um processo mensurável é bom". Um processo mensurável necessariamente é dispendioso. É difícil o empresariado brasileiro compreender que é caro ter previsibilidade em projetos de software. Métricas e estimativas também não oferecem qualquer tipo de certeza com relação a isso.

4. Falta de Skill: É um mito comum achar que fábricas de software possuem os melhores analistas, os melhores arquitetos, os melhores programadores. Sim, temos importantes exceções, mas tenho visto que bons analistas, bons arquitetos e bons programadores não acreditam no modelo de fábricas de software em geral.

5. Custo: No meu artigo citado acima, cito as 3 qualidades do software: qualidade interna (o software é fácil de manter e evoluir), qualidade externa (o software atende o negócio), qualidade do projeto (o software foi feito no menor custo e prazo possível). Essencialmente fábricas de software tem menos responsabilidade com a qualidade interna principalmente. O problema é que 90% do custo de um software no seu ciclo de vida é manutenção. Se o software tem pouca qualidade interna, o custo de manutenção é potencializado. A qualidade interna de projetos de software em fábrica é ruim pois a responsabilidade do projeto é somente construção. Geralmente não é a fábrica que mantém o software depois de "pronto".

6. Existem exceções, mas são raras. Já trabalhei em fábricas durante 3 anos e tínhamos projetos ágeis e iterativos (logicamente também tinha waterfall, mas poucos), mas isso é exceção. Pouquíssimas fábricas trabalham iterativamente e com escopo negociável. Não conheço nenhuma que seja muito fã de práticas ágeis.

7. Divergência conceitual: O modelo de fábrica é completamente contra tudo o que já foi escrito pela literatura acadêmica. Está lá, é só pegar os livros para ler! Waterfall é um engodo, PMBOK não é originalmente direcionado para software (é possível aplicar práticas, mas não ao pé da letra), (R)UP não é out-of-the-box, desenvolvimento de software é altamente dependente de pessoas. Essa divergência e deturpação da ciência é minha maior briga com os gestores covardes, figurinhas carimbadas que geralmente "administram" esses "estabelecimentos".

Minha posição com relação à isso e o modo como aconselho o empresariado é: compre body shop e treine recursos em práticas ágeis. É mais barato e o resultado infinitamente melhor. Atualmente tenho trabalho em alguns projetos onde colocamos o time + gerenciamento dentro do cliente. Depois que o cliente experimenta agilidade e iteratividade ele passa a comprender a furada que é projetos de escopo fechado dentro de fábricas de software.

[erros de português editado]

This message was edited 1 time. Last update was at 06/03/2008 17:42:29

rodrigoallemand wrote:
Engraçado como vc consegue avaliar um projeto (CEF) de 34 milhoes em 5 anos como "sistema de padaria"... Ou um outro (CVRD) de 7 milhões/ano... Acho que são os "padeiros" que transformam certos projetos em "sistema de padaria"... O erro ai é simples... contrata-se padeiro pra fazer pão, nada mais que isso...

Rodrigo, desculpa cara, mas o fato de ter custado 34 milhões não necessariamente diz que foi eficiente e nem que o produto está colocando dinheiro no bolso da CEF. O ponto é que já ví empresários jogando 3, 7 milhões fora em projetos Waterfall que realmente eram software de padaria.

Se você tivesse falado: " - Entregamos 6 meses antes do prazo." ou " - Fizemos a CEF economizar 60 milhões no ano." ou ainda " - Garantimos o ROI em 10 meses..." aí sim seriam parâmetros positivos.

Fico imaginando se com menos dinheiro não seria possível entregar uma solução com uma equipe ágil e iterativa. Não estou desmerecendo o trabalho de vocês, é só uma coisa que passou na minha cabeça, isso porque já ví muitas barbaridades cometidas por fábricas de software.

rodrigoy wrote:
4. Falta de Skill: É um mito comum achar que fábricas de software possuem os melhores analistas, os melhores arquitetos, os melhores programadores. Sim, temos importantes exceções, mas tenho visto que bons analistas, bons arquitetos e bons programadores não acreditam no modelo de fábricas de software em geral.

Aqui você esta sendo arrogante (e nisso você perde a credibilidade). Conheço muitos bons profissionais das fábricas de softwares que trabalham em fábricas de softwares que passei e conheci (não trabalho em uma fábrica de software atualmente). Talvez não sejam a maioria os profissionais que trabalham nesses locais que sejam bons, mas existem sim vários bons profissionais em fábricas.

Microfilo, as fábricas pregam que os desenvolvedores devem ser apenas digitadores especializados em programação, ou seja, eles não deve pensar e sim executar.(copiar e colar código de repositórios/ projetos já prontos ou internet).

Levando isto em conta, os bons desenvolvedores que ainda estão em fábricas entrarão em extinção em pouco tempo.

Vou relatar um ocorrido.

Eu trabalhava prestava serviço numa grande empresa de economia mista, onde para ser admitido precisa fazer concurso. Um belo dia eles acharam que precisava de mais pessoas para desenvolver softwares, então nada melhor que fazer uma licitação para contratar uma "Fábrica de Software". Colocaram vários requisitos, dentre eles claro CMMI nível 4 ou 5 não lembro bem. Lógico que só esse requisito já eliminou trocentas empresas pequenas/médias pq todos sabemos que custa muito caro CMMI.
Então uma empresa muito famosa de todos nós ganhou e claro não tinha analista/programador/etc suficiente para atender a grande demanda e saiu pegando qq pessoa que dizia: "JAVA...ummm eu vi na faculdade. XP..ummm num é aquilo de programar duas pessoas no mesmo computador??" Aí já viu né. Atraso, confusões, reclamações do cliente, atraso, bugs, atraso.

Quantas empresas CMMI - 5 existe no Brasil??
Acho que não mais que 5 né.
Já ouvi falar de pelo menos 2 que tiveram problemas com clientes em Recife nisso de Fábrica de Software.

microfilo wrote: Talvez não sejam a maioria os profissionais que trabalham nesses locais que sejam bons, mas existem sim vários bons profissionais em fábricas.

Microfilo, o que vc escreveu aqui é exatamente o que falei. Talvez seus conhecidos sejam as exceções, eu não os conheço. Fábricas de software é contratação em atacado: "Sabe Java? Sabe Struts? Sabe UML? Tá disposto a fazer hora extra? Tem empresa aberta? Então tá contratado...". Pessoas são recursos em FSW.

Cara, já é a segunda vez que vc me chama de arrogante aqui no fórum. Texto é difícil de expressar. Só estou colocando meu ponto de vista e tentando ensinar algo baseado na minha experiência. Meu, vamo tomá uma cerveja antes de vc me chamar de arrogante de novo. Beleza?

Querem dados concretos?

O não cumprimento de prazos (66%), falhas de comunicação (64%) e mudanças constantes de escopo (62%) lideraram a lista dos principais deficiências apontadas pelo 5º Estudo de Benchmarking em Gerenciamento de Projetos Brasil, realizada anualmente pelo Project Management Institute (PMI), organização internacional responsável pelo desenvolvimento das práticas em gerenciamento de projetos no mundo.

fonte: http://www.tiinside.com.br/Filtro.asp?C=265&ID=86090

microfilo wrote:

rodrigoy wrote:
4. Falta de Skill: É um mito comum achar que fábricas de software possuem os melhores analistas, os melhores arquitetos, os melhores programadores. Sim, temos importantes exceções, mas tenho visto que bons analistas, bons arquitetos e bons programadores não acreditam no modelo de fábricas de software em geral.

Aqui você esta sendo arrogante (e nisso você perde a credibilidade). Conheço muitos bons profissionais das fábricas de softwares que trabalham em fábricas de softwares que passei e conheci (não trabalho em uma fábrica de software atualmente). Talvez não sejam a maioria os profissionais que trabalham nesses locais que sejam bons, mas existem sim vários bons profissionais em fábricas.

Onde ele está sendo arrogante se você acabou de confirmar a frase dele. Caramba, as fábricas tem sim bastante gente muito boa no meio. Mas 50 excelentes profissionais numa fábrica com 10mil macacos não resolve em nada já que o cliente vai ter menos de 5% de chance de ter alguém capacitado se a fábrica colocar 10 pessoas para executar seu projeto.

Sinceramente, fábricas de software preferem gente medíocre a gente capacitada. Produto feito em fábricas é a mesma coisa em qualquer ramo de atividade, por isso não entendo por que raios tem gente que prefere lasanha sadia a ir a um bom restaurante italiano.

Ainda bem que o setor alimentício é muito mais profissional, imaginem se a comida viesse com baratas dentro na mesma proporção que projetos de fábrica fracassam.

se ter profissionalistamo vale! Aqui na empresa funciona muito bem a fábrica e não vi nada de problemas com as nossas empresas de outsourcing ...

This message was edited 1 time. Last update was at 06/03/2008 19:15:47

Eu sou bastante cético em relação a fábricas de software. Já vi algumas operando e afundando completamente projetos banais e outros casos em que as coisas até são entregues de maneira razoável. Concordo com cada ponto que o Yoshi listou anteriormente e acrescentaria mais um: a longo prazo, outsourcing tira de você o poder de inovação. O Michael Bean tem um excelente texto a respeito disso em http://forio.com/resources/the-pitfalls-of-outsourcing-programmers

[editado: url errada]

Até imagino daonde o cv tirou essa de me chamar de Yoshi...

louds wrote:...
Ainda bem que o setor alimentício é muito mais profissional, imaginem se a comida viesse com baratas dentro na mesma proporção que projetos de fábrica fracassam.

Na mesma proporção... não ia ter barata suficiente no mundo!

peerless wrote:se ter profissionalistamo vale! Aqui na empresa funciona muito bem a fábrica e não vi nada de problemas com as nossas empresas de outsourcing ...

Nao viu ou nao procurou? Qual o seu parametro pra dizer que a fabrica 'funciona bem'?

This message was edited 2 times. Last update was at 07/03/2008 03:09:10

Isso vai dar pano pra manga...

stwart wrote:Pergunto os profissionais desenvolvedores. Vale a pena contratar uma fabrica de software?

Não.

rodrigoallemand wrote:
Engraçado como vc consegue avaliar um projeto (CEF) de 34 milhoes em 5 anos como "sistema de padaria"... Ou um outro (CVRD) de 7 milhões/ano... Acho que são os "padeiros" que transformam certos projetos em "sistema de padaria"... O erro ai é simples... contrata-se padeiro pra fazer pão, nada mais que isso...

Eu tenho experiêcia nos contextos que você cita e posso dizer que não, não são é (pelo menos os que trabalhei) de padaria exatamente por isso que diretor é demitido, equipe muda fornecedor muda e o sistema fica três anos sem ir para produção, após cinco anos de desenvolvimento.

Quanto aos problemas do processo de fábrica de sotware você pode começar consultando qualquer documentação sobre processo áeis. Se quiser mais pode procurar sobre como o modelo de fábrica não se aplica à trabalhadores de conhecimento.

rodrigoallemand wrote:
Acho bastante dificil uma metodologia não-waterfall se sair tão melhor do que a waterfall nos piores casos, que são o que todos lembram quando se fala de FSW.

Waterfall não é metodologia, é anti-pattern de projeto (e quem disse isso foi seu autor).

rodrigoallemand wrote:
Aliando-se o desejo do cliente (desejo este que deve estar maduro o suficiente antes do inicio do projeto), uma arquitetura bem montada (seja pela fabrica ou pelo cliente), Profissionais (isso mesmo, com P maiúsculo) e prazo e custos calculados afim de satisfazer a todos, qualquer metodologia dá certo! Seja ela agil, waterfall ou estilo padaria (ataque em 'massa', defesa em 'bolo'). Agora, quando um dos itens desanda (o que é mais certo de acontecer) as metodologias waterfalls falham tanto quanto as outras, mas com outros termos. Quando se tem escopo fechado, o problema é o onus que se cria quando há uma mudança. Já nas ageis, onde o "escopo não é fechado", paga-se do mesmo jeito, mas com um previo acordo de "escopo não fechado".

Desculpe mas você tem alguma estatística ou argumento real para contrariar metodologias iterativas e incrementais? RUP, XP, Scrum, FDD... praticamente tudo que foi escrito sobre esta área nos últimos anos (ou décadas)?

rodrigoallemand wrote:
E eu tb não acredito nas frases do tipo "entregue uma parte funcionando".... não adianta vc ter uma ERP monstruosa, ou um CRM super poderoso se vc não conseguiu fazer, ao tempo da entrega final, um simples controle de acesso, ou um simples CRUD de produtos. Em qualquer metodologia isso se retrata como "software incompleto".

E-mail meu sobre isso de ontem na lista CMM-Brasil":

2008/3/5 Phillip Calçado <pcalcado@gmail.com>:
> Olá,
>
> Eu tenho um ótimo exemplo deste aspecto para ilustrar seu argumento,
> MT, e melhor ainda: um exemplo em que o cliente está tão satisfeito
> que quer evangelizar essas práticas.
>
> http://video.globo.com
>
> Talvez alguém se lembre do Globo Media Center, o produto que foi
> lançado junto com a globo.com. Minha equipe tinha como
> responsabilidade migrar o modelo antigo do Media Center, que não fazia
> sentido na web moderna, para o que é hoje o Globo Vídeos. Eu gerenciei
> o desenvolvimento deste produto e foi quando introduzimos agilidade
> (basicamente Scrum) na empresa.
>
> Migrar um site que bate recorde de audiência todos os anos (com o Big
> Brother Brasil), que tem como público pessoas acostumadas à uma
> linguagem diferente (TV) e ainda deve entrar dentros de critérios
> rígidos da matriz (a Globo.com, como é de se esperar, é parte das
> Organizações Globo e está submissa ao que é conhecido como Padrão
> Globo de Qualidade) não é fácil. Como mudar da noite para o dia o que
> os usuários estão acostumados?
>
> A solução? A cada 15 dias tem algo novo neste site. Bugfixes e
> alterações menores podem ser percebidas no dia-a-dia mas as grandes
> mudanças ficam acessíveis apenas de dentro da intranet. Os produtores
> -os clientes de verdade- acessam o site enquanto ele vai ser
> construído. O público -os usuários de verdade- é apresentado à
> mudanças apenas de maneira big-bang, como quando fomos dormir Globo
> Media Center e acordamos Globo Videos, com outro formato, outro layout
> e funcionalidades completamente diferentes.
>
> A cena é corriqueira: no início do projeto recebemos um zigalhão de
> requisitos que muitas vezes não faziam sentido. Vendo os releases
> quinzenais eles perceberam o que estava errado, o que podia melhorar e
> ainda removeram muitas coisas que perceberam -vendo o produto
> funcionando parcialmente- que não fazia sentido.
>
> A empresa está desde dezembro em processo de adoção do produto em larga escala.
>
> O blog do gerente de webmedia da empresa está aqui:
>
> http://www.acarlos.com.br/blog/category/agile/
>
> O do Guilherme Chapiewski, que era desenvolvedor na minha equipe e me
> substituiu quando vim para a Austrália é esse:
>
> http://gc.blog.br/index.php?tag=scrum
>
> E eu escrevi um pouco sobre a experiência de adoção aqui:
>
> http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/
>
> []s
>
>
> 2008/3/5 mtierno.rm <mtierno@rocketmail.com>:
>
>
> > Djalma
> >
> > Por entrega do tipo big bang eu entendo fazer o delivery em produção
> > de uma vez, certo?
> >
> > Bom, tem muito sistema que só funciona assim mesmo. Não dá (por n
> > motivos) para realizar a implantação em produção por partes.
> >
> > Então, vem a pergunta: que vantagem há em entregas parciais?
> >
> > Vamos lá: as entregas devem ser avaliadas pelo cliente, em ambiente
> > de desenvolvimento ou de homologação.
> >
> > A primeira vantagem é o controle do progresso real do projeto. Há
> > sensação de progresso e isso é muito importante para o time. Evita o
> > que o Brooks chamou de "Analysis Paralysis" (eu acho que foi o
> > Brooks, ok?).
> >
> > A segunda (e, ao meu ver, maior) vantagem é o feedback do cliente,
> > validando o entendimento dos requisitos, melhorando-os e
> > clarificando-os na mente do time de desenvolvimento e do próprio
> > usuário. O escopo dezlizante garante o cumprimento de prazo e custo
> > e força usuários a avaliar se a mudança que pedem é realmente
> > necessária, pois ela "custa" abrir mão de uma funcionalidade
> > previamente solicitada.
> >
> > Terceira vantagem: a sindrome do estudante a seu favor. Com ciclos
> > de desenvolvimento de 15 dias, a equipe vê-se constantemente no
> > deadline. O incremento de produtividade é notável.
> >
> > Há um grande número que eu poderia arrolar aqui. O importante é que
> > as entregas parciais mostram seu valor independentemente se o
> > delivery será "big bang" ou faseado.
> >
> > Como não há almoço grátis, é óbivo que há um preço a ser pago. Há um
> > overhead evidente.
> >
> > No fim das contas, um projeto tocado de forma super-iterativa terá
> > menos funcionalidades entregues do que um tocado de maneira cascata.
> > Aí entram as pesquisas que dizem que até 40% das funcionalidades de
> > um sistema nunca são usadas (pense no Word) e que as aplicaçoes
> > demoram um tempo para "estabilizar" depois de entregues, com numeros
> > pedidos de mudanças e "pequenas (ou grandes) adequações" por parte
> > dos usuários.
> >
> > As entregas parciais, é importante notar, endereçam os
> > aspectos "micro" das funcionalidades. Os aspectos "macro" vêm antes,
> > como estamos acostumados.
> >
> > []s
> >
> > MT.
> >

--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br

rodrigoallemand wrote:
Não estou julgando waterfall x agil. Pelo contrário, sou a favor das ageis! Mas acho que a visão de certas pessoas nesse novo boom das metodologias ageis (novo, pq isso já é bem antiguinho) é meio falho!

Por quê?

Você acaba de dizer que metodologias que seguem waterfall falham nos mesmos cenários que metodologias iterativas incrementais mas não deu um motivo. Sem motivo a única forma de argumentar que voê está errado é com toda a documentação escrita sobre modelos iterativos nas ultimas décadas, ou até mesmo o paper que define waterfall que o menciona como uma anti-prática. Eu queria que você explicasse melhor seu ponto porque ele não faz muito sentido para mim.

rodrigoy wrote:
Minha posição com relação à isso e o modo como aconselho o empresariado é: compre body shop e treine recursos em práticas ágeis. É mais barato e o resultado infinitamente melhor. Atualmente tenho trabalho em alguns projetos onde colocamos o time + gerenciamento dentro do cliente. Depois que o cliente experimenta agilidade e iteratividade ele passa a comprender a furada que é projetos de escopo fechado dentro de fábricas de software.

Eu acho isso uma péssima alternativa. Se voc6e compra o serviço compra de especialista,s se os especialistas não são assim tã especialistas eu prefiro contratar uma consultoria menor (e melhor).

Engraçado a minha situacão atual. Eu acabo de sair de um papel onde boa aprte das minhas tarefas era gerenciar contratos e prestação de serviços com empresas CMMI nivel 5. Solução? Chutamos o fornecedor, após dois anos de enrolação e treinamos nosso pessoal, substituindo e adicionando pessoas. Na minha empresa atual eu estou do outro lado da linha, sou consultor novamente, e graças à Zahl trabalho num lugar onde eu posso -como já fiz algumas vezes- dizer para o ciente claramente que ele está perdendo dinheiro tentando treinar consultores. Quando você contrata uma fábrica ou um consultor você contrata o serviço, não a pessoa. Se o serviço não presta você troca de fornecedor.

cv wrote:

peerless wrote:se ter profissionalistamo vale! Aqui na empresa funciona muito bem a fábrica e não vi nada de problemas com as nossas empresas de outsourcing ...

Nao viu ou nao procurou? Qual o seu parametro pra dizer que a fabrica 'funciona bem'?

Os projetos são atendidos DENTRO do prazo, ja é o suficiente para considerarmos que "valeu a pena", não concorda?

ps.: o "cliente" do projeto em que atuo é o setor de Qualidade de Software da fábrica.. por isso posso afirmar

Notícias, artigos e o maior fórum brasileiro sobre Java