Sou só eu que tem arrepios quando ouve este termo, ou vocês botam fé que este conceito é o futuro quando se trata de desenvolvimento de software?
Fábrica de Sofware
S
119 Respostas
R
Porque Futuro ?
Todas as grandes consultorias estão trabalhando dessa forma, com profissionais alocados, fábricas e até fábricas alocadas (em empresas de telecom isso é muiot comum).
Pelo que entendo é assim que se trabalha hoje.
[]´s
S
Me expressei mal. Por futuro eu não me referia a adoção, mas sim ao fato das fábricas de software se tornarem padrão de mercado.
S
Porque Futuro ?Todas as grandes consultorias estão trabalhando dessa forma, com profissionais alocados, fábricas e até fábricas alocadas (em empresas de telecom isso é muiot comum).
Pelo que entendo é assim que se trabalha hoje.
[]´s
E na sua opinião, isso é bom?
F
Você poderia citar um outro conceito de desenvolvimento de software que não seja atraves de uma Fabrica de Software?
S
Você poderia citar um outro conceito de desenvolvimento de software que não seja atraves de uma Fabrica de Software?
Que tal abordagens ágeis? (XP, FDD etc)
F
Olá
Você poderia citar um outro conceito de desenvolvimento de software que não seja atraves de uma Fabrica de Software?
Que tal abordagens ágeis? (XP, FDD etc)
desculpa mas eu não compreendi bem… O fato de usar uma abordagem agil exclui a fabrica de SW?Ou seja é uma coisa ou outra?
Eu sempre pensei que uma fabrica de SW poderia muito bem usar XP, FDD ou as 2 juntos ( que até onde eu entendo são metodologias assim como o RUP).
L
Olá
Eu também. Deve ter alguma que use mas eu não conheço nenhuma. Pelo contrário, conheço algumas que se esforçam para conseguir CMM e são extremamente burocratizadas.
[]s
Luca
U
IMNSHO, uma abrica de software como o proprio nome ja diz, é um conceito absurdo!
por que?
o que é uma fabrica?
se ajusta a fabrica para uma especificação
depois se adiciona materia prima
e do outro lado saem um monte de coisas exatamente iguais
a coisa mais parecida em software com uma fabrica é uma prensa de CDs/DVDs onde se desenvolve o software/especificação
e depois se prensa um monte de CDs iguais
eles querem que em uma fabrica de software fabrique as espeficicações, mas não é isto que uma fabrica faz, isto é o que o setor criativo da empresa faz …
por tanto, é impossivel existir uma fabrica de software …
por isto, todos os que ja trabalharam em uma tem pavor do termo fabrica de software, e todos os clientes que ja compraram de uma fabrica de software estão penando e pagando manutenção até hoje para que algum dia o software faça o que eles querem …
por que existem as tais?
bom, é um ótimo negócio para consultorias que não se importam com o produto final, e se elas seguirem direitinho a definição de o que o cliente foi convencido que queria, então irão conseguir depois convencer o cliente que é culpa dele que o negocio não funciona/não faz o que o cliente precisa …
mas isto pode também ser só motivado por algumas péssimas experiências, pode ser que alguem tenha feito estes dois conceitos completamente diferentes funcionarem juntos 
IMNSHO => In my not so humble opinion
R
Quanto ao XP + Fábrica já participei de algo assim, de certa forma.
Trabalhei com uma equipe pequena no desenvolvimento de dois sitemas para uma telecom, baseado em um framework proprietário.
A metodologia que foi utilizada foi o scrum.
Só que após os sistemas ficarem prontos, foi criada uma fábrica para dar manutenção, etc… aí (creio eu) para manter o querido CMMI 5, foram introduzidos novos processos.
O que posso dizer é que já ví, vivi e ouvi falar de muitas fábricas de software, mas sem nenhuma queixa quanto a qualidade… acho que isso não astá atrelado ao conceito e sim á empresa.
[]´s
R
Porque Futuro ?Todas as grandes consultorias estão trabalhando dessa forma, com profissionais alocados, fábricas e até fábricas alocadas (em empresas de telecom isso é muiot comum).
Pelo que entendo é assim que se trabalha hoje.
[]´s
E na sua opinião, isso é bom?
E respondendo:
Pelo menos as experiências que tive, no geral foram boas.
[]´s
L
Minhas experiências foram péssimas!
O pessoal confundia fábrica de software com pastelaria! Uma tristeza…
Achavam que programar era como fritar pastel(sempre o mesmo processo), e que era só pedir e rapidinho estava pronto! :x
O grande problema das fábricas de software hoje, na minha opinião, é que elas viraram quintal dos “países desenvolvidos”. Por a mão de obra aqui(e na India) ser mais barata, eles mandam as especificações pra cá, e exigem de volta um software de qualidade! Ateh ai, poderia funcionar se:
-as especificações enviadas não fossem uma porcaria
-o tempo não fosse pouco pra executar as tarefas
-o salário pago aqui não fosse tão baixo
-a qualificação dos profissionais não fossem uma porcaria(normalmente as equipes tem 3,4 caras bons e 20 caras ruins digitadores)
-o processo não fosse tão burrocratizado
A
Quanto ao XP + Fábrica já participei de algo assim, de certa forma.Trabalhei com uma equipe pequena no desenvolvimento de dois sitemas para uma telecom, baseado em um framework proprietário.
A metodologia que foi utilizada foi o scrum.
Só que após os sistemas ficarem prontos, foi criada uma fábrica para dar manutenção, etc… aí (creio eu) para manter o querido CMMI 5, foram introduzidos novos processos.
O que posso dizer é que já ví, vivi e ouvi falar de muitas fábricas de software, mas sem nenhuma queixa quanto a qualidade… acho que isso não astá atrelado ao conceito e sim á empresa.
[]´s
Conseguiram medir a qualidade? Quão bom foi o projeto? Tem números?
Lembre-se que no nível 5 vc já definiu, implementou e institucionalizou métricas… :twisted:
S
Olá
Que tal abordagens ágeis? (XP, FDD etc)
desculpa mas eu não compreendi bem… O fato de usar uma abordagem agil exclui a fabrica de SW?Ou seja é uma coisa ou outra?
Eu sempre pensei que uma fabrica de SW poderia muito bem usar XP, FDD ou as 2 juntos ( que até onde eu entendo são metodologias assim como o RUP).
Daí depende do seu conceito de fábrica de software. Se considerarmos apenas o produto final (software), qualquer empresa que desenvolve pode ser chamada de fábrica de software.
Agora, se levarmos em consideração a maneira de se fazer as coisas, o que eu compreendo por fábrica de software é na grande maioria dos casos desenvolvimento em cascata acompanhado de modelos de qualidade. Ambos são necessários para se criar um conceito de “linha de produção” que ao meu ver não tem a ver com software.
Ou seja, ao meu ver fábrica de software e desenvolvimento ágil podem até não serem conceitos mutuamente exclusivos, mas são bastante diferentes.
S
Quanto ao XP + Fábrica já participei de algo assim, de certa forma.Trabalhei com uma equipe pequena no desenvolvimento de dois sitemas para uma telecom, baseado em um framework proprietário.
A metodologia que foi utilizada foi o scrum.
E como funcionava esta Fábrica de Software Ágil?
R
Perceba,
A consultoria que eu trabalhava tinha a certificação de qualidade CMMI 5, não especificamente a fábrica que trabalhei.
Quando disse que novos processos foram encorporados à fabrica, não foi porque aquela fábrica em sí estaria se adaptando para aquela certificação, até porque era uma fábrica alocada, mas sim porque existem processos que realmente precisam ser padronizados.
Quanto ao bom funcionamento da fábrica com scrum, creio que o ponto mais marcante eram as reuniões matinais para da um feedback a todos sobre as atividades de cada um no sistema. Existiam os testes unitários, etc…
Note que o scrum foi utilizado no desenvolvimento dos sitemas, após virar um fábrica, perderam-se algumas características, mas muitas permaneceram. Digamos que houve uma adaptação.
Quanto a números fica um pouco complicado de expor, que tipo de informação gostaria de saber ?
[]´s
L
por isto, todos os que ja trabalharam em uma tem pavor do termo fabrica de softwareFalou tudo!
L
Futuro? Diria passado… As formas de trabalho de software são cíclicas. Tivemos o terminal burro, depois o client-server e agora o que temos com a web? Um tapa no terminal burro.
Antes tinham as chamadas softwarehouse, que desenvolviam projetos sob encomenda dos clientes. e o que temos agora? Depois voltamos para a alocação direto no cliente, o desenvolvimento interno de produtos, onde os profissionais eram alocados para projetos de 6 meses (geralmente era mais, já fiquei 2 anos num cliente). A fábricas de software que fazem softwares ou serviços sobre encomenda. Já viram isso?
A verdade é que o mundo de TI ainda não achou a melhor forma de se desenvolver software. Talvez nem exista, mas a verdade, é que vão tentando. E se as fábricas não morrerem num futuro próximo e a maioria voltar a trabalhar diretamente para o cliente (como empregado mesmo), eu corto minhas partes íntimas fora (para não ser chulo). Offshore está ficando caro, e os diretores das empresas, mais uma vez, vão ganhar fortunas inventando um jeito novo de software. Quem viver, verá.
Mas nada muito novo, porque no mundo tudo se copia.
[]'s
C
Em meados de 2004 estava lendo a Veja, uma das colunas do Cláudio Moura e Castro onde ele dizia de profissionais especialistas!
Que de nada adianta saber um pouquinho de tudo, e sim, tudo de um pouquinho… isso se chama foco no negócio!
As fábricas, softhouses e afins como disse o Ludhi, tem tudo para virarem fumaça logo, logo!
Tá na hora dessas empresas focarem mais em um negócio específico e desenvolverem ao máximo!!! Nisso ganharão qualidade.
Então, resumindo é ter FOCO!!!
L
Em meados de 2004 estava lendo a Veja, uma das colunas do Cláudio Moura e Castro onde ele dizia de profissionais especialistas!
Que de nada adianta saber um pouquinho de tudo, e sim, tudo de um pouquinho… isso se chama foco no negócio!
As fábricas, softhouses e afins como disse o Ludhi, tem tudo para virarem fumaça logo, logo!
Tá na hora dessas empresas focarem mais em um negócio específico e desenvolverem ao máximo!!! Nisso ganharão qualidade.Então, resumindo é ter FOCO!!!
Alguém duvida disso?
E digo mais, daqui a pouco aparece uma outra onda, Ruby ou outra… Aí toda a molecada vai programar nisso, e vai faltar gente em java (sempre faltou, aliás). Aí os salários dão um boom. Já tomei a decisão na vida de não largar mais a área técnica. Por ver o que acontece com os cobolzeiros.
[complementando]
Ser especialista dá trabalho, mas essa semana fiquei sabendo de um cara que conhece uma tecnologia especifica de netweaver que está ganhando…
bem… 50k por mês PJ!!! Assim eu trabalho com PJ!!!
[/complementando]
R
Voces estão generalizando muito a coisa.
Fábrica != Software em caixinha.
Sinceramente não acedito que fabricas vão acabar, pois muitas delas existem especificamente para atender um nicho de clientes, para suprir suas necessidades e oferecer novos protutos interessantes a eles.
Existem sim “fábricas genéricas”, mas pelo menos eu, nunca participei de nenhuma.
Ao criar uma fábrica para atender um cliente, a empresa está, justamente, focando.
[]´s
S
Voces estão generalizando muito a coisa.Fábrica != Software em caixinha.
Sinceramente não acedito que fabricas vão acabar, pois muitas delas existem especificamente para atender um nicho de clientes, para suprir suas necessidades e oferecer novos protutos interessantes a eles.
Existem sim “fábricas genéricas”, mas pelo menos eu, nunca participei de nenhuma.
Ao criar uma fábrica para atender um cliente, a empresa está, justamente, focando.
[]´s
Não vi ninguém dizer que Fábrica de Software == Software de Caixinha (a fábrica é o meio, não o fim).
Gostaria de entender o que significa “criar uma fábrica” pra você.
P
Fábrica de Software é antagônico à desevolvimento ágil em sua essência. Fábricas deste tipo por definição trablham com entradas e saídas, entradas na forma de requisitos colhidos por um analista para a fabrica de projetos, projetos como entrada para a fabrica de codigos e por aí vai.
Dado o crescente interesse de IBM, MSFT e outras consultorias mainstream (as brasileiras de trs letrinhas só sabem seguir o que as estrangeiras de três letrinhas fazem, e mesmo assim alguns anos depois) pelo modelo ágil acho que a resposta quanto ao futuro é bem clara.
T
MSFT tem 4 letrinhas 
Interessante a idéia de Fábrica de Software. Mal posso imaginar o pessoal de controle de qualidade olhando para as classes da tua aplicação que rolam por uma esteira e recolhendo as classes defeituosas. Logo a frente uma máquina empacota as classes e carimbam-nas com data de validade. :roll:
<desabafo>Por que será que administradores frustrados vêm reinventar justamente em TI práticas fracassadas em outras indústrias?</desabafo>
P
Eu não falei que tinha 3 letras, falei que as empresas seguem gringas de 3 letras 
De qualquer form, ter 3 letras é mais filosofia do que sigla mas não, a MSFT não faz parte deste time. Seus problemas são outros.
L
Quando eu tava na faculdade e ouvia meu professor falando sobre fábricas de software (software de caixinha), repositório de códigos, componentização e mais um monte de coisas que inventam pra vender livros, eu pensava: “Nossa, deve ser maior blz trabalhar numa fabrica, tudo bonitinho, certinho”.
Quando fui trabalhar na minha primeira fabrica, eu pensei: “professor fdp, só falava merda e ainda peguei uma DP dele rsrs”.
A
http://www.guj.com.br/posts/list/11359.java
:)
Eh, em 2004 já falavam nisso…
Errar é humano, persistir no erro é burrice. :roll:
B
Não é “persistir no erro”. É que a evolução demora a chegar aqui no terceiro mundo, mesmo.
Veja só: um entrevistador - e também sócio - me disse, como resposta ao meu questionamento sobre o motivo de não utilizarem metodologias ágeis na empresa em questão: “é que pra usar metodologias como XP tu precisa de uma equipe boa”. :shock:
Tremendo incentivo pra trabalhar lá, né?! :?
T
Eu não falei que tinha 3 letras, falei que as empresas seguem gringas de 3 letras
De qualquer form, ter 3 letras é mais filosofia do que sigla mas não, a MSFT não faz parte deste time. Seus problemas são outros.
Já havia entendido, estava apenas brincando.
S
Ler este tópico me fez ver e confirmar suspeitas, baseadas em minhas experiências, com relação a uma fabrica de software. E como o CV disse, “Fabrica de Software” nada mais é do que um produto de Marketing. Na minha opinião não passa do sonho de todo dono de empresa de TI, não se pode prever tudo que irá acontecer no desenvolvimento de um software e é quase impossível saber quando o mesmo estará pronto, como ocorre em uma fabrica. O problema é que as pessoas que estão nestas “fabricas de software” tem plena certeza de que isso é possível enquanto se baseiam em métricas loucas e metodologias (CMMI) que não conseguem nem metade dos resultados para qual foram propostas. Não sei qual é o futuro do desenvolvimento de software… mas seguindo essa ideia, de que desenvolver é um processo exato, talvez seja possível “programar” o proprio desenvolvimento ao ponto de programadores não serem mais necessários
L
Cara, desculpa mas sou obrigado a discordar da sua opinião. Mas antes de mais nada, tbm sou contra fábricas de software…
É claro que é possível se obter métricas aproximadas de quanto tempo vai levar o projeto. Senão tbm vira um circo neh, imagina vc chegar pro seu cliente e falar “ó…não sei quando vou terminar, quando acabar eu te entrego o software”…acho q seria inviável isso…
O grande problema das fábricas de software é que elas mesmo ignoram as métricas que elas fazem e falam pro cliente que vão fazer em um tempo muito menor pra conseguir vender o projeto…se eles fazem a métrica e dá que vai levar 1 ano, eles falam pro cliente que leva 6 meses…
Mas uma métrica e um planejamento bem feito e bem seguido é muito eficiente! Mesmo pq leva em conta riscos como funcionário sair, ficar doente, o projeto dar uma travada e etc…
e o CMMi não diz que desenvolver é um processo exato. Ele só intrefere no controle do projeto. Não que eu goste do CMMi, muito pelo contrário. Mas uma coisa é certa, empresa nenhuma usa ele adequadamente, a que eu trabalhava pagou pra tirar…
K
Essa é uma realidade, já participei de alguns processos, em alguns casos esses foram abandonados, pelo time-to-marketing. Uma vez concluído, raramente são seguidos.
Também tive uma experiência positiva com o Scrum, projeto que eu participei fora conduzido sob tal regime e acho realmente que tem muito mais haver com nossas necessidades, cultura e ter previsibilidade sob o Caos , como o Scrum prega , é praticamente impossível.
Agora, pior que o termo Fábrica de Software, somente BODYSHOP … affff açougue puro …
C
Sim, existem metricas, mas esse “nao sei quando vou terminar, quando acabar te entrego o software” nao eh exatamente o que as metodologias ageis promovem, com o porem muito importante que as “entregas” sao semanais ou quinzenais?
L
Sim, existem metricas, mas esse “nao sei quando vou terminar, quando acabar te entrego o software” nao eh exatamente o que as metodologias ageis promovem, com o porem muito importante que as “entregas” sao semanais ou quinzenais?
ah sim, mas esse porem é muito importante mesmo! :lol: As entregas são feitas semanalmente ou quinzenalmente…ai é ótimo!!!
Quando expressei minha opinião, estava me referindo ao modelo tradicional de desenvolvimento de software, onde se entrega tudo de uma vez só para o cliente no final. Daí eu acho inviável vc não dar um prazo pro cliente…
com metodologias ageis, o cliente acompanha o andamento do desenvolvimento, ai não vejo muito problema!
L
olha eu ressucitando o tópico rs
1 ano depois do falecimento dos posts nesse tópico, queria saber a opinião hoje de vcs sobre como anda o mercado de desenvolvimento?
Estou meio assutado ainda vendo empresas que estão se moldando agora, novas, procurando uma maneira de trabalho de “Fabrica de Software”, vejo amigos comentando que suas empresas querer ter 90% do corpo de JR e estagiários, que iniciam projetos HOJE com Struts 1, porque o mercado conhece e como a rotatividade é alta qualquer um pode chegar e mandar bala.
Isso tem fundo de verdade? tem, mas essas empresas não querem pessoas, querem números, afinal onde se é um pessoa que faz parte de um time, eu acredito que a rotatividade não seja grande, onde se é apenas mais um “recurso”, tanto faz quem é vc e se vc quer ficar ou não.
Eu estou meio por fora de como as coisas estão rumando no mercado e o modelo de fábrica (consultorias de 3 letrinhas by Shoes) realmente esta forte e crescendo ou realmente tem algo errado com essas empresas?
[]'s
L
…Eu estou meio por fora de como as coisas estão rumando no mercado e o modelo de fábrica (consultorias de 3 letrinhas by Shoes) realmente esta forte e crescendo ou realmente tem algo errado com essas empresas?
[]'s
Eu vejo que a tendência é só aumentar a adoção desse tipo de modelo. E digo mais, como a mão de obra é beeeeeem mais barata em outros estados, todo trabalho de “desenvolvimento” sairá dos grandes centros. Falo isso porque isso é que acontece na atual empresa que trabalho. Grande parte dos projetos que começaram a ser desenvolvidos aqui em São Paulo, foram todos pra Bahia, e qual a justificativa? Custo com a mão de obra. Enquanto um sênior aqui em São Paulo rala pra ganhar seus R$6.000,00, R$7.000,00, lá na Bahia eles encontrar gente que se sujeita a ganhar de 1/3 e metade do que se ganha aqui em São Paulo.
A
bom, aqui eu trabalho numa fábrica de software, quando se referem a gente se referem aos meninos da fábrica… rs agora, o esquema que a gente trabalha aqui não tem quase nada a ver com uma linha de montagem onde teria a entrada - especificações - e depois a saída - software…
D
Eu acho que é util eu dar um testemunho sobre a minha experiência como cliente de uma fabrica de software:
HSBC como cliente da fábrica:
Trabalhei alguns anos com sistemas de RH do HSBC, depois de uns 2 anos que eu estava na empresa, recebemos a triste noticia que o banco tinha tomado a decisão de impedir que todo o analista de sistemas do banco desenvolve-se ou desse manutenção em sistemas, teriamos o perfil de gerentes de projeto. Foi implantada uma metodologia monstruosa para construir foguetes e tivemos que engolir toda aquela baboseira. Todos os nossos sistemas seriam desenvolvidos nas fabricas de software das consultorias 3 letrinhas.
Foi o primeiro ano a metodologia não era nada agradavel, nada aplicavel a projetos médios e pequenos por causa das fases dessa metodologia nós trabalhamos com sobreposição de fases, nosso clientes as areas business ficavam responsaveis por solicitar em Use Case depois suplementado pela consultoria e aprovado por nós do TI eram de péssima qualidade pra não dizer terrivelmente ruim!, pequenas alterações que faziamos em uma semana isso com uma boa documentação e teste passaram a ter quase dois meses, pois o tempo de build da fábrica e absurdamente ridiculo!
Eu lembro muito bem dos valores um sistema de interface entre aplicativo estava orçado em 85 mil reais, sem brincadeira aquela interface entre eu montaria em um mês tranquilamente(Lá eu montei duzias), manutenções e módulos que para nossa equipe eram faceis custavam bagatelas de 50 mil reais(uma semana duas semanas de desenvolvimento pela nossa equipe) e tivemos projetos de 500 mil, 300 mil e por ai vai.
Os programas desenvolvidos pela fábrica levavam o dobro ou triplo do tempo e quando chegavam se já sabe, eram de uma qualidade péssima, parece que o pessoal analista de sistemas da consultoria não tinha feito nada! Os programas com problema de testes de tela foco, validação e na maioria das vezes totalmente fora da necessidade do usuário.
Depois de muito stress em dois anos a fabrica foi sendo deixada de lado e começou a voltar o desenvolvimento um bom para nossa equipe. Hoje a fabrica é utilizada com muita moderação e não vem sendo util até no nesse ano quando falei com um ex-colega.
B
Quote de um ano atrás, mas vamos lá:
As práticas de outras indústrias não são fracassadas. Elas simplesmente funcionam lá, e talvez em alguma outra indústria de outro ramo.
Mas em TI não funcionam.
Desenvolver um software:
-não é como construir um prédio
-não é como montar um carro numa linha de montagem
-não é equivalente a processo algum do mundo físico
Parafraseando Fred Brooks
Isso quer dizer que você pode até colocar o dobro de peões para cavar um buraco na metade do tempo, mas não adianta alocar o dobro de programadores em um projeto para tê-lo feito na metade do tempo. Dependendo da hora, vai até atrasar mais o projeto.
Eis a simples diferença entre um trabalho físico, perfeitamente particionável, de um totalmente interligado, um trabalho intelectual.
Eis por quê práticas e gerenciamento provenientes de outras indústrias não funcionam.
K
disse tudo…
não consigo visualizar uma fábrica de software utilizando uma metodologia ágil…seja lah qual for…
já trabalhei em 2 fábricas de software, e nelas eu apreendi de tudo…tudo o que NÃO
deve ser feito no desenvolvimento de software. Na minha opnião, desenvolvimento de software é um processo criativo e que valoriza principalmente as pessoas… e uma fábrica de software é o contrário disso. Uma fabrica vende horas … como se fosse um “commodity”.
nas fábricas onde trabalhei, o trabalho poderia ser feito na metade do tempo, com a metade
de pessoas… mas isso numa fábrica não tem a menor importância, o importante é faturar !!! :shock:
Sinceramente, acho que as empresas (onde se incluem também as consultorias de 3 letrinhas) que só visam o curto prazo e lucro imediato, estão fardadas a desaparecer.
D
Fala Kruger!
Vc ainda ta na Fabrica da Dts?
Concordo plenamente as empresas que começaram com essa história de utilizar fábrica de software há algum tempo, parece que estão acordando e vem pressionando as 3 letrinhas.
T
Eu trabalho em um projeto d downsizing aonde tem N consultorias que trabalham nesse esqueminha tosco de fábrica… O s subprojetos em que trabalho simplesmente não terminam huahuaha
Trocentos estagiários e jr para fazer um subsistema minúsculo que poderia ser feito por um único cara razoavelmente experiente… Ae vc inclui que boa parte dos analistas (salvo raras excessões) que não tem nem idéia do que estão fazendo… Já viu né… Depois tenho que ficar consertando (REFAZENDO) a merda malfeita… fazer o q…
Ah e sem falar que toda vez q meu gerente fala: “dá pra vc resolver aquele probleminha lá?” pode crer que o dia que eu ia perder fazendo isso já virou 3 meses…
L
não entra na minha cabeça porque as empresas se submetem a isso ainda… será que os “clientes” são tão burros assim? décadas de projetos errados e prejuízos financeiros não ensinou nada à ninguém?
D
O problema que os empresários não sabem que a fabrica de software é jogar dinheiro pela janela.
Economizar no profissional é aumentar seu prejuízo.
A
Pessoal, vou meter o bedelho na discussão também introduzindo uma pergunta: vocês afinal acham então que o conceito de fabrica de software é algo não-aplicável no desenvolvimento de um software?
Eu nunca trabalhei em uma fabrica de SW ou d qq outra coisa mas minha opinião é a seguinte:
Cada vez mais eu acho que um software deve ser desenvolvido por pequenas equipes de no maximo 7 pessoas. Acho que equipes de 5 pessoas sao ideais. Mas dependendo do tamanho sistema, se for mto grande, axo que dividir em partes e formar pequenas equipes pra cada módulo é uma boa prática… é claro utilizando como argamassa uma arquitetura bem definida para colar todos as partes no final! É possivel? Ou apenas utopia? Se eu fosse gerente de um grande projeto axo q eu tentaria esse tipo de abordagem!!! oq vcs acham?
S
Pessoal, vou meter o bedelho na discussão também introduzindo uma pergunta: vocês afinal acham então que o conceito de fabrica de software é algo não-aplicável no desenvolvimento de um software?Eu nunca trabalhei em uma fabrica de SW ou d qq outra coisa mas minha opinião é a seguinte:
Cada vez mais eu acho que um software deve ser desenvolvido por pequenas equipes de no maximo 7 pessoas. Acho que equipes de 5 pessoas sao ideais. Mas dependendo do tamanho sistema, se for mto grande, axo que dividir em partes e formar pequenas equipes pra cada módulo é uma boa prática… é claro utilizando como argamassa uma arquitetura bem definida para colar todos as partes no final! É possivel? Ou apenas utopia? Se eu fosse gerente de um grande projeto axo q eu tentaria esse tipo de abordagem!!! oq vcs acham?
O que você pensa não está errado, o problema, como foi falado é que os manda-chuva não pensam.
Eles acham que aumentar o tamanho da equipe faz as cosias andar mais depressa: mentira. Faz andar mais devagar.
Mais pessoas significa mais comunicação, mais controle. Isso significa menos tempo codificando. Aqui entre o Pair Programming onde a rotatividade dos pares aumenta a comunicação e o controle sem sacrificar o tempo de codificação.
Quem paga não entende o que compra. Isso faz com que se pense que terceirizar e pagar N dezenas milhares é melhor que ter uma equipa interna pagando N milhares. Mas isso acontece porque eles não estão comprando o software. Eles estão comprando a responsabilidade. Se o software der problema eles executam a empresa que o fez.
Um lugar onde de faz algo é uma fábrica. O termo Fábrica de Software não deve ser prejurativo, porque as pessoas não sabem outro nome da "empresa que produz software"
Acontece que o erro é esse: o que a empresa produz não é o software. produzir software não significa criar um bem, significa criar um serviço. Criar um software é como treinar pessoas, ninguém fala em “fabrica de pessoas treinadas”.
É o foco que está errado. E com ele toda a nomenclatura e confusão que se cria dai.
Mas, sim, criar um software passa por criar uma “coisa”, mas essa “coisa” é apenas uma ferramenta. Imagine-se no circo. No Canhão Humano as pessoas pagam pelo quê ? por ver um canhão disparar ? Não, por assistir a coragem do cara lá dentro.
Ninguém paga para ver a qualidade das cartas do ilusionista, paga para ser maravilhado pelo que ele faz com elas.
E quem cria esses engenhos ? Alguem cria, tem uma engenharia , um saber, uma tecnologia associada. Existem fábricas onde se fabricam essas coisas.
Construção de software é mais ou menos como isso. Alguem cria o software, mas não é isso que se está vendendo. Ou pelo menos não deveria ser. Quando se fala de equipe, scrum, XP, java, .net , etc… estamos no nivel do cara que fabrica as cartas que os ilusionistas usam. Software é muitos mais que isso.
C
Eu ainda nao estou convencido de que TODO desenvolvimento de sw se encaixa nesse modelo software-como-servico. É verdade que o ideal de projeto da maioria das fabricas de sw que conhecemos e daquelas que nao tivemos oportunidade de conhecer pq nao sobreviveram é equivocado. E superficialmente falando, baseado nas ofertas de emprego publicas em listas de java nao creio que a situacao esteja mudando.
Nesse sentido de construcao de produtos de software um grande exemplo de fabrica de sw é a fundacao apache.
A
não entra na minha cabeça porque as empresas se submetem a isso ainda… será que os “clientes” são tão burros assim? décadas de projetos errados e prejuízos financeiros não ensinou nada à ninguém?
Luiz, enquanto no Brasil for comum as pessoas levarem um por fora esse tipo de prática vai ser comum, se é que você me entende, acontece a mesma coisa na política, na administração pública, etc…
S
Nesse sentido de construcao de produtos de software um grande exemplo de fabrica de sw é a fundacao apache.
ótimo exemplo. A fundação apache ( ou a fundação eclipse já agora) é uma fabrica de software ? Eu diria que sim. Mas gostaria de saber o que acha quem diz que “fabrica de software” non ecsisté ou não deveria existir…
B
A Apache é uma comunidade de desenvolvedores que produzem software de forma colaborativa nos termos da Apache License.
Os projetos dela não nascem pela demanda de um cliente, e sim de uma necessidade coletiva do mundo.
L
Mais lenha na fogueira!
Às vezes, tenho a impressão de que o pessoal culpa as consutorias de três letrinhas ao mesmo tempo em que coloca o cliente como vítima. Será que é isso mesmo? Eu vejo podridão nos dois lados. Tanto o cliente quanto a consultoria são culpados nessa história.
Exemplo: normalmente, o cliente, de cara, não tem uma TI organizada, que é vista mais como um sangue-suga de dinheiro, reativa, e que não busca inovações. Com isso, o cliente, pra resolver seu problema, ao invés de arrumar a casa, vai lá e terceiriza pra uma consultoria. E com isso, a TI do cliente, ainda sem foco e sem gente qualificada que entenda de software, vai simplesmente pedir pra qualquer consultoria que um projetão deve ser feito em X meses e deve ser o mais barato possível.
E aí? A consultoria atrasou a entrega? Sem problemas! Pega o dinheiro da multa contratual e paga uma outra consultoria barateira que faça o serviço. A consultoria não entregou com qualidade? Mas quem se importa? Não é a consultoria que vai perder com isso, muito menos a TI do cliente, que sempre vai colocar a culpa nas terceirizadas. A TI não compra softwares de terceiros, compra bodes expiatórios.
Mas não sou louco, a fábrica de software é um erro! Mas qual é a responsabilidade de quem os contrata? Será que os clientes são tão vítimas assim?
B
Acho que são sim. Eles simplesmente não sabem a diferença. Pergunta para eles o que o cara de TI faz.
No caso de empresas estatais, mesmo que tenham um setor de TI p/ atende-las, elas não contratam consultorias diretamente, são as consultorias que ganham licitações, isto é, leva quem oferecer o menor preço(dizem…). E tem o menor preço que oferece os serviços de pior qualidade.
M
"
A
Manter uma equipe desenvolvendo em waterfall (mas falando que é rup) tem grandes chances de sair mais caro.
Mas enfim, quais são os aumentos de custos que há no caso de manter uma equipe trabalhando com metodologias agéis? Nem licença de MSProject vc precisa.
M
"
A
Discordo. Quando a Toyota, por exemplo, adotou um modelo ágil ela não desviou o foco da sua atividade fim. Uma coisa não exclui a outra, e nem deve!
K
Reduzir custos de quem ?! Do cliente ?! Da fábrica ?!
Tudo o que eu já vi em fábricas de SW é custo pra ambos os lados…
E numa fábrica de SW voce não teria esses mesmos custos ?
Mesmo com as melhores das intenções e com um “processo bem conduzido”,
a maioria das fábricas de SW precisam de tanta papelada e CMMs da vida,
que esquecem do fundamental, software funcionando com qualidade.
M
"
L
Olá
Adoro miguxês, acho tão meigo… :lol:
[]s
Luca
P
Em uma fábrica os custos são diluídos já que já existe toda uma estrutura e metodologia montada pra desenvolvimento de software e a carga tributária é baseada no ramo de negócios.
A pergunta persiste: custo de quem? Eu respondo: do fornecedor (da fábrica). O custo do cliente aumenta, e muito, com software de qualidade ridiculamente baixa, que precisa de manutenção frequente, não atende aos objetivos originais, foi entregue com atraso e estourou o orçamento.
Ok, fabricas de software podem não ter estes problemas se fizerem as coisas certas. Quais são as coisas certas?
Eu nem tenho certeza se ainda podem e nem se em todo o país, mas ainda que sim isso tem mais a ver com um governo que tenta imitar a Índia do que com eficiência ou benefício ao cliente. Novamente o benefício é para a fábrica e não para o pobre coitado que compra software dela.
Tendo trabalhado em diversos destes ambientes eu só vi redução de custo do fornecedor. O cliente, tendo comprado um péssimo software, so gasta mais dinheiro.
Mas como eu disse, cada caso é um caso. Como todo mercado em fase de mudança, no começo aparecem muitos amadores que queimam o filme da área, mas a medida que a coisa vai se profissionalizando, o cenário muda e fica mais claro, até vir outra onda de mudança.
Desculpe mas eu trabalhei em/trabalhei para/comprei de empresas que não são amadoras -com todos os seus selinhos de CMMI 5>- e nenhuma delas apresenta resultado satisfatório. Volto eu com a pergunta: o que é que precisa ser feito (e nenhuma destas empresas faz)?
L
quem é o emo ai?
L
Não entendi essas colocações.
1 - Encargos trabalhistas:Vc tem tb isso com Fábricas de Software com processos em cascata.
2 - Montar uma equipe ágil, treinada e com uma metodologia boa para desenvolver, testar e controlar o software toma tempo e dinheiro.- Vc tb tem isso com Fábricas de Software com processos em cascata.
3 - Sem falar que o foco da empresa estaria se desviando da sua atividade fim.- De onde vc tirou isso??
L
Quem faz mais uso de fábricas de software que não empresas de grande porte.
L
E por acaso isso não é repasso para os cliente né?
Um projeto em waterfall pode levar anos para fazer um simples crud, quem passa isso?
O modelo onera o cliente, a prestadora de serviço tem como intuito carregar o desenvolvimento eternamente pois ela ganha ainda mais, engociações contraturais desse tipo favorecem essas empresas que vizam o lucro, não em entregar soluções para seus clientes.
M
"
L
Marcos, vc não esta confundindo terceirizar com fábrica não?
Não estamos falando que terceirizar é errado, estamos falando que o modelo de etrceirização das fábricas são errados.
M
"
J
S4nchez:
Eu não tenho arrepios, mas minha pele fica verde, minha camisa
começa a rasgar e de uma hora para outra eu fico bombadão.
Jorge
J
OláEu também. Deve ter alguma que use mas eu não conheço nenhuma. Pelo contrário, conheço algumas que se esforçam para conseguir CMM e são extremamente burocratizadas.
[]s
Luca
Luca, Furutani:
Eu sempre achei esquisita a idéia de fábrica. Se “fábrica” tenta passar
a idéia de coisa profissional e bem organizada, vamos aplicar a outras
atividades intelectuais para as quais são cobrados profissionalismo e
competência:
Que tal “Fábrica de cirurgias” em vez de clínica ou hospital ?
Que tal “Fábrica de sentenças” em vez de escritório de advocacia ?
Que tal “Fábrica de diplomas” em vez de universidade ?
Se vendemos a idéia de “fábrica”, por que nos ofendemos com a idéia
de que nossos clientes querem um produto pronto sem se envolver no
processo ?
Se compro um carro de uma montadora, não preciso ajudar a projetá-lo.
Se compro um pastel na feira, não preciso dar palpite de como fritar.
“Fábrica” passa essa idéia, e não me surpreende que muitos clientes
procurem comprar software como quem compra pastel, porque
é exatamente isso que estamos lhes dizendo.
Jorge
L
Tem certeza que já não existem algumas dessas fábricas por ai? rsrs
Tem um texto do Rodrigo Yoshima que fala sobre cultura empresarial, é exatamente isso que não se existe nas fábricas, eles querem apenas recusros vendedores de horas, eles não querem pessoas para formarem seus times, por isso a grande rotatividade nesse tipo de empresa, não há o menor comprometimento (leia interesse) da empresa para com seus funcionários, o que acaba sendo mútuo, ai acontece o que vemos de pessoas ficarem as vezes menos de uma semana nessas empresas e já sairem, porque elas só servem pra quando vc quer levantar uma graninha fazendo trocentas horas/mês, como praticamentes todas tem problemas com prazo de entrega e qualidade, sempre há muito o que se fazer nos projetos, mesmo quando eles estão “90%” prontos já, só falta testar rs.
D
KKK, Onde será que eu já ouvi e disse isso tantas e vezes?
J
Luiz:
Li o artigo do Rodrigo e gostei, mas há também as empresas que adotam o conceito de
fábrica e tentam valorizar funcionários. Trabalhei em uma que fazia isso, do jeito dela: pagava
os vouchers para os líderes de projeto obterem certificação PMP, criou um "prêmio de excelência"
que naturalmente virou “prêmio de obsequência” (o pessoal não leu o Deming), deu treinamento
de “processos” (sim, aquele tipo de processos).
Em troca, havia relativamente pouca rotatividade. Mesmo com toda essa “valorização”, a qualidade
deixava a desejar porque uma cultura dessas não promove fazer um bom trabalho. Aquele
"orgulho do próprio trabalho" do qual o Deming falava era muito difícil.
A distância física e psicológica do cliente atrapalha muito: o único projeto em que realmente deu
gosto de trabalhar a pessoa que fazia o papel do que hoje chamariamos de “product owner” fazia
seu trabalho excepcionalmente bem. Nunca a encontramos pessoalmente, mas a comunicação fluiu,
e tivemos um cliente psicologicamente próximo. Incrivelmente, faziamos tudo via conf call com
os EUA, e funcionava. O resultado permitiu que a equipe seguisse um processo que fazia sentido
naquele contexto, incorporando algumas práticas ágeis, sentisse orgulho do próprio trabalho e
recebesse um feedback excelente do cliente.
Infelizmente, esse projeto ficou truncado depois de 4 ou 5 meses e voltamos à deprimente
realidade da maioria dos projetos feitos nesse esquema: o cliente é uma entidade abstrata,
mediada por alguém sem skills de comunicação, os procedimentos e processos são impostos
de cima para baixo, e os vícios são percebidos (por alguns) mas não podem ser corrigidos.
A cultura empresarial favorece colocar tudo no piloto automático (traduzido do
CMMês “processo definido da organização”) e acha que isso é bom.
Enfim, a moral da história é que o problema não é a ganância e a exploração de certas empresas.
Mesmo quando não há isso, percebe-se que o esquema de fábrica é furado.
Espero ter contribuído,
Jorge Diz
J
não entra na minha cabeça porque as empresas se submetem a isso ainda… será que os “clientes” são tão burros assim? décadas de projetos errados e prejuízos financeiros não ensinou nada à ninguém?
Luiz, enquanto no Brasil for comum as pessoas levarem um por fora esse tipo de prática vai ser comum, se é que você me entende, acontece a mesma coisa na política, na administração pública, etc…
André:
Pode ser mesmo que um ou outro leve um por fora, mas me parece que se trata
muito mais da incapacidade de entender quais são as formas saudáveis de
desenvolver software.
Como profissão, não temos esse entendimento; não há um conjunto mínimo de boas
práticas com as quais concordemos.
Por exemplo, os livros que usamos na faculdade foram malhados ostensivamente
nestes fóruns: não imagino um forum de médicos, advogados ou engenheiros
civis fazendo isso …
Adicione a isto o vício daqueles que gostam muito de gestão e nada de pôr a
mão na massa e perdem o contato com o dia a dia do desenvolvimento (vide a
quantidade de gente fazendo MBAs, virando PMPs, montando PMOs e sonhando
em virar CTOs, CIOs ou, quem sabe, CEOs.
São esses profissionais de três letrinhas (parafraseando o Shoes) que decidem
como, onde, quem e por quanto vai desenvolver os sistemas que fazem
(ou não fazem) funcionar as empresas.
Jorge
J
Talvez, mas não deve ser desculpa para não capacitar o pessoal interno. Alguém tecnicamente
competente e que entenda o negócio precisa fazer essa ponte, mesmo que essa pessoa não faça
todo o trabalho técnico. Dificilmente tecnologia da informação não seja crítico numa empresa.
O pessoal de fora vai demorar também para entender o suficiente do
negócio para fazer um trabalho minimamente decente.
Vc se surpreenderia com as idéias que o pessoal de dentro guarda pra dentro quando
o clima interno não favorece a troca de idéias. Uma empresa terceira que funcione como
exército de ocupação, impondo “mudanças profundas” pode ter um efeito similar ao visto
em Bagdá: radicalização da resistência e sabotagens diversas.
Acho, no entanto, que alguém de fora que seja um bom facilitador pode promover
a mudança através de alguma forma de coaching.
Como disse antes, pode terceirizar parte da força de trabalho, mas mantenha gente capacitada dentro.
Se sua empresa não está disposta a qualificar quem precisa ser qualificado, esse alguém, cedo ou tarde,
vai decidir com os pés. Perder alguém capacitado em tecnologia e no seu negócio dá um prejuízo
gigantesco.
Lembra do “The Mythical Man-Month” ? Adicionar gente a um projeto atrasado atrasa-o ainda mais.
J
Não vejo assim. Meu feeling, na condição de quem ministra treinamentos, é que as empresas
"clientes" compram mais treinamento que consultorias, software houses e fábricas de software.
E antes, quando trabalhei em consultoria, sempre tinha a impressão que o pessoal dos clientes
recebia mais treinamento.
Uma explicação possível é que para a consultoria o investimento sai caro: tem que pagar o
treinamento e deixar de receber essas horas de um cliente.
Jorge
P
Bom, você concordou comigo que a fábrica consegue reduzir custos ( Note que eu sempre estou falando das boas fábricas) e essas conseguem oferecer vantagem competitiva para seus produtos nos clientes.
Não! Eu concordei que a fábrica reduz o custo dela própria mas ela em geral aumenta o custo para o cliente ao entregar software de péssima qualidade, atrasado e com orçamento estourado. Mas pro fornecedor é um negocião.
Acho que, como o Luiz apontou, você pode estar confundindo fábrica com terceirização. Eu trabalho com terceirização de desenvolvimento de software e não trabalho em uma fábrica.
M
"
M
"
P
Não! Eu concordei que a fábrica reduz o custo dela própria
Foi isso mesmo que quis dizer. Pra saber se o preço da fábrica compensa ou não, você tem de ter uma visão muito boa do escopo e do custo do trabalho. Se o cara falar que precisa de 8 horas pra fazer uma tela que seu funcionário faz em duas, não compensa. Se o cara não tem essa visão, é melhor ficar com profissional interno. No meu último trabalho uma fábrica nossa cobrou um valor por hora pra resolver um problema em um dos sitemas. Tudo bem que somos de Uberlandia - MG e o profissional viria de São Paulo, mas fomos fazer as contas do quanto ele ganharia por mês e deu 32 mil :shock: !!
Acho que ainda não consegui me fazer entender:
A fábrica gasta $1 ao invés de $10 por usar mão-deobra subqualificada
O cliente continua pagando $1,000.00, independente do corte de custos da fábrica
O que você falou é que estes $1,000.00 podem ser menos do que um cara interno. Sim, claro, podem. Mas a minha experiência -bem como a de outros aqui- é que durante o projeto e após este o cliente vai ter que arcar com tantos gastos extras (projeto estourou prazo e orçamento, software de manutenção difícil -toda mudança é um parto, software não atende ao que o cliente pedia, software não possui performance desejada…) que o projeto sai mais cao terceirizando para uma fábrica do que para uma consultoria que não trabalha com linha de montagem e waterfall. Ou ainda usando contractors (“PJ”) ou ainda em muitos casos fazendo dentro de casa mesmo.
M
"
A
O contrato precisa deixar bem claro exatamente o que você quer em tempo, escopo e qualidade e a fábrica tem de ser responsável pelo desvio.
Tah aí um dos maiores mitos em projetos de desenvolvimento: fechar escopo, custo e prazo e buscar culpados por atrasos em projetos. Os clientes são tão culpados quanto os fornecedores pelo fracasso.
P
Isso é complicado. O contrato precisa deixar bem claro exatamente o que você quer em tempo, escopo e qualidade e a fábrica tem de ser responsável pelo desvio. Se tiver uma brecha, certamente vai acontecer o que você falou.
Então, Marcos. Considerando que estatísticas mostam que 50% do escopo de um projeto é descoberto durante o projeto e que waterfall é um anti-pattern será que este objetivo não é simplesmente impossível de ser alcançado na grande maioria dos casos? Ser;a que uma abordagem diferente, baseada em iterações e escopo deslizante não é mais indicada nesta maioria?
J
Quanto à sua afirmação, é claro que precisa ter uma pessoa de dentro capacitada pra trabalhar com o terceiro, seja uma fábrica de software ou não, senão as horas vão sair cara e
…
Não foque demais no valor-hora, porque não há termos de comparação. Ao contrário de outras áreas,
não temos tabelas que digam quanto custa um certo serviço (ou tarefa, ou artefato, ou produto): nem
em R$, nem em horas, nem em pontos de função, nem em pontos de casos de uso.
O produto não vai ter os requisitos necessários. Ponto. Nenhuma lista de supermercado vai
garantir isso, qualquer que seja o processo que você seguir. Os requisitos são sempre
elaborados em conjunto, durante o desenvolvimento, porque eles são um contraponto
da implementação, não uma condição anterior fixa e imutável.
No início do projeto, o cliente pode achar que sabe o que quer. Ele não sabe. A equipe de
desenvolvimento pode achar que entendeu o que o cliente queria naquele momento. A equipe
não entendeu. O cliente e o terceiro podem achar que sabe o que a tecnologia da informação
pode contribuir para apoiar o negócio. Nenhum dos dois sabe, nem tem como saber.
Esse conhecimento vai sendo construído durante o projeto. Negar isso é cair em armadilhas
como tentar especificar tudo o que vai ser necessário no início do projeto (engessando tudo
antes da hora), criar comitês para desestimular “mudanças” de requisitos (em vez de mudanças,
prefiro falar de ajustes), fazer contratos comerciais onde se especifica um certo número de
pontos cujo cálculo é extremamente subjetivo (certificações aparte) e chegar no atual
estado das coisas no desenvolvimento de sistemas, no qual dois terços das funcionalidades
de um sistema não são usadas em produção, o sistema fica inchado e a manutenção fica
extremamente cara (mais de dois terços do custo total de um sistema).
Minha experiência mostrou que essa máxima foi verdadeira em todos os projetos em que participei.
Paralelismo significa ruído na comunicação: quanto mais ruído, mais riscos, menor produtividade e
pior qualidade. Não há balas de prata, por mais promissoras que possam parecer certas metodologias /arquiteturas / práticas de gestão. Gerenciar bem é lidar bem com riscos, e o risco de adicionar gente
num projeto atrasado, na minha intuição, é escandalosamente alto. A única certeza é que o seu custo vai aumentar.
P
Agora não entendi. Qual a relação entre MVC, metodologias ágeis e colocar gente num projeto andando?
J
Se a pergunta foi para mim, respondo: nenhuma.
Foi isso que quis frisar, aparentemente sem sucesso.
P
Não, não foi para você, foi para o autor da frase.
L
Gerenciar bem é lidar bem com riscos, e o risco de adicionar gente
num projeto atrasado, na minha intuição, é escandalosamente alto.
Por isso qeu mentalidade de quem vive e planeja um projeto em fábrica é preparar o ambiente para quando tudo ir por água abaixo eles poderem entupir de novos recursos.
Essas empresas iniciam projeto HOJE com struts 1 porque vão precisar alocar pessoas novas todo mês, pois ninguém tem comprometimento e nem motivação de trbaalhar nesses lugares, sendo JR então, qualquer 2 reais hora a mais que apareça significa trocar de emprego, então eles querem algo que possa ser masi facilmente absorvido pela dezena de desenvolvedores que vão passar no projeto ao longo do tempo.
Enquanto outras empresas estão preocupadas em formar equipes multidiciplinares que se comprometam com o projeto e possam trabalhar visando entregar algo de qualidade para o cliente, essas empresas buscam vendedores de horas que não estão nem ai pro cliente, pra empresa, pro projeto, pra nada, ai vira a bola de neve que nós já estamos cansados de conhecer.
D
Qualidade e Fabrica de Software são duas coisas que não vi ainda caminharem juntas, talvez não seja tanto o modelo Fábrica e sim as consultorias que administram as suas fábricas pensando em $$$$$$$$$ aumentar sua margem de lucro sem investir um R$ 0,01. Trabalhei numa fábrica que não tinha nem ar condicionado!
Quando eu estava na fábrica eu estava muito insatisfeito e vi minha produtividade ir diminiuindo a cada dia que passava, prova disso que os primeiros projetos estavam estava muito bons e os meu ultimos estavam muito aquem.
Parece que o ambiente lá te desanima, use cases frustrantes, especificações frustrantes e politicas frustrantes.
Esse modelo é muito engessado te pouca liberdade, além de te forçar a trabalhar com coisas do tempo do êpa.
M
"
L
Que tal desenvolvimento iterativo (e incremental)?
Que tal um Product Backlog que vai tendo seus itens flutuando pra baixo e pra cima conforme a prioridade/necessidade DO CLIENTE?
Ter alguém com conhecimento do negócio do cliente e que seja comprometido com o projeto para fazer isso funcionar corretamente, que diga o que realmente importa para o cliente, já diminui drasticamente o desvio ocorrido nos projetos.
P
Bom, eu trabalho com metodologias ágeis há alguns anos e não lembro de ter visto em nenhum lugar com cre’dito alguém defendendo este tipo de coisa. Na verdade, dado que em metodologias ágeis se trabalha em times pequenos e multi-funcionais, seria o extremo oposto. Eu não entendo como práticas como propriedade coletiva de código, user stories entregando valor de ponta-a-ponta, integração contínua e outras poderiam funcionar num ambiente onde exista qualquer paralelismo no desenvolvimento de um sistema.
Pode explicar melhor ou dar referências?
Se o desenvolvedor já está no time provavelmente o relatório é uma user story separada e sim, ele pode ser paralelizado dentro do time se fizer sentido. Se o desenvolvedor vem de fora então seu exemplo está explicado no livro do Fred Brooks, já citado:
Recomendo fortemente a leitura deste livro.
Quanto ao MVC, eu ainda não entendi como ele se encaixa nisso tudo. MVC é apenas uma forma de dizer como 3 componentes de uma aplicação se comunicam, não vejo o impacto na metodologia em usar ou não.
As ferramentas (e, principalmente, as metodologias) de gerenciamento de projeto fazem isso há anos e não resolveram os problemas. A questão é simples, creio: não adianta tentar controlar o incrontrolável. Há mais de duas décadas que se tenta isso com falhas miseráveis todos os anos (vide CHAOS reports).
Mas acredito que você está convergindo para o iterativo incremental, talvez eventualmente ágil. O grande problema é que iterativo e incremental não combina com linha de montagem, onde um time alimenta o outro. Neste modelo não há o tempo e a cerimônia do waterfall, os ciclos e iterações devem ser curtos e você não precisa se preocupar em entregar uma especificação 100% ok para o próximo da fila (analista -> proramador -> testes, etc) porque o que você vai desenvolver é só o necessário para aquela iteração.
M
"
P
Mas modelo iterativo e incremental (com todas as suas variações) é para desenvolvimento de software.
O que eu discordo é que (1)numa fábrica isso funciona e que (2)por serem atividades diferentes você pode adicionar pessoas num time para paralelizar tarefas livremente.
Bom, MVC não é sobre Camadas, mas ainda que fosse não é porque você tem Camadas diferentes que elas podem ser desenvolvidas por pessoas diferentes. O nível de acoplamento entre Camadas é grande demais, talvez você esteja se referindo à Componentes, que possuem contratos e interfaces bem-definidas.
Eu entendo seu ponto mas para mim isso é equivalente a dizer que alguém vai do Rio à São Paulo andando, mas vai de Nike. Por que não pegar um avião (cuja passagem custa menos que o tênis) em primeiro lugar?
Nada funciona em tudo mas a coisa não é como você falou. De qualquer forma, metdologias iterativas e incrementais, especialmente metodologias ágeis, possuem “gerenciamento constante” e baselines. Na verdade elas costumam ser bem rígidas com relação à como o processo é gerido.
O ponto é que este tópico é sobre Fábrica de Software e pelas razões que coloquei no último post eu não acredito que ela consiga ser eficiente neste sentido -ela, na verdade, foi criada para ser ineficiente e barata.
R
Marcos, desculpa a sinceridade, mas esse foi o maior absurdo que ouvi nesse fórum até hoje.
M
"
M
"
P
Tudo é possível mas eu, autores de metodologias e Brooks discordamos de que seja em muitas situações. Existe um impacto muito grande em tirar ou colocar uma pessoa de um projeto, mesmo metodologias ágeis que pregam pair programming como XP tratam isso com extrema cautela e eu nunca vi ninguém recomendando -nem eu recomendo- colocar pessoas em projetos atrasados. Dificilmente o projeto está atrasado por falta de pessoal, geralmente o problema é mais embaixo, e se for por falta de essoal até estes se tornarem produtivos vai demandar muito tempo/custo.
E não confunda com “o mesmo analista do início ao fim”, estamos conversando sobre a sua discórdia com Fred Brooks sobre acrescentar pessoas em projetos atrasados:
Depende do projeto e da alocação. Em algumas vezes sim, mas se existe capacidade de paralelismo ela pode ser explorada. Com projetos baseados em MVC e utilizando metodologias ágeis, muitos desses pontos são fáceis de identificar, mas a pessoa tem de saber gerenciar. Mais um motivo pra ter alguém de dentro pra acompanhar os terceiros (fábrica ou não).
Novamente eu recomendo a leitura do livro.
Eu não me lembro de ter falado em nenhum lugar ensta thread sobre não haver acompanhamento ou erenciamento. A analogia foi apenas para tentar mostrar que comprar uma ferramenta bonita e cara (o tênis ou uma ferramenta de gestão de projeto) não adianta.
Como eu já repeti aqui nesta thread algumas vezes isso de “avisar a diretoria” nunca acontece.
Primeiro porque o gerente confunde progresso com execução de tarefas e tenta medir o que não é mensurável. Se 90% das tarefas estão 90% concluídas então o projeto está quase que 90% concluído? Não. Gerenciamento de projeto de software não é matemática de primeiro grau, não adianta somar, dividir e multiplicar. Os 10% restantes podem ocupar 99% do tempo total do projeto e ninguém previu isso. No final o projeto chega no deadline em sei-lá-quantos-% pronto. 90% pronto não é pronto.
O outro problema é que ao primeiro sinal -sempre tarde demais- de que o projeto vai atrasar os gerentes de uma fábrica vão apertar seus funcionários para que trabalhem mais. Horas extras, sábados, feriados, baixar a qualidade do software… tudo o que for preciso para entregar. Entregar qualquer coisa, mas entregar algo.
Uma abordagem baseada em iterações possibilita prever o risco e traçar uma estratégia eficiente, porque se baseia em dados reais. Nossa velocidade é 5, temos duas iterações para acabar o projeto e 25 pontos. (1) Marque uma reunião com o cliente para priorizar quais dos 25 pontos restantes devem entrar nas duas últimas iterações (2) procure coisas simples que podem aumentar a velocidade e (3)em vez de um software 90% funcionando você entrega um software 100% funcionado com 90% do escopo implementado. Precisamos terminar? Bom, se a velocidade se mantiver precisamos de mais 3 iterações.
A coisa não é não gerenciar ou não acompanhar mas sim parar de seguir um anti-pattern chamado waterfall. Cronogramas completos, acompanhamento tarefa-a-tarefa… nada disso tem funcionado desde a época de Fred Brooks.
O ponto é que este tópico é sobre Fábrica de Software e pelas razões que coloquei no último post eu não acredito que ela consiga ser eficiente neste sentido - ela, na verdade, foi criada para ser ineficiente e barata.
Opinião não discuto :lol:
Engraçado, eu citei aqui alguns trabalhos -Mythical Man-month, CHAOS Report- estatísticos e acadêmicos. Será que é somente minha opinião?
P
E como adendo sobre componentes:
Comonentes podem tecnicamente ser implementados por times diferentes. Muitas vezes funciona. o problema é que para Componentes de Negócio isso é um mito. Novamente: é tecnicamente viável (assim como é viável fazer o mesmo sem componentes ou mesmo Camadas) mas qualquer caso de uso vai envolver mais de um componente e separar o mesmo caso de uso por pessoas distintas não é uma boa idéia.
R
Bom, se você acha que um trabalho de interfaces é mais comparável com quem trabalha na regra de negócios, ótimo. Sobre o artigo, ele vai muito em direção ao que falei: gerenciar o processo não é só caso de uso e uml, tem de ser gerenciado de perto analisando caso a caso as atividades. O que sai caro na grande maioria das vezes é deixar tudo andar com a maré.
Marcos,
Especializar papéis entre análise e programação já é sofrível. Fazer isso ao nível de camadas e tentar gerenciar essa dinâmica é uma aberração.
Pelas conversas que tivemos nesse fórum dá pra ver que você é bem fã da visão do PMBOK com relação ao gerenciamento de projetos (WBS, escopo detalhado, controle de tarefas e etc…). Atualmente tenho desenvolvido softwares para a área de engenharia (mecânica, elétrica e civil) e vejo que essa visão casa bem com esses tipos de projetos. São projetos que envolvem mais de 10 equipes e centenas de pessoas que muitas vezes não são profissionais do conhecimento (aka peão de obra). Outro ponto: esses projetos tem uma segurança com relação à sua previsibilidade. É um tipo de projeto que a soma das tarefas dá o resultado esperado.
Para projetos de software as tarefas não são importantes para o gerenciamento. O que é importante são os objetivos. São histórias implementadas e não tarefas cumpridas (como o pcalcado explicou). Nosso earned value cresce só com casos de uso funcionando. Escrever casos de uso, fazer modelos, fazer planos, codificar, testes não agregam valor. Como sempre digo, o escopo de um projeto de software é resolver problemas de negócios e não implementar requisitos. É um processo empírico.
M
"
M
"
P
Tudo é possível mas eu, autores de metodologias e Brooks discordamos de que seja em muitas situações.
Nunca disse em muitas, mas “quando possível”.
Sim, você disse que em muitas situações:
O CHAOS Report discorda de você. Pode ser sua opinião mas dadas as estatísticas tanto do relatório quanto das pessoas que postaram nesta thread eu creio que voc6e está enganado.
Você está analisando o pior caso. Será que a maioria dos gerentes de software ainda pensam assim? A grande maioria não, a realidade tem mudado bastante. Novamente eu tomaria cuidado com a palavra “sempre” e generalizações.
Novamente: confira as estatísticas antes de falar em maioria.
Todos os trabalhos citados falam de uma abordagem comum para todos os projetos, a famosa “receita de bolo para o sucesso”. Gerenciamento nunca foi isso. E nesses trabalhos eles mesmo citam que não estão falando para não usar as metolodias, mas para não adotá-las como regra geral, eu concordo com isso. Gerenciamento é saber quando, onde e em que ponto usar. NESSE PONTO, fábricas de software podem ter um sucesso maior.
Nenhum dos trabalhos citados ala sobre receita de bolo ou sequer descreve metodologias. Antes de criticar algo é sempre bom saber do que se trata.
L
Cite apenas um exemplo real de uma empresa conceituada que conseguiu isso dessa maneira que vc descreve tanto nessa thread!
Agora se quiser exemplos de empresas que não conseguem, podemos fazer uma lista aqui de pelo menos 10 páginas.
Parece que vc esta se esforçando para “vender” um brinquedo quebrado, que todos estão carecas de saber que não da certo, que não funciona, o Phillip cansa de citar autores e mais autores mostrando isso, relatos e mais relatos comprovando a grande porcaria que é trabalhar dessa maneira, mas como sempre, continuam tentando meter isso goela abaixo, vendendo idéias falidas há vários anos, tentando achar meios de justificar os erros para fazer acreditar que se tivesse sido feito corretamente, funcionaria.
Desculpe, mas estamos em 2008, acho pouco provável alguém (que seja do meio, geralmente o cliente não é) ver os fatos, analisar o cenário (como toda hora alguém faz mostrando dados, autores e etc) ainda dar crédito a toda essa maneira fálida de se pensar em software.
M
"
P
Ótimo, então cite e vamos continuar o debate.
O estranho é achar que não vale a pena gerenciar um projeto ou ter métricas pra avaliar a qualidade do software.
Essa parte tá meio chata. Já foram umas duas ou três vezes que falei aqui que não é sobre não gerenciar ou ter métricas mas sim qual tipo de gerência e métrica é usada, como por exemplo na página anterior:
A conversa estava interessante mas peço que leia as respostas, do contrário fica bem difícil mantêr um diálogo sadio.
M
"
P
Hmm… interessante. Você sabe de onde surgiu a frase “No Silver Bullet”?
De qualquer forma, favor mostrar onde eu falei que algo sempre falha para que entenda melhor o que está dizendo.
O que você chama de cronograma completo? Se for ter um cronograma no início do projeto e se ater a ele, não é só pra software que não funciona, mas em qualquer projeto que o escopo vai se definindo a medida que for caminhando. O problema é achar que por causa disso pode desenvolver sem nenhuma previsão e sem nenhum acompanhamento por acreditar que “como vai furar, não adianta acompanhar, no dia que ficar pronto, eu entrego”.
Eu não vou nem entrar no cronograma, só vou perguntar quem falou “pode desenvolver sem nenhuma previsão e sem nenhum acompanhamento por acreditar que ‘como vai furar, não adianta acompanhar, no dia que ficar pronto, eu entrego’”.
Me parece que você está implicando que se não se usa os métodos que você defende para gerência de projetos (por exemplo um cronograma de tarefas) não há gerência. Se isso for verdade então sinto muito mas você está completamente enganado.
M
"
P
Pois é, o autor deste artigo chama-se Fred Brooks e é o autor que eu estou recomendando que você leia há duas páginas -o livro que fala sobre como novas pessoas atrasam um projeto.
O que eu não entendi até agora é onde você acha que eu discordei disso. O tópico é sobre Fábrica de Software e não sobre se um projeto deve ou não ser acompanhado. O meu ponto é que os métodos usados pelas fábricas -e não necessariamente os princípios- falham e existem meios melhores.
Bom, organizando as idéias:
1 A empresa está com um determinado problema e chegou a conclusão internamente que o desenvolvimento de um software resolveria esse problema.
2 Por questão de limitação de recursos (humanos, financeiros, tempo, cronológico, etc) decidiu terceirizar
3 Poderia escolher uma das várias opções: comprar software pronto, contratar uma empresa de software normal pra desenvolver ou contratar uma fábrica de softwareAté aí a gente concordou que terceirizar poderia ser uma opção dependendo do caso. A discordância foi que a metodologia de uma fábrica de software poderia ser melhor do que outras já existentes, certo? Você citou que já teve experiências que no final o produto demorou mais tempo, custou mais e não saiu com a qualidade esperada.
Exato e por isso eu não entendi seu pontos nos últimos dois ou três posts antes deste.
O assunto está andando em círculos, então vou tentar concluir:
Gerenciar um projeto é importante. Existem milhões de formas de fazer isso. Uma fábrica se baseia no modelo de linha de montagem, linha de montagem não funciona para software. Claro que pode funcionar num caso X ou Y mas como regra geral não funciona e as estatísticas mostram isso.
M
"
N
Bom, uma rápida procura na wikipedia mostra um artigo que resume o pensamento nacional sobre o que é uma fábrica de software:
[editado]
Deixando mais claro:
[/editado]
L
Marcos vc esta enganado amigo, pois é exatamente por se basear nesse modelo de linha de montagem que se usa essa terminologia “fábrica de software”, ou seja, entra (requisitos), processamento (desenvolvimento, teste, homologação) e saída (produto final).
TODAS as empresas que se intitulam/rotual/vangloriam “fábricas de software” que eu conheço aqui em São Paulo trabalham exatamente assim, se existir alguma que trabalhe diferente (o que eu dúvido) nos fale para temos um exemplo real pelo menos.
R
Concordo exatamente com você. Mas pelo que eu entendi de fábricas de software até hoje, elas não se baseiam em linha de montagem e produção em série da forma que você está falando, pelo menos o que eu interpretei dos modelos de fábricas de software que conheço
Geralemten seguem o seguinte modelo: Analista de requisitos se reune com o cliente, o cliente inventa um milhão de coisas para o software, o analista faz um documento de requisitos, faz o cliente assinar os requisitos com o sangue, passa os requisitos para o arquiteto\projetista, que faz um monte de diagrama UML e passa para um programador que traduz aquele UML em código, compila, faz a build, passa para um testador que faz meia duzia de cliques nas telas do sistema, encontra N erros, e passa os Change Requests para o programador, que corrige os N erros, fazendo referencia do Change Request na alteração que ele teve que fazer, aí o tester fala para o gerentinho do projeto “OK”, o gerentinho do projeto entrega o projeto pro cliente, o cliente homologa, passa para o usuário e ele ve que aquela joça não presta.
Ficou meio confuso (propositalmente), mas é mais ou menos assim.
D
Olá amigo marcosalex.
Tome cuidado com essa necessidade exacerbada de gerenciamento de projetos. Como nossos colegas aqui do forum disseram, precisamos sim gerenciar, basta verificar como isso está sendo feito e como pode ser feito. Cuidado para não cair no “Comando Controle”… Desenvolvimento de software é arte, ao menos para mim, arquitetura também vai além da arquitetura e contrução civil no qual o nosso velho modelo cascata baseou-se. Fábricas de software, como todos disseram, seguiram o modelo industrial também, todos numa tentativa desesperada de se “moldar” o desenvolvimento de software.
Convido-o a participar de alguma palestra que fale do manifesto ágil ou mesmo sobre Scrum. Leia alguns artigos, blogs como o do nosso colega “Shoes”.
Recomendo o link: http://www.scrumalliance.org/
Abra a mente meu camarada…
Forte abraço,
Dany Gregory.
M
"
D
Peço desculpas se lhe passei esta idéia meu caro, de forma alguma foi minha intenção atacá-lo.
Como nosso colega disse que desenterrei um assunto jurássico, vamos por o dinossauro de volta porque não queremos um Rex solto por aí certo? Se é que vale o trocadilho.
Grande abraço!
Dany Gregory.
V
cara acabei de entra, me da dicas, pois tenho muita expriencia com eletronicos…
M
Acho que a culpa da decadência do trabalhador nas fábricas de software é por causa da administração.
Sim, os administradores, que inspirados em seus ídolos austeros como Frederic Taylor e até mesmo Henry Ford, implantam processos oriundos das linhas de produção, segmentando o trabalho, fazendo com que cada programador faça uma pequena parte do produto final. Já vi lugares em que um programador fazia o orçamentário, outro fazia o financeiro e assim por diante. O resultado final era que cada um dos coitados não conhecia o produto que fabricava.
Existem fábricas de software em que os administradores levam tão a sério o modelo Taylorista que dividem tanto o trabalho que cada profissional faz somente a mesma coisa todos os dias: um só trabalha com css, outro só trabalha com javascript, outro só mexe com php, outro só mexe com arquitetura e assim por diante. O resultado é desatroso para o trabalhador, que sai inápto para fazer um produto inteiro, já que só sabe fazer uma pequena parte de um software.
Já vi programadores que sairam de fábricas de software reclamando que não conseguiam fazer um software por inteiro, desde a análise até a implantação… Eram ináptos pois as fábricas de onde sairam segmentava o trabalho. Como dizia o grandíssimo filósofo Proudhoun: “o trabalho parcelar embrutece a inteligência”. No caso, torna os programadores ináptos para fazerem outras partes de um sistema, então ficam na mesmisse e sempre serão explorados e humilhados por essas fábricas e consultorias.
O mesmo aconteceu com a Atari. A Atari foi fundada pelos próprios programadores e foi gerenciada por eles próprios até um dia ser comprada pela Warner, com isso veio a adminstração e implantou uma linha de produção lá, transformando a Atari em uma fábrica de jogos. Os programadores revoltados, recusaram essa humilhação e deixaram a Atari para formar outra empresa, a Activision.
Qualquer um que pense bem percebe que essas linhas de produção são humilhantes para quem está trabalhando nelas, e eu diria que seus inventores Taylor, Ford e corja do tipo, são malignos em fazer algo que visa somente o lucro em detrimento do bem estar e brio do trabalhador. Se você tiver alguma noção de brio e compaixão pelo próximo, vai concordar. Parece até exageiro dizer que são maligos, mas qualquer um que tenha um pouco de tendência de falar ou fazer o mau são malignos, e, esse tipo de gente são a maioria em nossa sociedade.
Henry Ford apoio e financiou o terceiro reich de Hitler, não me foi surpresa quando descobri isso, pois há mesmo algo maligno em alguém que inventa uma linha de produção com o intento de aumentar a produtividade e lucro reduzindo o ser humano a engrenagens de máquina, humilhando-os em toda suas faculdades mentais e desrespeitando tudo aquilo que há de elevado no ser humano. Alguém que trabalhe nisso se embrutece, atrofia todas suas qualidade morais e intelectuais. Não há brio, e o serviço se aproxima mais ao sentindo original da palavra “trabalho”, que é castigo.
Fábricas de software são as linhas de produção de trabalho parcelar dos tempos modernos. É o mesmo modelo Taylorista implantado na Atari que humilhou e indignou seus programadores forçando os mesmos a montarem outra empresa. Acho que qualquer um com um pouco de amor próprio e sentimento de dignidade e respeito próprio foge desses lixões e consultorias que se auto denominam fábricas.
Criado 14 de maio de 2007
Ultima resposta 29 de out. de 2012
Respostas 119
Participantes 37
Casa do Codigo APIs REST: Seus servicos prontos para o mundo real Por Alexandre Saudate — Casa do Codigo
Fiap Graduacao em Tecnologia — FIAP Analise e Desenvolvimento de Sistemas, Engenharia de Software e mais
Casa do Codigo Casa do Codigo — Livros de tecnologia Livros de programacao, infraestrutura e inovacao