Fábrica de Sofware

JavaChild Membro desde: 13/03/2008 09:39:28 Mensagens: 103 Offline

marcosalex wrote:
Por enquanto, terceirizar é melhor quando:

1) Não consegue a competência imediatamente: não tem cabimento reinventar a roda. Um terceiro é capaz de fazer a transferência deste conhecimento rapidamente. É muito mais prático e rápido do que buscar um profissional no mercado.

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.

marcosalex wrote:
2) Quer uma mudança profunda: seja de que natureza for, tecnológica ou não, transformações radicais são melhor conduzidas por terceiros. A razão? Os profissionais da equipe atual serão sempre um foco de resistência ao novo. Nem sempre seguem o que dizia John Cage "Não temos que temer as novas idéias, mas sim as velhas"

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.

marcosalex wrote:
3) Competência: sua companhia até pode dominar determinado conhecimento, mas está consumindo investimentos e não necessariamente está remunerando o capital com o retorno compatível com o resto das operações. É hora de pensar em terceirizar, pois o prestador de serviço está mais predisposto a fazer investimentos em qualificação do que sua empresa.

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.

marcosalex wrote:
4) Prazo: se o problema é cumpri-lo, a capacidade um terceiro em alocar recursos é alta. Em geral, ele sempre conta com uma reserva técnica, acionada nestas emergências.

Lembra do "The Mythical Man-Month" ? Adicionar gente a um projeto atrasado atrasa-o ainda mais.

JavaChild Membro desde: 13/03/2008 09:39:28 Mensagens: 103 Offline

marcosalex wrote:
3) Competência:
...
É hora de pensar em terceirizar, pois o prestador de serviço está mais predisposto a fazer investimentos em qualificação do que sua empresa.

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

marcosalex wrote:
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.

marcosalex wrote:
Em empresas que trabalhei e que tive a oportunidade de conhecer, conseguimos reduzir bastante custo com pessoal contratando softwares de terceiros. [...]

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.

This message was edited 1 time. Last update was at 23/12/2008 15:48:59

"

This message was edited 1 time. Last update was at 23/12/2008 15:50:15

"

marcosalex wrote:

pcalcado wrote:
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 !!

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.

This message was edited 1 time. Last update was at 23/12/2008 15:52:40

"

Virtual Machine Man Membro desde: 02/06/2005 16:28:38 Mensagens: 702 Offline

marcosalex wrote:

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.

marcosalex wrote:
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?

JavaChild Membro desde: 13/03/2008 09:39:28 Mensagens: 103 Offline

marcosalex wrote:
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.

marcosalex wrote:
... o produto entregue não vai ter todos os requisitos necessários.

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).

marcosalex wrote:

Jorge Diz wrote:
Lembra do "The Mythical Man-Month" ? Adicionar gente a um projeto atrasado atrasa-o ainda mais.

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).

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.

Agora não entendi. Qual a relação entre MVC, metodologias ágeis e colocar gente num projeto andando?

JavaChild Membro desde: 13/03/2008 09:39:28 Mensagens: 103 Offline

pcalcado wrote:Agora não entendi. Qual a relação entre MVC, metodologias ágeis e colocar gente num projeto andando?

Se a pergunta foi para mim, respondo: nenhuma.
Foi isso que quis frisar, aparentemente sem sucesso.

Não, não foi para você, foi para o autor da frase.

Jorge Diz wrote: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.

This message was edited 2 times. Last update was at 07/07/2008 10:29:55

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.

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